David Lloyd
2018-04-02 14:58:47 UTC
Debugging multi-release JARs can be a pain, because their
corresponding sources generally do not include the multi-release
overlays. I'd like to propose a convention for multi-release source
JARs. AFAIK there is no specification for source JARs, but Maven and
other build tools commonly output source JARs as a part of their
build, hence the term "convention" instead of "standard".
The convention would be simple: the source JAR should include
META-INF/versions directories exactly as specified in JEP 238. IDEs
and other tooling should consider the running or configured project
JDK version when determining which sources to examine or display to
the user.
I don't think the Multi-Release attribute should be required for
source JARs. That attribute would be gleaned from the corresponding
.class JAR; requiring it in the source JAR seems redundant.
WDYT?
corresponding sources generally do not include the multi-release
overlays. I'd like to propose a convention for multi-release source
JARs. AFAIK there is no specification for source JARs, but Maven and
other build tools commonly output source JARs as a part of their
build, hence the term "convention" instead of "standard".
The convention would be simple: the source JAR should include
META-INF/versions directories exactly as specified in JEP 238. IDEs
and other tooling should consider the running or configured project
JDK version when determining which sources to examine or display to
the user.
I don't think the Multi-Release attribute should be required for
source JARs. That attribute would be gleaned from the corresponding
.class JAR; requiring it in the source JAR seems redundant.
WDYT?
--
- DML
- DML