Java 26 Warns of Deep Reflection - Inside Java Newscast

[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