OpenJDK 15 To Have Better Out-Of-The-Box Performance

[bug77]

Unfortunately, our use-case requires that we examine the runtime state of objects belonging to an arbitrary third party. And there's even some funky ClassLoader work in there too, along with a java agent which wants to rewrite some class byte-code on the-fly. We started developing this on Java 8 while Java 9 was still at the EAP stage - which was far, far too early for support from Gradle - and I honestly believe that we don't have a snowball's chance of running on a JVM which does not support reflection.

But reflection is still supported. It's just to be avoided if you want to use the native image feature of GraalVM. Even if you don't, developing with Micronaut/Quarkus without reflection and seeing the effects on startup performance and memory consumption is an eye opener.
But I'm with you, having no LTS JDK between 8 and 11 hurt Java big time. Big changes+nothing production ready=people staying away.

[chrisr]

Of course, they'll never be able to do Class.forName("xxx") where xxx comes from a configuration and the actual class is obtained over the Internet at runtime,...

Unfortunately, our use-case requires that we examine the runtime state of objects belonging to an arbitrary third party. And there's even some funky ClassLoader work in there too, along with a java agent which wants to rewrite some class byte-code on the-fly. We started developing this on Java 8 while Java 9 was still at the EAP stage - which was far, far too early for support from Gradle - and I honestly believe that we don't have a snowball's chance of running on a JVM which does not support reflection.

Also, sorry for the terms mix-up. In my head annotation processing happening before the actual processing, made it a pre-processor. I forgot that also means other things. Sorry for the harsh language, too.

Thank you for saying that .

[bug77]

Ah, you are apparently referring to an "annotation processor". My understanding of the term "preprocessor" is very different.

You are correct in that I have very little experience with annotation processors in general. The last time I looked at them they were used for generating the source code for stub classes.

Look at them closer. If Java is to move on from reflection, this is what is going to replace it. It's already in widespread use in microservices frameworks like Micronaut and Quarkus.
Whatever was traditionally done through reflection at runtime, these guys generate at compile time, basically, zeroing the runtime overhead. Of course, they'll never be able to do Class.forName("xxx") where xxx comes from a configuration and the actual class is obtained over the Internet at runtime, but other than that they're pretty capable.

Also, sorry for the terms mix-up. In my head annotation processing happening before the actual processing, made it a pre-processor. I forgot that also means other things. Sorry for the harsh language, too.

[chrisr]

What can I say, you're so seasoned, you're apparently unaware preprocessors work their magic at compile time. Lombok rings a bell?

Ah, you are apparently referring to an "annotation processor". My understanding of the term "preprocessor" is very different.

You are correct in that I have very little experience with annotation processors in general. The last time I looked at them they were used for generating the source code for stub classes.

[bug77]

I mixed nothing because I was never talking about "java.io.Serializable" - based serialization in the first place. That was 100% your own misunderstanding.


Use a preprocessor at runtime? Really? By all means

T ObjectMapper.readValue(InputStream src, Class<T> valueType);
void ObjectMapper.writeValue(OutputStream dest, Object value);

Actually I'm a long-standing real world Java developer who is trying to migrate a not-that-old code base from Java 8 to Java 11, and who is realising that modern JDKs are planning on bricking up my upgrade path.

So the JDK is moving forward "Full steam ahead!" and I'm saying ICEBERG! And you are saying "La-la-la-not-listening" from the top of your ivory tower.

What can I say, you're so seasoned, you're apparently unaware preprocessors work their magic at compile time. Lombok rings a bell?
JDK evolves. So does any living thing. Need I remind you what happens to those that do not adapt fast enough?

[chrisr]

Now you're mixing things up. Built-in serialization is not used, but at the same time, reflection is not a must.

I mixed nothing because I was never talking about "java.io.Serializable" - based serialization in the first place. That was 100% your own misunderstanding.

Reflection is used because it was readily available (and doesn't totally kill performance), but you could use preprocessors just the same.

Use a preprocessor at runtime? Really? By all means

T ObjectMapper.readValue(InputStream src, Class<T> valueType);
void ObjectMapper.writeValue(OutputStream dest, Object value);

Or are you complaining just because?

Actually I'm a long-standing real world Java developer who is trying to migrate a not-that-old code base from Java 8 to Java 11, and who is realising that modern JDKs are planning on bricking up my upgrade path.

So the JDK is moving forward "Full steam ahead!" and I'm saying ICEBERG! And you are saying "La-la-la-not-listening" from the top of your ivory tower.

[bug77]

joosters from Hacker News writes:

Is it just me, or does all garbage collector development seem to go through an endless loop of:

* We've optimised this release for throughput

* We've optimised this release for latency

* We've optimised this release for minimising memory usage

...and each release causes a regression in the stuff they weren't optimising for, leading to another future release picking one of the other three targets.

Java and Go seem to have gone round this cycle more than once..

I think it's just him.
Unlike Go, Java's GC is very tunable. So each of those "we've optimized for..." lines should really read "we've set the GC defaults for...". No matter how the JRE is configured out-of-the-box, not only do you get to tune the GC in a million ways, you also have a couple more GCs to choose from.
Go, on the other hand, decided this is too much and went with the "one size fits all" approach. With all the benefits and drawbacks. One of the drawbacks being over there the defaults actually matter and they will hurt if/when they don't match what you need.

Garbage collectors being automated beasts, there will always be a use case that will bring out the worst in any implementation. Imho if your usage patterns are so wildly different that that cannot be accommodated by any combination of GC parameters, you've just picked the wrong tool/language for the job.

[sindr]

joosters from Hacker News writes:

Is it just me, or does all garbage collector development seem to go through an endless loop of:

* We've optimised this release for throughput

* We've optimised this release for latency

* We've optimised this release for minimising memory usage

...and each release causes a regression in the stuff they weren't optimising for, leading to another future release picking one of the other three targets.

Java and Go seem to have gone round this cycle more than once..

[bug77]

When I said "serialization", I was referring to the general process of serializing objects and was not specifically referring to Java's particular built-in mechanism. I am fully familar with JSON and can assure you that all of the JSON serializers I've worked with in Java use reflection internally to locate all of the object fields which need to be written out.

Now you're mixing things up. Built-in serialization is not used, but at the same time, reflection is not a must. Reflection is used because it was readily available (and doesn't totally kill performance), but you could use preprocessors just the same.

Like you said: "for the time being". Recent JDKs are spitting out increasingly unfriendly warnings like:

which make it crystal clear where the JDK is headed. And some of these warnings are unfixable because we need access to those fields which have inconsiderately been declared "private".

Have fun writing your JSON serialization framework in Java when you cannot access your objects' internal states.

Do you know of a cleaner way to move Java forward without having everyone use a JRE with lots of legacy technologies? Or are you complaining just because?

I'm guessing the answer was already apparent when you wrote "unfriendly warnings". I don't see those warnings as unfriendly, but rather like "oh, look, things have moved on since I wrote that piece of code". And I'm a big fan of moving code forward; as opposed to crying when a change in the underlying runtime even hints at me having to adjust it sometime in the future.

[chrisr]

I was merely suggesting if serialization is what's holding you back, you should do what the modern world does and switch to using JSON. That doesn't need serialization. It does serialize/deserialize things, but it's not using Java's built-in serialization mechanism (that's why it doesn't require Serializable, but accepts Object instead).

When I said "serialization", I was referring to the general process of serializing objects and was not specifically referring to Java's particular built-in mechanism. I am fully familar with JSON and can assure you that all of the JSON serializers I've worked with in Java use reflection internally to locate all of the object fields which need to be written out.

Some things have been marked deprecated and may not be part of the core JDK anymore, but everything is still available for the time being.

Like you said: "for the time being". Recent JDKs are spitting out increasingly unfriendly warnings like:

WARNING: An illegal reflective access operation has occurred
...
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release

which make it crystal clear where the JDK is headed. And some of these warnings are unfixable because we need access to those fields which have inconsiderately been declared "private".

Have fun writing your JSON serialization framework in Java when you cannot access your objects' internal states.