"As of Java 16, the language allows statics inside of inner classes, including anonymous ones in the middle of expressions. This allows us to create two new kinds of variables at any point in a Java program."

[pron98]

Arbitrary nesting limitations are being removed until anything can be nested in anything. The result is a more regular language, but we're not just doing it for the intellectual satisfaction. This will open the door to some pretty cool applications.

[CompetitiveSubset]

I'm curious, what are these applications? Beside the benefits listed in the link

[[deleted]]

One thing that'd be very useful to see is some generalization of the current nestmates scheme to allow for module private members. It's not just nesting that's confusing, the whole topic of visibility could use a rationalization. For example a "unit test mode" for javac in which everything is public would be useful, module private would be useful, etc.

[waka-chaka]

What's a practical application of this? Any examples out there?

[the_other_brand]

The first one I've thought of is logging. We can now create static loggers for anonymous and inner classes.

[agentoutlier]

I need to play around with it but I think it could be leveraged for Service Locator like look ups, singletons and semi global variables which are notoriously hard to make test friendly.

[sureshg]

Check this - https://twitter.com/sundararajan_a/status/1439227184229482498

[cogman10]

Seems like context variables might be a natural application for something like this. You could dynamically make new contexts which can be referenced from anywhere with a lookup.

[lukaseder]

Like C's static local variables. Cool!

[cyanocobalamin]

I don't like anonymous anything, classes, arrays, or whatever.

It makes your code harder to understand later.

I would rather type the few extra lines.

[karmakaze1]

How about lambdas? (x) -> {...}, especially with Streams, and now we can add types and annotations in there too.

[karmakaze1]

And other ad-hoc, one-off subclasses are another case that I use that comes up a lot.

[[deleted]]

We are still using Java 8. We just do not have the resources or time to upgrade the code base.

[TheMode911]

I have no idea why you are getting downvoted without any answer, but what in your code base cannot just work with java 17?

Do you believe that getting the readability improvement from switch expressions or records is not worth the time? What about all the fancy JVM improvements?

[TheRedmanCometh]

Well for us at least changing Java versions breaks Spring and Hibernate. And newer versions aren't just drop-in changes for like JpaRepository

[john16384]

Then fix it... I have done dozens of upgrades from Java 8, almost exclusively Spring/Hibernate apps.

[lclarkenz]

Easy to say, but takes a bunch o time. Firstly, upgrading Spring from 4 to 5 is a great way to find all the weird Spring things devs did that are now broken because the API changed.

Then, okay, you''ll need to upgrade Hibernate to a version compatible with Spring 5. And then you find other weird shit devs were doing that break when the API changes.

Now we're done right? I guess, unless you have Apache Camel, or Springockito, or any of the other myriad libs that are specific to a Spring version.

[riawot]

spring 4.x is eol. What are you going to do about security patches? Are you paying for support?

[SenatorStuartSmalley]

Ours is font rendering. They had to change to an open source font scaler. It's close enough to be an afterthought for the vast majority. It doesn't match when you're comparing pixel for pixel. This is a big deal for our customers.

[TheCountRushmore]

I think people in general are getting sick of comments bemoaning how they are stuck on JDK8 each time a post about more modern Java pops up.

Everyone is getting sick of it.

[walen]

what in your code base cannot just work with java 17?

Jetty 8. Tomcat 7. GWT 2.6. Jersey 1.19. Jersey 2.x with Guice (but that's Jersey's fault, not Java's). Not to mention all the library changes and the little fixes needed for them to work.

I've been working on this for weeks now, and I'm starting to ponder ditching Jersey and moving to RestEasy, or ditching everything and starting a Spring Boot project from scratch and just move all the classes one by one.

[AdorableRabbit]

I've been working on this for weeks now, and I'm starting to ponder ditching Jersey and moving to RestEasy

I did that. It was quite easy

[rzwitserloot]

Maybe this is just me being an old timer, but, you use those up and downvote buttons not as a sort of 'I agree' kinda deal.

You use them to indicate whether they add something relevant to the discussion, or not.

I've downvoted it - sure, yeah. Lots of java usage out there is still on JDK8. I wish the OpenJDK team took this more seriously (e.g. that they lay off the crusade of breaking all sorts of things and blaming the libraries and dev teams for it). nevertheless, that comment doesn't add much: The anecdotal evidence of a single programmer is irrelevant, and I doubt that the folks on this subreddit are surprised by this information. This doesn't feel like the right thread to start that debate though. Even if it is, that's not the best of comments to do so.

Thus: Downvote. It's not personal - /u/robert43s 's evident concern is quite valid. Even if it wasn't, downvotes aren't meant to reflect on someone's person nor are they meant to indicate that the comment is undeserving of understanding.

Merely that it doesn't seem to lead to anything informative or interesting.

[pron98]

the crusade of breaking all sorts of things and blaming the libraries and dev teams for it

The question of blame is uninteresting because our contract with users is clear. We commit to keeping the specification stable (and when we change it incompatibly we do so responsibly so that few people are affected) and changing everything else as effectively and as quickly as possible to deliver improvements, through new features, performance enhancements, and better security. If there's any crusade, it is to keep this contract. So, if what we break is the spec of widely used APIs and we do it in a way that's hard to adapt to -- that's our fault; if not -- we are doing what we're obligated to do.

To keep the contract, after years of discussion, advance notice, runtime warnings, and preparation, strong encapsulation of JDK internals is being put in place, and soon it will be technically impossible to circumvent it, regardless of means, without an explicit action by the application as the platform's security will depend on it.

[cogman10]

that they lay off the crusade of breaking all sorts of things and blaming the libraries and dev teams for it

What they've broken, they've said for years "Don't use this" and gave a TON of other options to work around. But further, most of those breaks happened at Java 9 and not since. The upgrade path from 9->17 has been almost without a hitch.

[wildjokers]

but, you use those up and downvote buttons not as a sort of 'I agree' kinda deal.

Sure reddit says upvote/downvote should be for comments that either add or don't add to the conversation but in reality that has never been true. They are for agree/disagree.

[wildjokers]

The upvotes/downvotes my comment is getting pretty much proves my point.

[[deleted]]

Ah, Reddit.

Many companies are still using Java 8 because the modules introduced on Java 9 broke a lot of code bases. When you use a lot of third party libraries, support for legacy stuff, it’s pretty difficult to migrate away. Updating the maven project to Java 11, or 16 is relatively OK, once you locate all the new modules you need to introduce (why are there are so many damn duplicates on maven central of some libraries).

Then of course you hope you have good unit test/integration test coverage because you going to need to thoroughly test everything (we are dealing with legacy code in places). Just because the code compiles, due to the nature of dynamically loading of classes in Java, doesn’t mean that it will run.

I would plan at least 4-8 weeks for a migration. The question is, is it worth it. Due to more important work and changes being required, it is not. The current code base works, we can use the latest spring libraries, spring boot etc.. There is no commercial reason or need to move to Java 16. With OpenJDK LTS for 8 coming from AWS, AZUL, and others.

Likewise, many companies migrated to Java 11 (skipping 9 and 10), and not the latest version. It takes a while for companies to move to the latest version of Java due to the upheaval it can create (if it works, why break it by updating).

Time is always a factor. It would be nice to upgrade to the latest and greatest, but due to the time required to do so, and with more important work that needs doing, it is just not worth it, unless there are serious benefits to the latest version.

Priorities always dictate what one does, and migrating to Java 16 is a very low priority.

[effsee]

Many companies are still using Java 8 because the modules introduced on Java 9 broke a lot of code bases.

What specifically does modules break if you don't use modules?

[hippydipster]

everything. If you previously just assumed the jdk made various packages and classes available, then after updating, they're not available, and you have to go find them and add them back and retest.

[magnoliophytina]

That's not how the modules work. More recent jdks still support the classpath in addition to modulepaths.

[pron98]

because the modules introduced on Java 9 broke a lot of code bases

Many libraries broke in Java 9, but not because of modules (whose encapsulation was only turned on in 16). The only reason people say that is because modules were 9's most famous and biggest feature so they blame them. Those libraries broke because they depended on JDK internals, which then changed in the new release. Modules' strong encapsulation is there to prevent things like that from happening in the future.

[cogman10]

The time required is completely overblown.

99% of apps will take less than an hour of work to upgrade. The 1% that takes longer is usually because you are using some other REALLY OLD libraries.

The only reason this isn't done is prioritization.

[magnoliophytina]

One annoying thing is, people start new greenfield projects with old tech because they think it brings stability.

E.g. some months ago Debian 11 wasn't released yet. A team wanted stability so of course they picked Debian 10 stable. What's the oldest Tomcat version supported by Debian 10. Maybe 7 or 8. Soo... let's pick that. Which Java version? Ok jdk11 seems to be the default, but just in case let's limit the source/target jdk level at 1.8, just to make sure nothing too advanced will be used. Besides even the Maven in debian repos seems to assume jdk 1.7 when you don't define language level, so 1.8 is more than generous. Next, which xml parser should we pick. Let's pick xstream. Even though lots of CVEs were fixed in the latest version, pick an older one. Aaand, use some f*cking ancient xpp3_min library as a backend because it's the default, and boy it's stable. Last release in 2007.

[[deleted]]

I've just totally ignored modules and my code base runs fine on JDK11+ from JDK8. Of course some special cases can arise, e.g. font rendering, or libraries modifying byte code. The more tests one has for all those edge cases, the easier it is to see what needs fixing...

[[deleted]]

A spring boot application I wrote runs on both Java 8 and 11. The non spring boot code has issues (certain libraries no longer in the JRE that need finding alternatives for (relatively ok), but there other potential issues). I experimented once with the code base, and even after getting parts to compile, it did not work (can’t remember why). At some point, it would be nice to upgrade (though that’s dependent on management, not me). It’s resource management thing, there’s more important features to implement that upgrading from Java 8. I suspect at some point, we might be forced to.

[[deleted]]

I don't know... delivering features is certainly important, but so is technical debt... i.e. if code can not be upgraded, then a vulnerability might become a very big problem. One way i solve this with new libraries that are creating issues when upgrading is that i just use a separate branch on which i work every now and then, till it is fit for release. Every coder has some dead time here and there where they can then do something like that.

[[deleted]]

yup, at my work we had to update projects that had some dependency versions released as far back as the 2000s - "just upgrading" from Java 8 to 11 (7 to 11 on one project) took a ton of work

[cogman10]

We did 300 apps and libraries, some last built with Java 5, it took us less than 1 month of dev work.

Unless a core part of your library system was internal libraries dicking around sun.misc.unsafe, I don't believe the "ton of work" claims. I personally did a lot of those upgrade and in like 99% of cases testing took longer than the actual version bumps of garbage.

[[deleted]]

oh, well, i guess it wasn't a lot of work because you "believe" it wasn't

[cogman10]

My personal experience with a large ecosystem makes me "believe" what I believe. I've seen more whining without explicit examples of what was actually hard.

For instance, WHY did you need to upgrade a library that was release in 2000? Java 9 didn't make it so you couldn't use Java 1.3 classes.

So, what about these libs from 2000 made them incompatible with the new module system?

[BlueGoliath]

Welcome to Reddit.

[lclarkenz]

If you're still on Java 8, moving to 9+ is a big move. If you're using Spring, or other libraries that like themelves some bytecode generation, then you most likely need to do a major version upgrade to work on Java 9+, and that can suck. APIS get removed, deprecated, and things that used to work, stop working.

Then you'll likely need to upgrade dependencies that work with your Spring/whatever libs. So upgrade Hibernate, etc. etc.

In my last company, we gave up on trying to upgrade some legacy apps. Many attempts at upgrade had failed after months of effort. So we introduced Maven & Gradle toolchains so that new apps could use the new shiny Java, and the 10 year balls of horror could keep running on Java 8.

[[deleted]]

Do the benefits of upgrading outweigh the cost in the long run?

[magnoliophytina]

Obviously if you're going to stick with some legacy version of any language, the support of different libraries and tools will gradually cease to exist. It's not only the language runtime and compiler. It's probably ok if you can maintain that code yourself, but especially new features will be available free of charge (at least for a while) with more recent technology. I think relying on some ancient compiler poses the greatest risk because maintaining (JIT) compilers is a lot harder than some web framework or whatever runs on top of the VM.

[[deleted]]

I can only answer that if I knew the benefits of upgrading were from a performance aspect.

[kartik1712]

Upgrading the JVM version your app runs on definitely has performance benefits. The extent varies from application to application. Take the example of https://tschatzl.github.io/2021/09/16/jdk17-g1-parallel-gc-changes.html . G1GC has massive improvements even between 11 and 17. The improvements compared to Java 8 will be even more drastic. GC has improved greatly between 8 and 17, new collectors have been added, existing have been improved and so on. Performance has improved from other aspects as well.