5 ms·

I wrote a user friendly version of the release notes. Maybe this is useful to someone: https://winterbe.com/posts/2018/09/24/java-11-tutorial/ https://winterbe

I wrote a user friendly version of the release notes. Maybe this is useful to someone: https://winterbe.com/posts/2018/09/24/java-11-tutorial/ https://winterbe.com/posts/2018/09/24/java-11-tutorial/

akerro 8y ago
I saw that on reddit and downvoted it, title says it shows new Java 11 things, so I expected dynamic class-file constants example and explanation, ZGC tuning and showcase, not "var" from Java 10 and HTTP client from Java 9... Your post describes some minor syntax changes and a few new base methods, doesn't cover release notes.
msilb 8y ago
Looks like Java is slowly but surely catching up to Scala in terms of API, syntactic sugar etc. I wonder if some people disliking Scala compiler slowness would consider the switch back to Java.
- kod 8y ago
  Maybe in 15 years Java will finally get pattern matching, but it's never getting higher kinded types.
  - carey 8y ago
    The first step towards pattern matching will be previewed in JDK 12[1], as a Kotlin-like switch statement, to form the basis of pattern matching[2] together with changes already in JDK 11[3]. I think it will be more like 15 months than 15 years. I don’t expect higher kinded types any time soon, though. [1]: http://openjdk.java.net/jeps/325 http://openjdk.java.net/jeps/325 [2]: http://openjdk.java.net/jeps/305 http://openjdk.java.net/jeps/305 [3]: http://openjdk.java.net/jeps/309 http://openjdk.java.net/jeps/309
    - kod 8y ago
      If it doesn't have what 305 calls "deconstruction patterns" and "nested patterns", it's not really pattern matching. I'll be impressed if those make it in within 15 months.
- pjmlp 8y ago
  I only played with Scala but never found a good business reason to actually use it. Personally I rather not be in the bleeding edge and not having to deal with interop issues, or missing tooling.
  - pkolaczk 8y ago
    The whole point of Scala are its advanced features like implicits, higher kinds and macros, and not just syntactic sugar like in Kotlin. Therefore you won't appreciate Scala by just shortly playing with it. Also in 2018 interop issues or missing tooling problems are long gone.
    - pjmlp 8y ago
      I am well aware of those features. Only Scala shops can make effective use of them, and I am yet to do a project where Scala libraries were even considered.
- pkolaczk 8y ago
  Far from it. When Java gets pattern matching, Scala will have moved to version 3.0 with trait parameters, union and intersection types, implicit functions, type lambdas, cleaner macros and many more. Also, Scala compiler slowness is virtually not a problem any more since introduction of Zinc 1.0. During development, I get repeatedly compile times around 2-5 seconds on Scala 2.11, and recent Scala 2.12.x / 2.13.x showed to be typically 30%-100% faster than 2.11.x.
singularity2001 8y ago
wow, after all these years, the Java syntax for print(fetch("https://winterbe.com") https://winterbe.com")) is still this behemoth: var request = HttpRequest.newBuilder() .uri(URI.create("https://winterbe.com") https://winterbe.com")) .GET() .build(); var client = HttpClient.newHttpClient(); HttpResponse<String> response = client.send(request, HttpResponse.BodyHandlers.ofString()); System.out.println(response.body()); !? One can argue about taste, but how can anyone defend such uuuuuuuuurgh?
- dominotw 8y ago
  you can put all that in print and fetch methods and both of those would be equivalent.
- enitihas 8y ago
  Much better than HttpUrlConnection though. As an aside, the http client API seems really well thought out, supporting all sorts of common use cases for http. Once you convert the examples to some non trivial request response stuff, the new API shines. I think the job of pleasent APIs for starters is left to external libraries here.
- zbentley 8y ago
  Oddly, I almost feel compelled to. The verbosity in that code is less of the typical (and deserved) Java criticism of over-architected pattern cancer. Instead, almost all of the verbosity there is due to a refusal of the language to assume common defaults. Whether assuming common defaults or forcing people to think about that stuff is good or bad is debatable. But it's certainly far from deserving of the "uuuuuuuuurgh" of a lot of (mostly older) Java I've had to wade through.
- pjmlp 8y ago
  Yes, developers that like getting all the low level Lego pieces and are able to write higher level abstractions themselves. You should never try to learn 3D graphics programming if that basic stuff is already "uuuuuuuuurgh" for you.
- hayden592 8y ago
ofrzeta 8y ago
This is also a gem: "Because list is already immutable there's no practical need to actually create a copy of the list-instance, therefore list and copy are the same instance. However if you copy a mutable list, copy is indeed a new instance so it's garanteed there's no side-effects when mutating the original list" So you can get a "reference" to the same data where one reference gives you the data immutably while the other one lets you change it. Sounds like a recipe for subtle bugs.
- chinhodado 8y ago
  > where one reference gives you the data immutably while the other one lets you change it What do you mean, it's not like that at all. You only get back the same object (same reference) if it detects the object was immutable to begin with.
  - ofrzeta 8y ago
    Ok, fine. That's just what I got from the quoted text. But I see that was wrong.

I wrote a user friendly version of the release notes. Maybe this is useful to someone: https://winterbe.com/posts/2018/09/24/java-11-tutorial/ https://winterbe.com/posts/2018/09/24/java-11-tutorial/

akerro 8y ago

I saw that on reddit and downvoted it, title says it shows new Java 11 things, so I expected dynamic class-file constants example and explanation, ZGC tuning and showcase, not "var" from Java 10 and HTTP client from Java 9... Your post describes some minor syntax changes and a few new base methods, doesn't cover release notes.

msilb 8y ago

Looks like Java is slowly but surely catching up to Scala in terms of API, syntactic sugar etc. I wonder if some people disliking Scala compiler slowness would consider the switch back to Java.

kod 8y ago
Maybe in 15 years Java will finally get pattern matching, but it's never getting higher kinded types.
- carey 8y ago
  The first step towards pattern matching will be previewed in JDK 12[1], as a Kotlin-like switch statement, to form the basis of pattern matching[2] together with changes already in JDK 11[3]. I think it will be more like 15 months than 15 years. I don’t expect higher kinded types any time soon, though. [1]: http://openjdk.java.net/jeps/325 http://openjdk.java.net/jeps/325 [2]: http://openjdk.java.net/jeps/305 http://openjdk.java.net/jeps/305 [3]: http://openjdk.java.net/jeps/309 http://openjdk.java.net/jeps/309
  - kod 8y ago
    If it doesn't have what 305 calls "deconstruction patterns" and "nested patterns", it's not really pattern matching. I'll be impressed if those make it in within 15 months.
pjmlp 8y ago
I only played with Scala but never found a good business reason to actually use it. Personally I rather not be in the bleeding edge and not having to deal with interop issues, or missing tooling.
- pkolaczk 8y ago
  The whole point of Scala are its advanced features like implicits, higher kinds and macros, and not just syntactic sugar like in Kotlin. Therefore you won't appreciate Scala by just shortly playing with it. Also in 2018 interop issues or missing tooling problems are long gone.
  - pjmlp 8y ago
    I am well aware of those features. Only Scala shops can make effective use of them, and I am yet to do a project where Scala libraries were even considered.
pkolaczk 8y ago
Far from it. When Java gets pattern matching, Scala will have moved to version 3.0 with trait parameters, union and intersection types, implicit functions, type lambdas, cleaner macros and many more. Also, Scala compiler slowness is virtually not a problem any more since introduction of Zinc 1.0. During development, I get repeatedly compile times around 2-5 seconds on Scala 2.11, and recent Scala 2.12.x / 2.13.x showed to be typically 30%-100% faster than 2.11.x.

singularity2001 8y ago

wow, after all these years, the Java syntax for print(fetch("https://winterbe.com") https://winterbe.com")) is still this behemoth: var request = HttpRequest.newBuilder() .uri(URI.create("https://winterbe.com") https://winterbe.com")) .GET() .build(); var client = HttpClient.newHttpClient(); HttpResponse<String> response = client.send(request, HttpResponse.BodyHandlers.ofString()); System.out.println(response.body()); !? One can argue about taste, but how can anyone defend such uuuuuuuuurgh?

dominotw 8y ago
you can put all that in print and fetch methods and both of those would be equivalent.
enitihas 8y ago
Much better than HttpUrlConnection though. As an aside, the http client API seems really well thought out, supporting all sorts of common use cases for http. Once you convert the examples to some non trivial request response stuff, the new API shines. I think the job of pleasent APIs for starters is left to external libraries here.
zbentley 8y ago
Oddly, I almost feel compelled to. The verbosity in that code is less of the typical (and deserved) Java criticism of over-architected pattern cancer. Instead, almost all of the verbosity there is due to a refusal of the language to assume common defaults. Whether assuming common defaults or forcing people to think about that stuff is good or bad is debatable. But it's certainly far from deserving of the "uuuuuuuuurgh" of a lot of (mostly older) Java I've had to wade through.
pjmlp 8y ago
Yes, developers that like getting all the low level Lego pieces and are able to write higher level abstractions themselves. You should never try to learn 3D graphics programming if that basic stuff is already "uuuuuuuuurgh" for you.
hayden592 8y ago

ofrzeta 8y ago

This is also a gem: "Because list is already immutable there's no practical need to actually create a copy of the list-instance, therefore list and copy are the same instance. However if you copy a mutable list, copy is indeed a new instance so it's garanteed there's no side-effects when mutating the original list" So you can get a "reference" to the same data where one reference gives you the data immutably while the other one lets you change it. Sounds like a recipe for subtle bugs.

chinhodado 8y ago
> where one reference gives you the data immutably while the other one lets you change it What do you mean, it's not like that at all. You only get back the same object (same reference) if it detects the object was immutable to begin with.
- ofrzeta 8y ago
  Ok, fine. That's just what I got from the quoted text. But I see that was wrong.