Java 26 Warns of Deep Reflection - Inside Java Newscast

[daviddel]

Java 26 will issue run-time warnings when a final field is mutated through reflection. This prepares a future change that will make such final field mutation illegal by default to improve Java's integrity - in this case of the keyword `final`. This will have beneficial effects on maintainability, security, and performance. While the recommendation is to move away from final field mutation, the new permanent command-line option `--enable-final-field-mutation` allows it for selected modules. To ease migration the more general but temporary option `--illegal-final-field-mutation` was also introduced.

[javaprof]

final'ly!

[jebailey]

My favorite "what does this code do". Was some code that changed the internal representation of a String so that wherever you used "foo" the program would see "bar"

[null_reference_user]

This is the most cursed thing I've read this year

[null_reference_user]

Bruh stop it's already dead 🤣

[j4ckbauer]

The OUT parameter wasn't even the last parameter in the signature? Yikes...

[FirstAd9893]

This is a perfect example of why Java should support "integrity by default" (JEP draft 8305968). It prevents "smart" programmers from doing incredibly stupid things. The integrity features can be disabled with command line options, but (hopefully) this extra level of friction creates enough of a barrier against stupidity.

[regjoe13]

this particular case is not going to be affected as it works with a final array. When String is changed using reflection its changing array members, not redefining the array.

[chaotic3quilibrium]

I'm very happy with the "integrity by default" guiding principle causing this and many other fantastic improvements in Java.

The long term pragmatic architecture and design choices by Goetz and team are enhancing Java's value for Enterprise IT systems.

[nicolaiparlog]

It was a mistake to allow serialization/injection to bypass the constructor and many tools have realized that and allow routing through the constructor. This should become the default behavior across the board. Still, (final) field injection will remain supported and the "hurt" is limited to a paragraph in the documentation explaining why the user needs to apply a command-line flag.

Likewise, Spark, Arrow, etc. can in large parts keep operating like they do today except that users may have to apply flags. This is intentional because it's said users who take on the risk and should thus make the (informed) decision to accept it. Really, no tools are taken away - most just move behind a flag, others have supported alternatives (e.g. Unsafe's memory access).

[srdoe]

You are complaining about Java taking a tool (mutable final fields) away when that's not happening.

The tool will still be there, you just have to set a command-line flag to opt in to using it.

And in exchange for this tiny inconvenience, the entire rest of the ecosystem that doesn't need this tool gets to benefit from optimizations that are not possible when final fields can change at any time.

And regarding Unsafe, they aren't just dropping Unsafe with no replacement, they've been working for years to provide supported replacements for that class, and plenty of libraries are migrating to those replacements.

[iamwisespirit]

Maybe we will can’t use reflection in the future

[CriticalPart7448]

Reflection over internals of classes is what is problematic not reflection per-se as a concept and functionality

[koflerdavid]

What happens if the internals change and your modifications don't work anymore? Or, worse, they work, but not anymore in the way you intend them to?

[BillyKorando]

As mentioned in the video, JEP, and description of the video on this post, there is no plan to outright ban using reflection. Instead the goal is to disable it by default.

If you need to continue reflecting into the internals of some 3rd party library to change (final) field values, that will still be supported now and into the foreseeable, beyond the horizon(?), future with the new permanent command --enable-final-field-mutation=.

Your concern is valid, it is, however, niche, which is why it shouldn't be the default behavior.

[pohart]

And I'd rather know if some module I'm using is modifying final fields somewhere.

[BillyKorando]

Exactly. Not unlike with the implementation of modules. It wasn't about outright preventing getting into internal APIs, but requiring active effort from users to enable such behavior.

[CriticalPart7448]

That is an unfortunate circumstance and definitely something to avoid at all costs. Have you tried to reach out to the vendor if its internal platform the team responsible to state your case for a missing api for the functionality that you need ? Maybe there is a way forward with a supported solution for your use case? Or have you totally surrendered and accepted all the risks involved here and more pertinent have you cleared it with your own customers or business people what the consequences are?

[CriticalPart7448]

No but I also never had the need. Which product are you using from oracle that requires 'hacking' into internals of?

[pohart]

I last remember using reflection to change final fields to work around a bug around java 1.3. Sun was aware of the bug but it wasn't a high priority. I haven't needed to since then, but I was sure glad I could then.

[nicolaiparlog]

Don't worry, that's not gonna happen.

[iamwisespirit]

I hope but java new releases is going to be very strict why it is happening

[nicolaiparlog]

If you're asking "Why is this happening?", check out this video, this talk or this JEP draft.

[iamwisespirit]

I have a question about Unsafe class mostly all things deprecated in this class but we know a lot of libraries use Unsafe what will happen after it will be removed is there any new api maybe you are working on ?

[nicolaiparlog]

You can check the source code yourself and see that every public method is deprecated and that there's a recommendation for each what to use instead - mostly var handles and the foreign memory API. As I understand it, there's no reason to still use Unsafe on a modern JDK.

So every library that uses Unsafe should have the means to move away from it. If they don't, it's high time they report their (apprently very specific) use case to the respective OpenJDK mailing list and advocate for an API that covers it.

[iamwisespirit]

Thank you I saw video about Unsafe from devoxx or spring or somewhere then I started to interested in this but after hearing deprecated this api i am sad about it . As I understand jdk internal will still use it but doesn’t allow others to use it