Hi Paul,
I think you're seriously underestimate the cost of this JEP.
You're asking Java devs to:
- be able to maintain several codes with different source level
compatibility in the same code tree.
- 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
all of that to support a feature that:
- is not clearly defined
- is supposed to only solve cases where delta between versions is small
- comes with no help from the JDK (how to detect a version, etc).
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
On 04/15/2015 01:04 PM, Paul Sandoz wrote:
Hi Markus,
Sorry for the late reply i have been away for the last 3 weeks.
You and your colleagues might be interested in discussion of JEP 238 on
org.apache.maven.dev:
http://markmail.org/thread/v5ywgdpuprntrvfu#query:+page:1+mid:v5ywgdpuprntrvfu+state:results
especially when it gets to the technical discussion of how maven could support
the production of MVJARs.
On Mar 31, 2015, at 1:44 PM, Markus Keller <markus_kel...@ch.ibm.com> wrote:
I've discussed this with the Eclipse JDT team. We're very skeptic and we think
that JEP 238 goes into a wrong direction. Eclipse JDT does not intend to add
special support for it.
Building such MVJARs will be quite complicated, since it requires having
separate classpaths and compiling against multiple JDKs to produce the
release-specific class files that should end up in the same MVJAR. That means
you either need a preprocessor that would allow to keep JDK-release-specific
code in the same *.java file, or you need to maintain and sync separate *.java
files in separate source folders.
Is it really quite so complicated? especially if it is anticipated that only a
small number of sources files are likely to be affected?
Both options are completely counter Java's "write once, run anywhere" idea,
whose foundation is to have only one set of source files and no platform-specific
compilation switches. This is one of the greatest features of Java. It's what makes
reliable code analysis, dependency tracking, and refactoring possible.
The trouble with such maxims is they can be easily co-opted to ones point of
view :-) (my comment is in jest, but there is a point too) for example i can
reasonably argue that MVJARs are actually increasing the ability to run
anywhere, and that benefits all consumers of such JARs.
Note that in terms of dependency tracking one is not proposing that the
dependencies above the major platform would change. Nor would the API (there
may be some form of backward compatible change, see the brief discussion
between Moh and myself).
I agree that changes would be required to both tooling and IDEs. I am
interested in knowing how difficult such changes might be. Are there a series
of smallish changes, each of which is not terribly difficult, or is there
something fundamentally insurmountable?
Furthermore, the general problem is not specific to the JDK, but also occurs
for other libraries. Therefore, a JDK-specific solution would be at the wrong
level.
Just because it's JDK specific does not mean it is de-facto at the wrong level.
It's attempting to solve a smaller and much simpler problem.
A better solution for such cases is to provide an adapter JAR that makes the new APIs
available when running on an older JDK. That way, the problem is solved at the origin,
and not again and again for each client. And with "the problem", I mean the
problem that the old JDK release didn't offer an API for something that clients should
use ASAP, even if they can't require the whole new JDK release right away.
That does not solve the problem of internal or deprecated APIs present in N
going away in N+1.
Layering JDK classes (in JARS) on top of the JDK platform is not very
practical. Such classes often have special treatment, we don't want to
recommend using the boot classpath, and i don't think developers will be very
happy having using such options and manage additional dependencies associated
with the platform.
Of course we cannot feasibly backport every new API in N to N-1, N-2 etc. In
selective cases that might be possible, but for the core of the JDK it's like
pulling on a string of public dependencies, internal dependencies and perhaps
more subtle dependencies between javac and hotspot (Unsafe replacements would
be particularly tricky).
Paul.
