文中就寫了… local-variable type inference…像是 Scala、Kotlin 那樣吧！

應該不行！！

通常你會將 Java API 裡需要傳 .class 的 method 加上 kotlin reified extension method

第一個是說發展不夠快吧，而且都比較偏大廠制定規格。

原來如此

第二個還是會檢查，你不能寫 url.foo() 這種程式，會編譯不過。

那可以這樣寫嗎？

var url = new URL("http://openjdk.java.net");
...
url = new Scanner(conn.getInputStream(), "UTF-8");

第一個是說發展不夠快吧，而且都比較偏大廠制定規格。 第二個還是會檢查，你不能寫 url.foo() 這種程式，會編譯不過。

We need to do a lot more to modernise; to get you to that world of cloud and microservices and serverless. Because the reality is EE is the bedrock of mission critical systems; it does power enterprise. And if we look at why it isn’t getting us there it is pretty self evident. Is it open? No, it’s a vendor consortium, last time I checked those aren’t that open. Is it nimble? Well is shipped four years ago, that’s not very fast. We’re going to change everything about this.

將來可以透過 Java EE 來開發免伺服器的雲端服務，不用依靠某廠商 (指的是 AWS？)

// Java 9
URL url = new URL("http://openjdk.java.net");
URLConnection conn = url.openConnection();
Scanner scanner = new Scanner(conn.getInputStream(), "UTF-8");

// Java 18.3
var url = new URL("http://openjdk.java.net");
var conn = url.openConnection();
var scanner = new Scanner(conn.getInputStream(), "UTF-8");

感覺這樣的寫法不是很好，沒有強型別的檢查：(學 javascript 的 ?)

URL url = new Scanner(conn.getInputStream(), "UTF-8"); //complier error

var url = new Scanner(conn.getInputStream(), "UTF-8"); //pass !?

每個人有自己的repos, 然後用maillist交換patch這樣xd 類似古早魔改maple/windtop那樣吧...

開大絕:

     Map<Integer,String> map = Map.of( //
         1, "a", //
         2, "b", //
         3, "c", //
         4, "d");

不過我覺得 Intellij 之後的 format 會支援 Map.of 吧

有些老一輩不喜歡這種中央集權的,

呃... TFS 和 Subversion 之類的才是中央集權吧...

喜歡用maillist之類的

根本不想用版控？

有些老一輩不喜歡這種中央集權的, 喜歡用maillist之類的

intellij 如果直接給值不是會有 k, v 的提示？哈

key, value要輪流用啊... IDE自動format會看不出哪個是key哪個是value

因為大家都轉 kotlin 了

API 已經提供到 10 個 pair 的 of() overload 了，這還不夠嗎？

會放 10 個 pair 以上的 map literal ? 我覺得程式要 refactor 了

原來 Linus Torvalds 也有在用 GitHub1 XD

一種心死的概念

可以理解用library完成就不用改語法。但是 java9 的版本還是不太好用啊。

補充一個java9 對map比較好用的版本

     import static java.util.Map.entry;

     Map<Integer,String> map = Map.ofEntries(
         entry(1, "a"),
         entry(2, "b"),
         entry(3, "c"),
         ...
         entry(26, "z"));

但是多層下還是醜醜的..XD

但都沒人再提 multiline string 了QQ

對呀光要跑就要加一堆新參數設定....好麻煩

感覺舊的程式在9跑蠻多地方要注意的, 連intellij都有問題xd

能夠用 library 完成的功能就不要加語法啦。

這是 kotlin 從 scala 學到的教訓。

Much of the benefit of collection literals can be gained by providing library APIs for creating small collection instances, at significantly reduced cost and risk compared to changing the language. For example, the code to create a small Set instance might look like this:

但大概能理解，能用現存語法解決的地方，實在沒必要加個新的語法定義，除非真的效益差太多了。

之前 Sun 某個 Java 傳教士就曾在某個研討會投影片中靠北過了，反正他的大意就是「你們這些人總是覺得演化 Java 時這好哪好，其實才沒你們想的這麼簡單，我們要考慮的情況可多著嘞」…XD

之前有相關 JEP:

• JEP 186: Collection Literals1
• JEP 269: Convenience Factory Methods for Collections2

不在語法層級支援的原因可能是這一段吧:

In the past, there have been a few proposals floated to change the Java programming language to support collection literals. However, as is often the case with language features, no feature is as simple or as clean as one might first imagine, and so collection literals will not be appearing in the next version of Java.