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
