Hacker News Reader

Comment by winterbe | Hacker News Reader

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/

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.

> 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.

Ok, fine. That's just what I got from the quoted text. But I see that was wrong.

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.

Maybe in 15 years Java will finally get pattern matching, but it's never getting higher kinded types.

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 [2]: http://openjdk.java.net/jeps/305 [3]: http://openjdk.java.net/jeps/309

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.

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.

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.

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.

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.

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.

wow, after all these years, the Java syntax for

print(fetch("https://winterbe.com"))

is still this behemoth:

var request = HttpRequest.newBuilder() .uri(URI.create("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?

you can put all that in

print and fetch methods and both of those would be equivalent.

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.

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.

Almost nobody uses the standard lib for http in practice. Just use Unirest/OkHttp/SpringBoot then it’s trivial. SpringBoot is the best framework that I have worked with regardless of language. It covers most use case out of the box and everything is still completely configurable.

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.

This is really a really weird overdesigned API. Maybe I don't understand the purpose of it but it seems like an excessive use of design patterns.

Why would you need a Builder method on a static object to create a request object? Oh well, let me rephrase that: First you instantiate a Builder object that you need to call the create method on to get a request. Makes no sense to me.

What not make HttpRequest a concrete class and just instantiate it? If there's any good reason for that design please enlighten me.

Many use cases want to make a whole lot of pretty similar (URI, creds, method) requests that vary only in a single way ( e.g. a POST parameter) or don't vary at all (e.g. polling).

A builder is a convenient way to wrap up those common settings so that they can be handed to other parts of the code that don't care about them/want to override specific parts and leave the rest in common.

Now, there are other ways to do that (instantiating a concrete class with common settings and mutable fields for customizations in a function, and then passing references to that function to everything that wants the common-config-defaulted output object). The choice between that kind of strategy (or an instantiate-and-freeze-early and pass your mutators in, or a refactor-all-your-code-to-not-mutate strategy etc...) and a builder pattern is a subjective and debatable one. But the approach taken here is certainly defensible.

Reply on news.ycombinator.com