incompatible

@feather12315 996 只是手段不是目的。我们的目的不是加班，而是创造价值。首先为客户创造价值，然后为公司创造价值，在创造价值的过程中得到个人的成长。这的确是福报。
🙄

@gramyang
1. 你现在转学法律也不晚；
2. 写代码的高级技工如果当初学法律，也并不能成为规则的制定者。你能做什么不取决于你是学习什么的，取决于你所处的阶级。

这不是哪个好用的问题，这是钱的问题。
凭什么 idea 要比 eclipse 好用？凭 idea 是要付钱买 license 的。
你口中的老顽固们没这个动机去了解一个收费软件啊。

光看主贴的话，我觉得这个不太难，做一个贝叶斯分类器，然后用已有的谣言去训练它就好了。这个对于本科毕设来说是难度适中的。

看到你的补充，我觉得你的导师很可能是个水货，然后他在网上看了 “阿里巴巴达摩院造个“神器” 谣言识别准确率 81%”之类的新闻就灵机一动想到一个通过传播路径判断谣言的点子。阿里巴巴有资源干这个，你导师一个高校教师自己有没有资源支持学生干这个难道心里没点数吗。。。。

@Showfom 有，会。

@LeoQ

关于 API 的向下兼容：并非指的是 v2020xxxx 要兼容 v20140815 的功能，而是说即便发布了 v2020xxxx 后，v20140815 依然可用并且行为不变。 对于调用方来说，升级 api 版本或者 sdk 版本都是非常 critical 的事，在升级过程中，校验 sdk 或 api 的版本兼容性是必不可少的步骤。当然如你所说，sdk 版本和 api 版本强绑定是个糟糕的设计。

属性和 setter 之间的取舍，你看一下阿里 sdk 的源码，它是在 setter 里把 params 放到了父类的一个 dictionary 里了。另外基于它代码中有 add_query_param()的字样，我推测除了 query params 应该还有 body params、header_params、这些是基于 api metadata 生成 sdk 的 request 就固定下来的，如果不用 setter 的方式就需要额外的 metadata 来描述一个 param 的位置到底是在 query、body 还是 header 中。

最后关于动态设置 request 的属性，我自己是阿里云 ecs/rds/slb 等产品 java sdk 的重度用户，其实不太明白为什么有“动态设置属性”这种需求。你有什么场景是必须要动态设置属性的嘛？

来自友商的问候。。。
有点好奇贵厂都是原厂去帮客户交付的？交付不找合作伙伴嘛？

v20140815 有什么问题？ 公有云产品的 API 必须向下兼容，即便某天发布了 v2020xxxx，先前的 v20140815 也是要永久保留的。
SDK 里 client 与 request 各司其职，request 负责封装 API 的参数； client 负责从 request 取参数、做签名、拼 url 发请求、解析返回值。且各个产品的各个 API 都 follow 此 pattern，学一次就会用所有产品的 API 了。
你自己定义的 DatabaseTask 相比之下并没看出有什么优点，仅仅是满足了你自己的偏好而已。

注入并非一定要通过 setter 或者 constructor，通过 field 也可以。Java 反射机制可以 list 到所有 field （包括 private ）并且改变 field 的 accessibility 的。

此处注进来的 HttpSession 是一个 proxy，对该 HttpSession 的方法调用会被代理给当前线程对应的 http request 的 session。