<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<font size="4"><font face="monospace">We've staged the current state
of the in-development classfile API in the OpenJDK sandbox repo:</font></font><br>
<div class="moz-text-html" lang="x-unicode"><font size="4"><font face="monospace"> <br>
<a class="moz-txt-link-freetext" href="https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch">https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch</a><br>
<br>
The README file there includes instructions for building,
running the tests, and running the benchmarks. The API is in
the package `jdk.classfile` (a good starting point is the
class `Classfile`, which contains the main entry points for
parsing and generating classfiles). It provides full coverage
of the classfile format through Java 17. The repo also
includes experimental replacements for most uses of ASM in the
JDK. <br>
<br>
There is Javadoc here:<br>
<br>
<a class="moz-txt-link-freetext" href="https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/jdk/classfile/package-summary.html">https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/jdk/classfile/package-summary.html</a><br>
<br>
The package doc is a good place to start to get an overview of
how it is used. The docs so far are fairly thin, and need a
lot of work, especially examples. <br>
<br>
How can people contribute? <br>
<br>
- Try it out! Bring your favorite code examples from ASM,
cglib, or your favorite bytecode library, and try them with
this library. Post experience reports (but please, let's keep
subjective "you should do it like my library does" down to a
dull roar.) Bear in mind that your first idea of how to do it
in the library might be suboptimal, so ask questions.<br>
<br>
- Tests. Our test coverage is good, but there are still
corners of the API that are not fully covered. We'll be
posting some coverage metrics soon; additional tests are
always useful. <br>
<br>
- Examples. Our docs need lots of examples, and well-crafted
examples are worth a thousand words. <br>
<br>
Further discussion should take place on <a class="moz-txt-link-abbreviated moz-txt-link-freetext" href="mailto:classfile-api-dev@openjdk.org">classfile-api-dev@openjdk.org</a>
(copied); you can sign up here:<br>
<br>
<a class="moz-txt-link-freetext" href="https://mail.openjdk.org/mailman/listinfo/classfile-api-dev">https://mail.openjdk.org/mailman/listinfo/classfile-api-dev</a><br>
</font></font> </div>
<div class="moz-cite-prefix"><br>
<br>
<br>
On 6/19/2022 10:11 AM, Brian Goetz wrote:<br>
</div>
<blockquote type="cite" cite="mid:641b055b-a384-525a-f71a-81ccebd53bc2@oracle.com">
<div class="moz-text-html" lang="x-unicode"><font size="4"><font face="monospace"><font size="4"><font face="monospace"><br>
Generation, parsing, and transformation of classfiles is
ubiquitous in the Java ecosystem. Frameworks transform
classfiles on the fly by hooking into classloaders or
using `java.lang.instrument`; compilers and IDEs for all
sorts of languages read and write classfiles; static
analysis tools read classfiles; migration tools
transform classfiles. In the JDK, we have a static
compiler (`javac`) and other tools (`javap`, `jlink`)
that read or transform classfiles, and numerous platform
features that operate by classfile generation
(reflection, lambdas, dynamic proxies, method handles),
as well as many tests that generate classfiles. In
fact, the JDK contains at least three libraries for
processing classfiles: an internal one (used by JDK
tools such as `javac`); a fork of ASM (used by lambdas
and many other platform features), and a fork of BCEL
(contained inside a fork of Xalan). And of course the
ecosystem has many such libraries: ASM, javassist,
cglib, BCEL, gnu.bytecode, ByteBuddy, and many others.
<br>
<br>
Over the years, there have been many calls for Java to
have an "official" classfile library, and there are
numerous practical reasons to create one, and the shift
to the six-month cadence has added two new reasons.
Firstly, tools that bundle classfile libraries are more
likely to encounter classfile versions "from the
future", because they use a classfile library that knows
about Java N, but the customer may be running it on Java
N+1, which was released only six months later. Second,
the pace of classfile format evolution has picked up
significantly in recent years, with a significant
fraction of releases having at least some change to the
classfile format (new attributes, new constant pool
forms, new bytecodes, new combinations of flags, etc).
Having an official classfile library would mean that
applications and tools are guaranteed to have access to
a library that is up-to-date to the latest classfile
version that will run on the current JDK. <br>
<br>
It might seem an "obvious" choice to "just" standardize
on ASM, but there are many reasons not to do so. ASM is
an old codebase with plenty of legacy baggage; the
design priorities that informed its architecture are not
ideal for the JDK in 2022; and the language has improved
substantially since them (lambdas, records and sealed
classes, pattern matching.) What were the best possible
API idioms in 2002 (visitors) may not be ideal two
decades later. <br>
<br>
A draft JEP can be found here:<br>
<br>
<a class="moz-txt-link-freetext" href="https://bugs.openjdk.java.net/browse/JDK-8280389" moz-do-not-send="true">https://openjdk.org/jeps/8280389</a><br>
<br>
Such an API will have many consumers, both internal to
the JDK and external: compilers, analysis tools,
platform implementation, 3rd party libraries, tests,
etc. We will focus initially on the internal JDK
consumers, incrementally migrating them off of the
existing libraries and onto the new library.
Eventually, once all the internal consumers are
migrated, we will be able to remove ASM from the JDK
entirely. Initially, the library will be internal-only
(non-exported), to gain experience with and refine the
API before committing to a public version. When the API
is sufficiently stable, it will be exported for public
use, first as a preview API and eventually as a
permanent API. <br>
<br>
Comments on the JEP itself -- the concept, motivation,
and design goals -- are invited for discussion. The JEP
includes some code examples, which are hopefully
illustrative, but I will request that people hold off on
API discussions for the time being, to make room for
discussion on the JEP itself first. <br>
<br>
</font></font></font></font> </div>
</blockquote>
<br>
</body>
</html>