在1996年至2002年之間，我用Java編寫了成千上萬行代碼。我用Java 1.0到Java 1.4編寫了Web框架，電子表格以及更多內(nèi)容。

與90年代中期（預模板）的C ++相比，Java是一種完全令人驚奇的語言。 JVM是所有計算機語言的最佳運行時。

漫長的奇特之旅

從2002年開始，我開始做C＃。 然后是露比 然后是Scala。 一些Haskell，最近，我做了很多Clojure。

因此，我今年完成的Java 1.5 / Generics數(shù)量非常有限。

有一個Java演出

今年，我參加了一場演出，編寫了一些非常有趣的代碼（編寫了一個編譯器）。 但是，客戶是一家Java商店。 該項目已經(jīng)具有Java基礎。 客戶堅決認為該項目全部用Java來完成……不是Scala……不是Clojure……不是JRuby，而是Java。

因此，在過去的6個月中，我花了數(shù)千行Java代碼。 我已經(jīng)了解了Java在過去10年中的發(fā)展情況，這令人震驚。 令人震驚的Java變得多么糟糕。

基本上，Java毫無意義。 據(jù)我所知，泛型將給定程序的總字符數(shù)增加約20％-30％。 盡管Scala的類型（帶有類型推斷）與Ruby相比是純正的（在我看來，陪審團無法確定Scala的類型系統(tǒng)的重量與其相對于類型較少的Clojure的價值）。我可以認為泛型不值得在類型檢查與Java 1.4的邊際改進之間進行。

因此，我將介紹我認為可以使Java更好而又不會破壞語言的東西。

這不是“ Scala更好的帖子”

請注意，該帖子不是“ Scala更好”的帖子。 盡管帖子中的某些想法來自Scala，但我認為Scala（或Clojure）不能替代Java。 Scala只是一種語言，我已經(jīng)看到大量的Scala濫用。

此外，我認為Scala在很大程度上已經(jīng)遭受了Java所遭受的同樣的痛苦（增加了語言的權(quán)重和復雜性（主要是通過Scala的類型系統(tǒng)）來解決邊際問題），考慮到兩種語言，這不足為奇的血統(tǒng)。

有些東西可能是在JDK 8中提出或提出的

這些是我的想法。 我不是JCP地區(qū)的球員。 感謝與Sam Pullara的出色午餐，我了解Java 8中的lambda。 但是我沒有處理太多的JCP通信，因此JCP提案可能涵蓋了這些想法。

默認公開

除非有明確的可見性級別，否則將所有聲明默認為public 。 是的，我知道這會破壞現(xiàn)有的一些代碼，但是讓我們將默認值設置為正確的值即可。

為什么？ 由于我們的代碼中包含的噪聲越少，信號越突出。

最后一個表達式是返回值

信號變得更有價值的另一個地方不再需要return關(guān)鍵字。 最后一個表達式成為返回值：

int plusOne(int x) {x + 1;}

僅當方法中沒有return語句時才適用。 因此，如果您打算將return用于控制流編程，則必須明確。 但是對于小的，簡單的方法，擺脫return意味著更少的視覺噪音。

塊表達式

花括號中的任何內(nèi)容都是一個塊表達式，而不是一個塊語句。 這意味著如果花括號內(nèi)容可以是一個表達式，則將其視為此類。

String s = {var d = new Date();"The current date is "+d; }

某種類型推斷

我想看到自動分配推論。 基本上：

var name = "David"; // it's a String, duh

我們不需要使var為關(guān)鍵字。 基本上，類型var成為“推斷類型”類型。

和基本的左側(cè)參數(shù)類型推斷（請注意，IntelliJ已經(jīng)使用此語法）：

List<String> stuff = new ArrayList<~>();

如果返回值只有一條路徑（除了方法的最后一行，沒有return語句），則返回類型推斷：

plusOne(int x) // it's an int{x + 1;}

以上所有更改都可以使用編譯器已知的數(shù)據(jù)來完成。 無需花哨的算法。 只是減少了程序中重復單詞的數(shù)量……而通過泛型類型推斷，無論如何，IDE都已經(jīng)在IDE中顯示了這些內(nèi)容。

更好的平等測試

將===添加為equals方法的別名，但要求===的右側(cè)與右側(cè)協(xié)變。

另外，將!==添加為!equals 。

具有元數(shù)據(jù)的簡單，不可變的數(shù)據(jù)結(jié)構(gòu)

用Java表示簡單數(shù)據(jù)是一個巨大的痛苦。 是的，IDE在創(chuàng)建getter / setter方面大有幫助。 但是最終，我們的許多程序都包含原始數(shù)據(jù)。 因此，我建議向Java添加內(nèi)部數(shù)據(jù)結(jié)構(gòu)。

這些是Scala的案例類與Clojure的元數(shù)據(jù)工具的組合。

struct只能在頂級公共類中。

例如：

public class MyStuff {struct Name(firstName = "David", lastName = "Pollak", age = 49, Date birthday = null)public static boolean funWithNames() {var archer = Name("Archer").age(10);var tessa = Name().firstName("Tessa").lastName("kitten").age(1);assert(tessa.age === 1);assert(tessa.getAge() === 1);archer !== tessa;}public static void metaData() {var david = Name("David", "Pollak");Name d2 = david.setMeta("geek", "true");assert(david === d2); // metadata not part of equality testingassert(david != d2); // object instances not the sameassert(david.getMeta("geek") === null);assert(d2.getMeta("geek") === "true");} }

你從struct得到什么？

• 不可變對象的創(chuàng)建，無需使用每個參數(shù)的new且具有位置構(gòu)造函數(shù)，以及簡單的名義上的創(chuàng)建和新值鏈接。
• 與每個struct相關(guān)聯(lián)的元數(shù)據(jù)的Map<String, String> 。
• 每個字段的默認值。 這允許添加字段，并且?guī)в懈郊訁?shù)的庫的新版本不會破壞訪問舊版本的代碼。
• 一個toString方法，它輸出字段名稱和值。
• 一個正確實現(xiàn)的equals方法，可以通過對空字段的適當處理來進行所有字段的比較。
• 計算哈希碼的hashCode方法（如果已知所有字段都是不可變的，則應將其緩存）。
• 字段級訪問器方法。
• 每字段復印機： field(param)這允許創(chuàng)建具有新值的新實例。 元數(shù)據(jù)已復制。
• 每個struct都有大量的元數(shù)據(jù)，包括字段名稱列表，每個字段的類型。 該元數(shù)據(jù)可以用于快速，高效，自動生成的一組序列化器/反序列化器（例如JSON，JDBC，XML）。

另外，請注意定義的語法。 如果可以，則推斷類型。

對于每個包含struct類，將有一個ClassName.struct接口。 該接口由所有struct實現(xiàn)，并且該接口包含所有共享字段。 例如：

class People {struct Parent(String name = null, List<People.struct> kids = null)struct Kid(String name = null, Parent parent = null)String getName(struct person) {person.name;} }

注解也可以完成很多事情（例如，增強struct的JSON可序列struct等）

但是，通過輕量級的方法在語言級別定義數(shù)據(jù)模式，可以使代碼更快地編寫，更易于維護和更具可讀性。

精鑄

Java轉(zhuǎn)換過于冗長且容易出錯。 使用if / instanceof / cast模式需要大量代碼，并且非常容易出錯，因為該類被指定了兩次……一次在測試中，一次在強制轉(zhuǎn)換中。

我們可以從Scala借用我最喜歡的功能之一：模式匹配，但是只需執(zhí)行以下操作：

String testIt(Object o) {switch o {String s: s;Number n: "It's a number: "+n;Date d if d.millis() > 0: {var formattedDate = formatDate(d);"It's a modern date: "+formattedDate;}default: "No clue";} }

好吧...我們有什么？ 該類已測試。 如果該類是匹配項，則將其分配給變量（僅具有行范圍）。 接下來，運行警衛(wèi)，看看是否應該采取這種行動。 如果是這樣，請運行:右側(cè)的表達式。

請注意，這種形式的切換是一種表達方式，而不是一條聲明。 另外，請注意，不會掉線。

那么，這還能使事情變得更容易嗎？

String whatSize(int i) {switch i {v if s < 10 : "small";v if s < 100 : "medium";default: "large";} }

我們可以做的下一件事是將其應用于struct s（不，這不是模式匹配）：

String aboutPerson(People.struct p) {switch p all {Parent p: "A parent named "+p.name+" #"+p.kids.size();Kid k: "A kid with "+(k.parent.kids.size() - 1)+" sibs";} }

express后面的all關(guān)鍵字表示必須匹配。 如果將新struct添加到類中，這將很有用，因為所有在該struct上打開的位置都將標記一個編譯時錯誤。

不變的收藏

Java迫切需要一個出色的不變集合包。

基本上，該軟件包是Clojure出色的Map和Vector類的純復制品。 我們不需要很多花哨的Scala風格的收藏。

不實現(xiàn)java.util.List或java.util.Map不可變集合。 基本上，這些集合將是獨立的。

結(jié)合JDK 8 lambda，我將在Scala和Clojure的集合操作方面得到我的一大堆愛。

所以你有它

所以你有它。 我認為以上內(nèi)容將使Java更易于處理語言。 它將減少冗長。 它將允許將數(shù)據(jù)作為相當常見的數(shù)據(jù)進行處理，尤其是在編寫將數(shù)據(jù)編組進出系統(tǒng)的服務時。

上述更改將減少Java的冗長性，而不會顯著降低Java的“講述故事”代碼。 而且，是的，有可能編寫相當難以理解的Scala代碼。 我們不想去Scala去的地方。

我還想看什么？ 按名稱調(diào)用參數(shù)（我不知道它們是否會成為lambda的一部分）。 屬性。 看看是否有可能在Java中進行某種形式的全局類型推斷也將很有趣。 但是所有這些東西都是另一天。

繼續(xù)前進！

參考： Java： DPP博客博客中來自JCG合作伙伴 David Pollak 的本地最低語言標準 。

翻譯自: https://www.javacodegeeks.com/2013/10/java-a-local-minimum-language-wise.html

總結(jié)

以上是生活随笔為你收集整理的Java：本地最小语言的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。