JDK 13 RFR of JDK-8221264: Refactor SourceVersion#latestSupported

[Martin Buchholz]

Here's a naive user journey into upgradeable module land:

I knew about upgradeable modules from reading JEP 261 but I had trouble
figuring out which modules in a particular JDK were upgradeable.  How does
one tell that java.compiler is upgradeable in a particular JDK?  Eventually
I came up with the non-obvious hack:

#!/bin/bash

set -eu -o pipefail
die() { printf "%s: $1\n" "$0" "${@:2}" >&2; exit 1; }

(( "$#" == 1 )) && [[ -d ${JAVA_HOME=$(jver "$1")} ]] \
  || die "Usage: %s JDK-SPEC" "$0"

readonly JMODS_DIR="$JAVA_HOME/jmods"
[[ -d "$JMODS_DIR" ]] \
  || die "%s: no such directory" "$JMODS_DIR"

cd "$JMODS_DIR"

declare -A hashed
hashed[java.base]=1
for mod in $("$JAVA_HOME/bin/jmod" describe java.base.jmod \
  | perl -ne 'print "$1\n" if /^hashes (\S+)/'); do
  hashed[$mod]=1
done

for file in *.jmod; do
  [[ -n "${hashed[${file%.jmod}]-}" ]] || echo "${file%.jmod}"
done
---

list-upgradeable-modules ~/jdk/jdk13
java.compiler
jdk.aot
jdk.internal.vm.compiler
jdk.internal.vm.compiler.management

That looks right - java.compiler is upgradeable.  I'm an IDE and now I want
to actually do an upgrade.  For that I need a module.  There doesn't seem
to be any such artifact on Maven Central. There's a java.compiler.jmod file
in my jdk13, BUT:
 - a jmod file looks a lot like a modular jar, but it isn't one
 - the .class files contained therein are the wrong class file version

If the class files for upgradeable modules were built to target an older
JDK version, they could be used unchanged in JDK(N) or JDK(N-1).
If additionally there was a way to turn a .jmod file into a modular jar,
that artifact could be used directly in JDK(N-1)

Many people in the industry are migrating across LTS releases jdk8 -> jdk11
-> jdk17.
They will want to use jdk17 java.compiler in an IDE running on jdk11.

 $ jver 11 jmod describe java.compiler.jmod
Error: Unsupported major.minor version 57.0



On Sun, Mar 24, 2019 at 7:49 AM Jonathan Gibbons <
jonathan.gibbons at oracle.com> wrote:

>
> On 3/23/19 11:54 AM, Martin Buchholz wrote:
> > I'm confused about how an IDE would access the jdk(N+1) API inside a
> > JDK(N).
> >
> > Of course, the jdk build needs to use this API while bootstrapping the
> > JDK(N+1), but this seems to involve a lot of build magic and "interim"
> > modules, e.g. I see java.compiler.interim in my build tree.  But isn't
> > that all implementation detail of the build system?  Users can't
> > simply take a java.compiler module out of a JDK(N+1) and use it with a
> > JDK(N) can they?
>
> The build magic is related to this issue but not an inherent part of the
> issue.
>
> The javac classes in JDK N, i.e. the classes in the java.compiler and
> jdk.compiler modules) are guaranteed to be executable on JDK N-1 [*],
> and able to compile source code for `--source N` provided that a
> suitable copy of the API for JDK N is available.  In the build magic,
> that copy of the API comes from the source code in the repo. In other
> deployments, the copy of the API can be provided in any suitable
> compiled form.
>
> -- Jon
>
> [*] Note that as generally used in this sort of context, "N-1" means the
> previous GA release, which may be numerically 2 less than N if the
> following release is not yet final.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190324/4b231b32/attachment.html>