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.