@jamesxu 有三种类型的安装包：bin/all/src bin 是 83M，all 是 126M，工程使用用 bin 即可，all 包含了文档和示例代码。

@liuxey 是我的 typo。。。[捂脸]

这个邮件是我发的。楼上各位，如果还遇到下载慢的问题请告诉我（你的地区 /ISP/下载链接 /下载速度，最好有截图），我会设法处理。

我 91 年的，是我厂所有工程师中最年轻的。

按照楼主的描述，项目肯定不是标准的 Maven/Gradle 项目。有抱怨的时间，不如尝试把项目变成 IDE 无关的。

我觉得答案显而易见啊。。。简历质量不高让人没有面试的欲望啊。。

数学系啊。。。。

@smeraldo 从目前和三个 merge 了我的 PR 的团队的接触来看，我对他们三个团队很有信心。但是从跟你的对话来看，我对你的团队没有信心。

@smeraldo 我是这么理解的：

首先，对于不能 /不想修复的问题，@SuppressWarnings 是常规操作。在 Sentinel 项目中，说句实话，我没有把握把这几个问题修复好（类似的注解还有 @SuppressFBWarnings，是 FindBugs 引入的，它需要额外的注解是因为 FB 扫描的是字节码，字节码中已经没有 @SuppressWarnings 信息了）。

其次，仅仅 @SuppressWarnings 不会使代码变得更坏——它是编译期注解，对编译后的结果没有任何影响。好处是从此之后新的违背代码规范的问题能在第一时间被发现。

最后，假如哪一天团队想要修复相关问题，全局搜索相应的 @SuppressWarnings 注解即可，无需运行构建。

这让我想起来，gradle 在迁移 Java9 的过程中，发现有很多测试在 Java9 上不能通过。我们当时的解决方案是，引入了一个 FIX_TO_WORK_ON_JAVA9 注解，在 Java9 上直接忽略这些测试： https://github.com/gradle/gradle/blob/69e400f5f00d60684c75827ecf61d3521d333467/subprojects/internal-testing/src/main/groovy/org/gradle/util/TestPrecondition.groovy#L106。忽略这些测试并不意味着从此不管了，而只是代表这些问题我们知道了，当前限于实际无法处理。绝大多数被忽略的 Java9 上的测试已经在去年夏天被修复掉了。

@smeraldo 这样做的目的是保证代码至少从此以后不会变得更差。

@azh7138m 我不知道你用的什么工具，我用 IDEA，在单个文件或者项目上 右键 Analyze - Run inspections by name - 选择修复类型 - Fix 即可。

@xiaohuamao 因为我喜欢写代码呀。

@realPipiz 不。

@PP @VoidChen @dfjslkjdf 我已经提交了 4 个 PR 了，你们呢？你们除了高谈阔论冷嘲热讽，做了什么？

@dfjslkjdf 我的时间比你值钱的多，但我乐意。合并 PR 的人都没意见，你算个什么东西。

@dfjslkjdf 想看我的代码的话，这是给 OpenJDK 修的 bug：

http://hg.openjdk.java.net/jdk/jdk/rev/53a4760e9fcc

https://bugs.openjdk.java.net/browse/JDK-8210810

无知不是你的错，出来嘲讽就是你的不对了。

@fancyhan @dfjslkjdf

阿里巴巴 Java 开发手册：

(七) 控制语句

2. [强制] 在 if/else/for/while/do 语句中必须使用大括号。即使只有一行代码，避免采用 单行的编码方式:if (condition) statements;

https://stackoverflow.com/questions/2125066/is-it-a-bad-practice-to-use-an-if-statement-without-curly-braces

https://coolshell.cn/articles/11112.html

历史上引起过严重 bug。

无知不是你们的错，出来嘲讽就是你们的不对了。

@pabupa 我刚数了一下我迄今为止已经在 GitHub 上提交了 365 个 PR 了，可能发了 365 次高烧吧。

@PP 我已经提交了两个 PR 了，你呢？你还在那里高谈阔论么？