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語言應允許特殊的語法進行反射

當然，可以在庫級別上實現一些緩解。 喬是一個例子。 還有很多。

介面

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 / SQLSQL。 當然，此類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

java更好的語言

總結

以上是生活随笔為你收集整理的java更好的语言_Java，如果这是一个更好的世界的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。