Note that one possible feature of JDK 9 is a -platform N option to javac
which would allow compiling against older versions of the platform
libraries:
JEP draft: Compile for Specific Platform Version
http://openjdk.java.net/jeps/8058150
This feature would address some of the concerns raised below.
-Joe
On 4/15/2015 2:24 PM, Remi Forax wrote:
On 04/15/2015 02:44 PM, Paul Sandoz wrote:
Hi Remi,
On Apr 15, 2015, at 1:58 PM, Remi Forax <fo...@univ-mlv.fr> wrote:
Hi Paul,
I think you're seriously underestimate the cost of this JEP.
That is why we are asking for feedback :-) I want to understand the
impact and get some concrete reasons why certain aspects are difficult.
You're asking Java devs to:
- be able to maintain several codes with different source level
compatibility in the same code tree.
Yes.
Maintaining one code with a different source level than the installed
JDK is still not fully solved,
i.e. you still need to have either an old rt.jar or a kind of
meta-description of it.
This can be solved more easily with modules but we aren't yet there.
- add a level of indirection in all tools that crawle/compile Java
source code
- add a level of indirection in all tools that crawle/rewrite bytecodes
How common is it to statically process the byte codes of a JAR file
to produce a new JAR file as opposed to doing that dynamically at
runtime? (I know of obfuscating tools, which IIRC were more commonly
used for mobile?)
From my experience, most of tools that do rewriting at runtime are
able to do rewriting at compile time
(or install time).
Are processed JAR files then re-distributed via say maven or kept
internally to be used with a specific stack?
By example for ASM, we publish several artifacts from the same source,
ones are 1.3 compatible (asm.jar), others are 1.5 compatibles
(asm-all.jar). So users that run on embedded device can still use ASM.
Would such tools process use the JarFile class to get access to the
JAR file contents?
either jar file or class files directly.
all of that to support a feature that:
- is not clearly defined
To me what is not clearly understood is the potential impact, where
as the feature itself is actually fairly simple to grok.
I agree, the idea is simple to grok, not it's perimeter.
- is supposed to only solve cases where delta between versions is small
Yes, it's anticipated there would be a small number of classes that
would require changing.
- comes with no help from the JDK (how to detect a version, etc).
We can propose such things for 9. For example, new public methods to
JarFile. There will be a public JDK version query API in 9, is that
what you mean by "how to detect a version?", or do you mean how can
one analyze an MVJAR? (or perhaps both...)
How to analyze a MVJAR given that you usually have only one version of
the JDK installed ?
Paul.
Rémi
While I understand the comfort for the end user to have only one big
fat jar, it would like to see a prototype that have good answers to
all these questions before including it into the JDK.
Said simply, tackling such problem requires a JSR not a JEP, because
it's a feature which impact a large number of parts of the Java
ecosystem.
regards,
Rémi
