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. > - 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?) Are processed JAR files then re-distributed via say maven or kept internally to be used with a specific stack? Would such tools process use the JarFile class to get access to the JAR file contents? > 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. > - 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...) Paul. > 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