
JDK 15 - aib
https://jdk.java.net/15/
======
kentosi
I'm so happy that we finally have multiline text blocks in Java:

    
    
      String query = """
                   SELECT "EMP_ID", "LAST_NAME" FROM "EMPLOYEE_TB"
                   WHERE "CITY" = 'INDIANAPOLIS'
                   ORDER BY "EMP_ID", "LAST_NAME";
                   """;
    
    

It's one more step closer to scala/kotlin/etc.

~~~
60secz
Shame they don't actually include templating inside of the string literal.
Still have to append with a lot of tokenized replaces. Since they've committed
to no formatting in the literal section, will be interesting to see if they
eventually support a syntax like python's f-strings: f"""${foo}"""

~~~
carimura
Maybe you're looking for String::formatted?

Directly from
[http://openjdk.java.net/jeps/378](http://openjdk.java.net/jeps/378):

    
    
      Another alternative involves the introduction of a new instance method, String::formatted, which could be used as follows:
    
      String source = """
                      public void print(%s object) {
                          System.out.println(Objects.toString(object));
                      }
                      """.formatted(type);

~~~
mumblemumble
I'd still prefer honest-to-goodness string interpolation. Formatting functions
with positional placeholders need a linter to be kept (vaguely) maintainable,
and I suspect that formatting functions with named placeholders would be
difficult to make acceptably ergonomic or performant in Java.

~~~
thangalin
> I suspect that formatting functions with named placeholders would be
> difficult to make acceptably ergonomic or performant in Java

yamlp performs string interpolation from YAML files:

[https://bitbucket.org/djarvis/yamlp/](https://bitbucket.org/djarvis/yamlp/)

I reuse my library in my text editor:

[https://github.com/DaveJarvis/scrivenvar/](https://github.com/DaveJarvis/scrivenvar/)

The text editor can interpolate strings in a variety of contexts (such as
Markdown, R Markdown, XML, and R XML documents):

[https://www.youtube.com/watch?v=u_dFd6UhdV8](https://www.youtube.com/watch?v=u_dFd6UhdV8)

As far as I can tell, there is no performance degradation from the recursive
interpolation; the editor reads, interpolates key/value pairs, and substitutes
the resulting values into R Markdown documents riddled with up to a thousand
simple formulas in about 600 milliseconds (on my desktop computer).

Also, the editor provides a way to maintain the interpolated variables in a
tree-like view:

[https://github.com/DaveJarvis/scrivenvar/blob/master/README....](https://github.com/DaveJarvis/scrivenvar/blob/master/README.md#screenshots)

The substituted values appear in the preview pane in their final form. This is
all real-time and pure Java.

------
mabbo
I've got a few very specific use cases where I'm going to be so glad to have
sealed classes[0]. Oddly not mentioned in the release notes, but they're like
a final class, except you can say "These classes are allowed to be subclasses
of this class".

Why is that useful? Because now you can do a switch statement that matches on
type:

    
    
        int getCenter(Shape shape) {
            return switch (shape) {
                case Circle c    -> ... c.center() ...
                case Rectangle r -> ... r.length() ...
                case Square s    -> ... s.side() ...
            };
        }
    

As long as Shape is sealed, the compiler can be confident that these are all
the possible subclasses of Shape.

[0][http://openjdk.java.net/jeps/360](http://openjdk.java.net/jeps/360)

~~~
benmller313
Maybe your example is just too simple, but why would you do that instead of
overriding the getCenter method in each subclass?

~~~
estebank
You're right that in the simplified example you have probably nicer
alternatives, but having sealed clases where you know that others can't expand
has its benefits to design some nice APIs, like state machines and type safe
builders.

The benefits of enums (as these are referred to in some languages) is that
after the safe downcast you have access to the fields and methods of the
specific type just by invoking them.

Pattern matching also makes this construct even nicer to use (and I would
argue that having one without the other is worse than not having either), but
that doesn't seem to be included in the language yet, very probably for good
reasons (I just don't follow Java development closely so I don't know about
them).

~~~
jdc
Pattern matching is available as a preview feature:
[https://openjdk.java.net/jeps/375](https://openjdk.java.net/jeps/375)

------
mjb
Nice to see ZGC marked as production-ready. With Shenandoah, ZGC, and G1 the
options for garbage collection in Java are so much better than they were just
a couple of years ago. Even better, the need to do a bunch of brittle tuning
and tweaking has mostly gone away.

Java still makes the GC work harder than other languages. In some of my
testing, idiomatic "microservice" Java code makes ~10x as much garbage per
request as equivalent idiomatic Go code. Some of that is the language, and
some is just that libraries and frameworks are super allocation-heavy. If the
ecosystem can tighten that up, then these great GCs will have even more
impact.

~~~
darksaints
Fully agreed about java libraries and frameworks being more allocation-heavy
than they need to be. The problem is that the libraries and frameworks are
built using the abstraction capabilities it has, and in Java, those
abstraction capabilities are very allocation heavy.

I'd love to see a jvm or graal implementation of ASAP memory management. The
idea generally being having extremely aggressive analysis on your code,
reducing heap allocations where possible, statically managing objects where
they can provably infer object lifetimes, reference counting everything left
over that provably can't result in cycles, and then garbage collecting
everything else.

~~~
specialist
_" ASAP memory management"_

Do you mean this?

ASAP: As Static As Possible memory management

[https://www.cl.cam.ac.uk/techreports/UCAM-CL-
TR-908.pdf](https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-908.pdf)

~~~
darksaints
Yes. To be clear though, the idea is already hard enough to implement, but it
would be incomprehensibly hard in the JVM ecosystem. The JVM directly
implements allocation decisions, but the analysis necessary for ASAP is done
mostly in higher level reprensentations of code, and there is no direct API in
java byte code to tell the JVM to statically allocate or reference count a
specific object.

~~~
thu2111
Hardly incomprehensibly hard. It's been done already, it just never got out of
the lab into the product.

[http://codrutstancu.com/p81-stancu.pdf](http://codrutstancu.com/p81-stancu.pdf)

SVM has support for snapshots/isolates, where you can ~instantly instantiate a
new JVM with a fresh heap. If you set your GC params such that it never really
collects, you get something close to that but without the complexity.

------
specialist
I haven't been this excited about Java since JDK 1.2.

Especially Project Loom. Virtual threads will be a game changer. A return to
original Java's rallying cry of programmer productivity.

There's always been steady progress, sure. But it seems like Oracle is much
less risk adverse. Or maybe the governance changed. Or maybe Sun, IBM, other
had been holding back a lot of progress. I'd love to know the backstories. To
better inform future efforts.

Regardless, Java today is amazing and rapidly getting better.

~~~
chaostheory
Isn't much of the excitement gone due to Oracle's license for its JDK?

~~~
carimura
We hope not, and if it is, it's a misunderstanding. Java is freer and more
open than it ever has been. There are many downstream builds under open source
licenses, including one from Oracle at
[http://jdk.java.net](http://jdk.java.net)

~~~
ptx
> Java is freer and more open than it ever has been

but pron of Oracle says, a few comments over:

> No one offers free LTS ... those "free LTS" distributions you should know
> that you're using a JDK that's not fully maintained ... Maintaining a JDK is
> a lot of work ... For real support for an old version you must pay.

So it doesn't sound like it's really free. If the free version doesn't get
security updates you can't really use it in practice.

------
geerlingguy
/me nervously glances at all the production infrastructure I manage that's
still on JDK 7 or 8.

I've just recently been able to upgrade some things to JDK 11.

~~~
skrebbel
I'm clearly missing something, but why is this so hard? I thought Java made a
point of being fully backward compatible, both at the source level and the
binary level (.class/.jar)? Is that true? If so, why is upgrading to a later
jdk more work than, well, installing the newer version?

~~~
tandr
(not gp) It is about stability, and that magical ephemeral "Something". In
software, like JDK or OS, "Something" does change all the time with bug fixes
and maybe even just a different builds. Jump from 8 to 11 has a lot of
Somethings changed, and transition is not always painless.

I have tests that use JSON serialization and deserialization (and then some),
and they pass perfectly fine on Java 8 runtime, but fail in exactly same place
on Java 11, without recompilation. I have spent some non-zero time trying to
get to the bottom, but so far without much luck.

~~~
correct_horse
gson uses reflection to serialize types, including standard library types,
which are not guaranteed to have the same fields from one release to another.
Presumably the people who write the jdk realized this potential source of bugs
and tried to prevent it from happening, meaning fewer ambiguities about what
changes are breaking at the expense of breaking gson (and probably others).
see:
[https://github.com/google/gson/issues/1216](https://github.com/google/gson/issues/1216)

------
voodooranger
> Removal of Nashorn JavaScript Engine

anybody know why a javascript engine was ever included in core java in the
first place? seems... niche. and yet core java never included a simple web
server (officially).

~~~
sjwright
It’s great for web development when I want the same code to run client side
and server side.

~~~
koreth1
I mostly don't work on web stuff, so maybe this is a dumb question, but can
you give an example of what benefits that gives you? What code do you want to
run in both places?

In my limited experience writing web code, the client side concerns itself
with rendering and user interaction, the server side concerns itself with
efficiently supplying dynamic data to the client, and other than request
payload definitions the two have no logic in common.

~~~
sjwright
The most straightforward example I can offer is my custom mark-up parser for
formatting text. I wrote this parser in Javascript where it runs live in the
browser, but when the final text is submitted it's parsed on the server side
for security and replicability reasons.

Of course I could rewrite it in another language, but with Nashorn I don't
need to. I can execute many hundreds of lines of Javascript with around four
lines of utterly boilerplate Java. And _it works perfectly._ I don't need to
worry about edge cases or dealing with subtle variations in regular
expressions (don't at me) and other string parsing nuances.

I'm just a sole developer; I don't have minions. If I _had_ to rewrite it
today I'd probably look at a transpiling approach, but even then, defensive
text manipulation tends to be edge-casey at the best of times.

(Also note that my priority here is browser performance, where it's running
continuously on hundreds of clients simultaneously—often budget smartphones
with limited CPU power. On the server it only has to run once per submit and
the CPU cost on the server is beyond trivial.)

~~~
koreth1
Makes sense. Thanks for the example!

------
karmakaze
For some context--I had to look it up for myself

    
    
      Release         GA Date           Premier Support Until
      11 (LTS)        September 2018    September 2023
      12 (non‑LTS)    March 2019        September 2019
      13 (non‑LTS)    September 2019    March 2020
      14 (non‑LTS)    March 2020        September 2020
      15 (non‑LTS)    September 2020    March 2021
    

Ref [https://www.oracle.com/java/technologies/java-se-support-
roa...](https://www.oracle.com/java/technologies/java-se-support-roadmap.html)

------
CydeWeys
It's pretty hard to believe that I've been writing Java now for over two
decades (not continuously mind you, but I'm not currently in a gap either) and
with no signs of slowing down.

I've been writing Java for longer than I've been _driving_ , and way longer
than drinking actual java. Geez. There's a certain fluency I have with this
language that I don't have with any other language, not even
Python/PHP/JavaScript/C#, all languages that I have 1k+ hours experience in.

~~~
touisteur
Recently been going back to it a lot, I feel the same. The code flows right
out my hands, I can see all the refactor paths and still learning new things
with it (recently AOP, doing new optimized next-level introspection stuff,
having fun with mappedbytebuffers... I know I'm late to the party but hey...)

------
x87678r
> Remove the Solaris and SPARC Ports

[https://openjdk.java.net/jeps/381](https://openjdk.java.net/jeps/381)

Wow this is the end of an era.

------
suyash
Also check out Tribuo - Machine Learning library in Java announced today
during the keynote : [https://tribuo.org](https://tribuo.org)

------
rubyist5eva
When is the next LTS release? I'm stuck on 11 until then.

~~~
suyash
in 2 years with Java 17

~~~
lewapkon
They release a new major version every 6 months. Java 17 is coming next year
in September.

~~~
suyash
Thanks for the correction

------
ducktective
Anyone has any idea about the current state of JavaFX?

~~~
suyash
It's being developed in the open source now as it is out of JDK -
[https://openjfx.io](https://openjfx.io)

------
chromedev
Does this include JRE? I've noticed that the OpenJDK Docker Hub images and
variants have a hard time releasing the latest JRE.

~~~
hocuspocus
Oracle doesn't offer a standalone JRE anymore. Several OpenJDK distributions
do (Adopt, Azul, RedHat, Debian, ...) and I assume the version 15 builds will
be available soon.

------
ramon
I worked with Java in the past so glad NodeJS arrived and Golang..
productivity is the key.

~~~
The_rationalist
You should give a try to Kotlin then

~~~
ramon
I was going to but then since Android also accepts Java I gave up on the
Kotlin since I'm confortable with Java already, but I do like a lot golang
recently I've also developed in C++ and I'm frankly learning a lot of golang
and liking each day more and more.. it's fast to process and there's no hick-
ups like in NodeJS, it's like the best of C++/Java with the best from NodeJS
and no hick-ups at least for now.. I'm very impressed with the golang
performance it's outstanding and what I got impressed too is that VSCode
installs all the Golang extensions so it seems like I have all the typo
verification on the fly without compiling remembering me a lot of Eclipse days
with Java.. Good old compiling.. haha. We never get away from compiling.. I
think Golang is under-marketed it deserves a lot of attention.

------
leoh
It feels like there's a new JDK every five minutes these days

~~~
alphager
Every 6 months, actually.

In practical terms, unless you want to test out Java features (which can be
removed with the next release), you only need to track the LTS-releases every
3 years and actively upgrade every 6 years to stay on a supported version.

~~~
leoh
The average cadence, over the lifetime of Java, is actually something like a
new version every 2.5 years. They have really ramped up.

~~~
carimura
Up until 10, releases were feature-driven, meaning, based around the delivery
of something when it was done like Generics in 5, Lambdas in 8, modularity
system in 9, etc. With 10 and on, Java is now a time-based release cadence,
every 6 months in September and March, like clockwork. What's ready goes in,
what's not waits for the next train.

~~~
leoh
I'm not sure this is ideal for users, no? Each time something is deprecated
(e.g. nashorn in JDK15), I have to go check the long term support schedule,
etc. And I have to imagine it's much harder to maintain, creating the
potential for patchwork fixes across various JDKs.

