POC: JDK ClassModel -> ASM ClassReader

[Brian Goetz]

From these 3 points it seems that your goal is for the ClassFile API to
eventually replace ASM? Yet this is listed as a non goal in
https://bugs.openjdk.org/browse/JDK-8280389? Can you clarify?

That's better directed at the Oracle folks. I read it as "within the
context of this JEP, which does not include a public API". I think
it's naive to assume that as and when a public API exists, that people
won't use it / won't seek to remove usage of third-party bytecode
libraries.

This is getting pretty off topic, so we should wind this line of speculation down.

I think the JEP was pretty clear, though.   There’s no intent to “kill ASM” or any other bytecode library.  There’s a reason there are dozens of bytecode libraries; each focuses on different priorities and audiences.  It would be naive to think that this would be the “one library to rule them all”; it will meet some people’s needs, and not others. If/when this API becomes public and permanent in Java 2x, it will be a long time before the ecosystem has fully baselined on Java 2x.  So ASM and others are here to stay for a while, and that’s all good.   The future of ASM is in the hands of the ASM community, which seems strong to me.  Users will make choices that make sense for them, on their own schedule.


What worries me is that:

a) The Classfile API ends up not containing everything that is really
needed by library authors, so they don't switch

Don’t worry about this; this is guaranteed.  There will always be something that this library doesn’t do (e.g., I doubt the TCK team will be able to use it to create some of the pathologically broken classifies that are used to test the JVM) or doesn’t do well enough for every situation.  In those cases, users should use what works for them.  There are choices.

b) The cost of switching is very high, so authors keep using ASM,
which therefore keeps being developed, and we lose the opportunity to
close a big gap in the long upgrade cycle problem.

Don’t worry about this; this is baked in.  If people are happy with ASM, they’ll stay with ASM, and that’s fine.  New projects will have more choices, and many of them may choose the one baked into the JDK.  Some projects may make the switch (as the JDK is embarking on — and this is definitely not cheap) and some may not.  Some will do it sooner, some later, some never.  Ecosystems are messy; we can lead, but people get to choose whether they follow.

c) Even if a) turns out not to be a problem, the time to get enough of
the ecosystem moved over to Classfile API is potentially extremely
long.

Don’t worry about this; this is just how the world works.  Some people will adopt early; some will migrate later; some never will.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/classfile-api-dev/attachments/20220720/b66bfacd/attachment-0001.htm>