Java，如果这是一个更好的世界

只是梦想着有一个更好的世界，在该世界中，Java平台中的一些旧错误已得到纠正，而某些令人敬畏的缺失功能也已实现。不要误会我的意思。我认为Java很棒。但是它仍然存在一些问题，就像其他平台一样。我希望没有这些特定的命令，而不必声称自己几乎是详尽无遗的，更重要的是，如果没有要求您经过深思熟虑且完全正确，我希望这些事情：

可串行性

在对象内，可串行性是默认设置。如果您不希望成员可序列化，则将其标记为“瞬态”。为什么在地球上我们必须添加这个愚蠢的标记
接口“可序列化”到我们所有的类？

默认情况下，所有对象都应可序列化。非可销售性应该是明确标记的“功能”

当然，可序列化性本身具有许多我不会涉及的奇怪细节，在这里

克隆

由于默认情况下所有对象都应可序列化，

默认情况下，所有对象也应该是可克隆的。不可克隆性应该是明确标记的“功能”

此外，浅克隆几乎是无用的。因此

默认情况下，所有对象都应深克隆自己。浅克隆可以显式实现

注意，clone方法应该是java.lang.System或某些其他实用程序中的某些本机方法。它不应位于java.lang.Object上，从而允许客户端代码实现正确的克隆解释，而不会发生任何偶然的名称冲突。或者，可以实现类似的私有回调方法，如果应定制克隆，则采用与序列化相同的方式。

无符号数字

为什么这不是Java的一部分？

所有整数基元以及java.lang.Number包装器都应该有一个无符号版本。

原语

基元是API支持的一种痛苦。从语法角度来看，int和Integer应该相同。 int []和Integer []也应该是

应将原语及其包装器更好地集成到语言和JVM中

如果不放弃真正的原语所提供的性能优势，这可能是无法真正解决的。看到Scala…

物产

Getter和Setter并不是最先进的技术。

应该更正式地支持属性

另请参阅此博客上的最新文章及其评论： http : //blog.jooq.org/2013/01/12/bloated-javabeans-part-ii-or-dont-add-getters-to-your-api/

馆藏

集合API应该与该语言更好地集成。像许多其他语言一样，应该可以使用方括号和花括号取消引用集合的内容。 JSON语法将是显而易见的选择。应该可以这样写：

// Translates to new ArrayList<>(...);
List<Integer> list = [ 1, 2, 3 ];// Translates to list.get(0);
Integer value = list[0];// Translates to list.set(0, 3);
list[0] = 3;// Translates to list.add(4);
list[] = 4;// Translates to new LinkedHashMap<>(...);
Map<String, Integer> map = { 'A': 1, 'B': 2 }; // Translates to map.get(0);
Integer value = map['A']// Translates to map.put('C', 3);
map['C'] = 3;

线程本地

在某些情况下，ThreadLocal可能是一件好事。 ThreadLocal的概念可能不是100％合理的，因为它可能导致内存泄漏。但是假设没有问题，

threadlocal应该是关键字，例如volatile和transient

如果transient值得作为关键字，那么threadlocal也应该是。这将如下工作：

class Foo {threadlocal Integer bar;void baz() {bar = 1;           // Corresponds to ThreadLocal.set()Integer baz = bar; // Corresponds to ThreadLocal.get()bar = null;        // Corresponds to ThreadLocal.remove()}
}

当然，这样的关键字也可以应用于原语

参考文献

引用在Java中有些奇怪。它们在java.lang.ref包中作为Java对象实现，但是JVM和GC对其进行了特殊处理。

就像threadlocal一样，应该有关键字来表示参考

当然，随着泛型的引入，添加这样的关键字几乎没有收获。但是，某些类在JVM中“非常特殊”，但没有语言语法功能，仍然感到难闻。

反射

请！为什么在地球上必须如此冗长？为什么Java（Java语言）不能更加动态？我不是在要求Smalltalk-一种动态的功能，但是反射不能像语法糖那样以某种方式内置到语言中吗？

Java语言应允许特殊的语法进行反射

当然，可以在库级别上实现一些缓解。 jOOR就是一个例子。还有很多。

介面

Java中的接口总是感觉很奇怪。具体来说，使用Java 8的扩展方法，随着它们靠近抽象类，它们开始失去生存的权利。当然，即使使用Java 8，主要区别也在于类不允许多重继承。接口可以–至少，它们允许规范（抽象方法）和行为（默认方法）的多重继承，而不是状态的继承。

但是他们仍然感到怪异，主要是因为它们的语法与类不同，而它们的功能却在融合。 lambda专家组为何决定引入默认关键字？如果接口允许使用抽象方法（如今天）和具体方法（防御器方法，扩展方法），为什么接口的语法不能与类相同？我没有运气就问过专家组： http : //mail.openjdk.java.net/pipermail/lambda-dev/2012-August/005393.html 。不过，我还是希望……

适当时，接口语法应与类语法完全相同

这包括静态方法，最终方法，私有方法，程序包私有方法，受保护的方法等。

默认可见性

默认可见性不应通过缺少private / protected / public关键字来指定。首先，在类和接口中无法用相同的方式处理这种缺失。然后，它不是很可读。

默认可见性应通过“包”或“本地”或类似关键字指定

文字

这将是日常工作中的绝佳补充。

应该有列表，映射，正则表达式，元组，记录，字符串（改进），范围文字

我之前已经在此发布过博客： http : //blog.jooq.org/2012/06/01/array-list-set-map-tuple-record-literals-in-java/ 。在这里找到了Brian Goetz在lambda-dev邮件列表中提到的一些想法： http : //mail.openjdk.java.net/pipermail/lambda-dev/2012-May/004979.html

#[ 1, 2, 3 ]                          // Array, list, set
#{ 'foo' : 'bar', 'blah' : 'wooga' }  // Map literals
#/(\d+)$/                             // Regex
#(a, b)                               // Tuple
#(a: 3, b: 4)                         // Record
#'There are {foo.size()} foos'        // String literal

我会加

#(1..10)                              // Range (producing a List)

最后

方法，属性，参数，局部变量，都可以声明为“最终”。在许多方面，不变性是一件好事，应予以鼓励（我很快会在博客中介绍）。其他语言（例如Scala）区分“ val”和“ var”关键字。除了那些其他语言令人印象深刻的类型推断功能之外，在大多数情况下，val比var更可取。如果要表达可修改的变量，他们仍然可以使用“ var”

Final应该是成员，参数和局部变量的默认行为

覆写

意外重写方法很危险。其他语言通过在覆盖上引起编译错误来解决此问题

应该引入重写关键字以显式重写方法

可以将某些Java编译器（例如Eclipse编译器）配置为在缺少java.lang.Override批注时发出警告/错误。但是，这实际上应该是关键字，而不是注释。

模组

依赖管理是Java的噩梦。还有另一种语言可以根据模块构建编译单元： Fantom 。 Stephen Colebourne（JodaTime的家伙）是Fantom的忠实粉丝，并在Devoxx上发表了演讲。他还不时发布有关Fantom的博客： http : //blog.joda.org/search/label/fantom

编译单元应以“模块” / jar文件的形式表示

当然，这会使Maven过时，因为Java编译器已经可以更好地处理依赖关系。

变量和泛型

来吧。 @SafeVarargs ?? 当然，由于泛型类型擦除，这永远无法完全正确解决。但是还是

不应有泛型类型擦除

元组和记录

我真的认为这是Java缺少的东西

元组和记录应该有语言支持

Scala集成了最多22个元组，.NET支持最多8个元组。这在Java语言中也是一个不错的功能。具体来说，记录（或结构）将是一件很不错的事情。如前所述，元组和记录也应使用文字。遵循以下原则：

#(a, b)                               // Tuple
#(a: 3, b: 4)                         // Record

编译器

远远超出添加一些注释处理的编译器API会很好。我很希望能够扩展Java语言本身。我想将SQL语句直接嵌入Java代码中，类似于可嵌入PL / SQL中的SQL。当然，此类SQL代码将由jOOQ之类的库支持。

编译器API应该允许任意语言扩展

当然，这种改进的编译器API应该以一种自动完成，语法突出显示和其他功能在Eclipse之类的IDE中自动运行的方式来完成，因为编译器扩展将能够向IDE公开必要的工件。好，我同意，这种改进是很多梦想

类型推断

如果没有歧义，难道类型推断不能像Scala一样强大吗？我不想写下每个局部变量的完整类型。应该支持Scala的本地类型推断

运算符重载

好的，这是一个高度宗教性的话题。你们中的许多人不同意。但是我喜欢

Java应该支持运算符重载

使用操作符而不是方法可以更好地表达某些库操作。想想BigInteger和BigDecimal的冗长冗长的API。

添加评论！

当然，缺少lambda和扩展方法，并且泛型也被删除。尽管后者永远不会修复，但是第一个将在Java 8中运行。因此，请原谅Sun和Oracle，让我们等了很长时间等待lambda。

参考： Java，如果这是我们的JCG合作伙伴 Lukas Eder在JAVA，SQL和JOOQ博客上提出的更好的世界。

翻译自: https://www.javacodegeeks.com/2013/02/java-if-this-were-a-better-world.html