Alice: Hello,
welcome to Liberica bar, small talks about Java and OpenJDK in an informal way. Today,
we're going to discuss the popular themes of the last week, the new release of JDK 15.
It's time to welcome the much-awaited version. And we will discuss it with a Performance
Architect at BellSoft, Dmitry Chuyko. Hi Dmitry. Thank you for coming. So,
let's discuss the highlights introduced in JDK 15. What are the main features that we can find there?
Dmitry: Well, if we speak of features, there are two
major features: two garbage collectors that are now considered production-ready.
They're both low-latency garbage collectors that perfectly work with enormously large heaps.
They're Shenandoah and ZGC, and they are supported on multiple platforms.
You have a great choice, these options, and they continue to evolve. They previously
had interesting enhancements in previous releases, and they, I'm sure, will continue to get more
enhancements in upcoming releases. If we talk about security, the important topic is, of course,
cryptography and related stuff. In this release, a new algorithm has been added for digital
signature, which is EdDSA. This is one more part of ongoing work. By adding new, more secure staff
and deprecating less secure stuff or making it non-default.
In previous releases, TLS 1.3 has been added, more algorithms were introduced.
There's no yet TLS 1.3 support for this one, but probably it will be in the nearest future.
Alice: What about
text blocks? It's one of the main features...
Dmitry: Yeah, text blocks is a language feature
that I really do like. You can embed any foreign
code or whatever, any text as a single block inside your regular Java classes. With indentation
and all that stuff. You can do templating using that embedded text. These are nice
small handy features. It is very convenient to use and to manage. So, yeah, let's just use that.
Alice: Let's just try it.
Dmitry: Yeah. That was one
of the reasons to try a preview mode of JDKs, previous ones. Now it's just a release feature.
Alice: That's cool.
And what else? Maybe, we can tell something about hidden classes, for example.
Dmitry: Yeah, there's work
going in the directions to have a more clear view of how API is structured, how it's split,
and what's allowed to do in runtime. In runtime, you can generate bytecode to derive new classes.
Previously, it has been done by using an Unsafe API. You can
derive a class and work with it as with any other regular class, which may be
not so great sometimes because it may be messed up with different
classes already existing in your runtime. It is better clearly to say, okay, we don't work with
those classes. We don't expect regular Java code to call them, but we instead have a requirement
to work with such classes using reflection to discover their methods, making a call.
All the things, but just clearly state that this is a kind of a dynamic thing
and then in such a case an older, unsafe nonstandard API is not necessary. It will be
deprecated and removed… What about deprecations?
Alice: What about removing?
Dmitry: Yeah. Removals. We like removals — less
support, right? Solaris and SPARC ports are now removed. They still exist in OpenJDK source base,
nothing is removed from there. But they are not supported, there are no releases on the platforms.
Alice: We can use the older versions, right?
Dmitry: Yes, you can use JDK 8 still or
previous JDKs. So, yeah, they're still supported. Some tiny API related to RMI, RMI activation
is deprecated. But still, all generic RMI staff is there, don’t worry. Nashorn has been removed.
It has been deprecated for a long time, no one really supports it. And we have alternatives,
good alternatives for that. Maybe a buzz thing, removal of biased locking.
Alice: Why is it a "buzz thing"?
Dmitry: Yeah. Because people really considered either to
enable or disable biased locking for performance for a long time. But really if you think about
that, if you still use Vector and Hashtable in your programs, and they still are used in some
single-threaded contexts, there's definitely something super wrong with your programs.
Alice: Okay. Got it. Well,
I think it's all about removing things, maybe we should continue about the new features...
Dmitry: There's a second incubator for a memory
access API. API that allows you to work with memory also accessible
by native libraries or just to manage native memory, as you wish to. And the API is now
extended with some VarHandle part, which is really convenient. So, yeah, it's worth trying.
Alice: And what about
thread-local handshakes and about Arm and Silicon?
Dmitry: This is kind of, as I said... Many refinements
happened during some ongoing work. Previously thread-local handshakes, an optimization for
more lightweight safepoints, have been implemented for x86 and for Arm 64.
In this release, it has been implemented for Arm 32 by BellSoft. Please use that if you use Arm 32.
You won't probably notice that, but it's there. One more ongoing change
is a process of preparation for Project Loom.
Alice: It's an
ongoing change, or we can find it in JDK 15?
Dmitry: It's a separate
project for now. It's not even proposed to target. But a lot of things must be changed for the next
big change. One of them is the implementation of DatagramSocket API,
which happened in this release. You can just use that reimplemented API or
be sure that things will work fine when Project Loom will be integrated.
Alice: What else is interesting in JDK 15?
Dmitry: One small but cool feature
is that you can now get your heap dumps in gzipped format,
which allows you to survive the heap dump of a huge heap, of really huge heaps. To save
your disc space. It is really convenient when you need heap dumps of large heaps.
Alice: And connecting there, big things: a big release
and what should we do right now. As far as I know, you're working with JEP 386 that is connected with
Alpine Linux. Could we find something in JDK 15 or it's only in the next release of the 16 version?
Dmitry: It has been proposed to target JDK 16.
We have good chances to be there, in 16. The JEP is about the integration of Project
Portola into JDK mainline, which will unify the code base and ease the process of development
for Alpine Linux support. This allows us to use the smallest
base Docker images, for example, in a case we provide JDKs for containers.
Alice: But the users
right now can download containers and use them from your site.
Dmitry: It's already supported but the final integration
is to make the code more clean, to fix potential problems and
to unify how different companies solve that problem.
Alice: So,
I think we could discuss JEP a little bit more in detail, but let's do it in the next episode.
I think it's quite an interesting theme. And what should we wait for in the 16 version?
Dmitry: Yeah,
I already started to talk about containers. A good thing for containers is to return unused memory,
uncommit it, and return it to the operating system, so the host can give it to another
container on the same machine. This now happens not just for heap but also for metaspace. And the
JEP is called Elastic Metaspace, and it's been targeted to JDK 16. Also, expect more ports,
not just Alpine Linux musl but also aarch64 for Windows. Probably, still not ‘proposed
to target’ or ‘targeted’ but a discussed one is a port for macOS on Apple Silicon,
which is really interesting. We’ve been waiting long for those new Macs to come.
Alice: Yeah. That's one of the
favorite themes of some of our Twitter followers, discussing who is the first, Microsoft or Apple.
Dmitry: Some things have already
happened for 16 that are good for the development of JDK. First of all,
of course, it is migration to GitHub and git in general. We now have cool Skara features.
They are really used from the very beginning. This is a positive experience. Also, the code base of
HotSpot has been cleaned up. It's now ready for C++ 14 features, which will help to use
standard approach, more standard approach for the development of JDK.
Alice: Should we
wait for something extraordinary in the 16 version?
Dmitry: Ah, yes. As usual!
I don't know exactly what it will be, but for sure. Some big features will be in 16.
Alice: Can you imagine what it could be?
Dmitry: I would wish it
to be Project Loom, but we'll see. As for features currently targeted, there's also Vector API,
which we now have implementations for both Intel and Arm. It will be interesting to see
how it will be used in the standard library or in third-party libraries for
speedup of calculations on the hardware that supports vectors.
Alice: Yeah,
that's quite interesting. Maybe something else?
Dmitry: I think that's probably most of it, yes.
Alice: We will wait for
the 16 version, but now everybody should remember that you should upgrade your
14 version to 15, because of security and all vulnerability fixes, of course.
Dmitry: And
it's better to use it in some automated way, for example, by using repositories that we provide
for Liberica for Linux, yum and apt, but there are also other options.
Any one is good if you just get automated updates or you get notified when an update
is available. It's important to start testing and integration of this new functionality.
Alice: Okay. So, don't forget to upgrade.
I think that's all that we would like to discuss today. Well, thank you to Dmitry. I will wait for
another meeting and talking about JEP. Subscribe to our YouTube channel and read the news in
our newsletter. We will prepare something interesting for you soon. Thank you and bye.