Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider Hidden classes use cases #48

Open
LifeIsStrange opened this issue Apr 6, 2020 · 4 comments
Open

Consider Hidden classes use cases #48

LifeIsStrange opened this issue Apr 6, 2020 · 4 comments

Comments

@LifeIsStrange
Copy link

The feature called Hidden classes has been officially marked as a candidate for Java 15 which will reach general availability by the 15 september of this year.

Hidden classes are a feature that is made for framework/libraries that generate classes at runtime.

You have far more expertise than me for considering what could be the use cases/benefits/optimizations that this feature could provide on Jackson, when detecting at runtime that the user supports Java 15.

https://openjdk.java.net/jeps/371

Edit: BTW you could propose, influence the design of the feature while it can still change.

@cowtowncoder
Copy link
Member

Sounds like something Jackson should eventually support, esp. when next LTS (17?) is released.
I think there are similar question wrt Records (Java 14?).

Right now Jackson only requires Java 7 for 2.x (and Java 8 planned for 3.x), so this would probably have to be an extension module.

I'll move this to repo that has issues for future ideas.

@cowtowncoder cowtowncoder transferred this issue from FasterXML/jackson-core Apr 6, 2020
@LifeIsStrange
Copy link
Author

LifeIsStrange commented Apr 6, 2020

Right now Jackson only requires Java 7 for 2.x (and Java 8 planned for 3.x), so this would probably have to be an extension module.
Couldn't you detect at runtime the JVM version and execute the hidden classes code path if supported, otherwise fallback to the current code path?

That way it wouldn't require Java 15 and so could be on the same package? And be a free benefit instead of having to download the extension module (that most wouldn't be aware of the existence)

@cowtowncoder
Copy link
Member

I think all the kludgeing and hacking to try to support future versions of JVM are less clean than module separation, so I don't think I am interested in that approach. Module system was designed to allow extensions for all kinds of things: this is not an unusual use case.

At the same time some support for newer JVM/JDK features is of course possible: JDK 8 can produce module-info for Java 9 and later (with Moditect plugin), and in some cases new features map into existing bytecode facilities. If so, those can be supported.

@cowtowncoder
Copy link
Member

Somewhat related: Jackson 2.12 will add explicit support for JDK14 java.lang.Record types (see FasterXML/jackson-databind#2709). So sometimes support can be added directly in core components; it all depends on how implementation turns out.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants