JDK6 backwards compatible AutoCloseable from a libraries perspective

[Michael Bien]

On 02/07/2011 04:14 PM, Rémi Forax wrote:
>    Le 07/02/2011 16:06, Michael Bien a écrit :
>>     On 02/07/2011 03:32 PM, Rémi Forax wrote:
>>>      Le 07/02/2011 15:08, Michael Bien a écrit :
>>>>       On 02/07/2011 02:40 PM, Rémi Forax wrote:
>>>>>        Le 07/02/2011 14:10, Michael Bien a écrit :
>>>>>>         Hello everyone,
>>>>>>
>>>>>> I would like to support the new try-with-resource feature in jocl while
>>>>>> staying backwards compatible with JDK5/6. The problem is that
>>>>>> AutoCloseable resides in java.lang which means i have no chance to load
>>>>>> the class if i would ship it for jdk5 backwards compatibility.
>>>>>>
>>>>>> Providing two builds for JOCL is not what i would like to do just to be
>>>>>> able to be upwards compatible.
>>>>>>
>>>>>> any ideas what i could do in this situation?
>>>>>>
>>>>>> best regards,
>>>>>> michael
>>>>> You need to:
>>>>> Create a jocl internal equivalent to java.lang.AutoClosable, let say
>>>>> jocl.lang.AutoClosable,
>>>>> this class should extends java.lang.AutoClosable.
>>>>> modify you managed classes to implements  jocl.lang.AutoClosable.
>>>>> compile with javac -source 7 -target 7
>>>>> Now you have a 1.7 compatible version.
>>>>>
>>>>> The trick is to downgrade the classfiles to have a 1.5 compatible version.
>>>>> For this use a bytecode rewriter tools like ASM [1] to change a just
>>>>> some bits
>>>>> in the classfiles.
>>>>>         modify the classfile of jocl.lang.AutoClosable to don't inherits from
>>>>> java.lang.AutoClosable anymore.
>>>>>         downgrade the classfiles major version number from 51 (V1_7) to 49 (V1_5)
>>>>>
>>>>> In fact, there is a way to avoid to create jocl.lang.AutoClosable, you can
>>>>> analyze the bytecode to detect call to AutoClosable.close() and replace it
>>>>> by the type of the variable infered using the same algorithm as the
>>>>> verifier does.
>>>>> ASM package org.objectweb.asm.analysis already provides this analysis.
>>>>>
>>>>> Rémi
>>>>>
>>>>> [1] http://asm.ow2.org/
>>>>>
>>>>>
>>>> Thank you Remi,
>>>>
>>>> do i really have to compile with 1.7 language level even if i don't use
>>>> ARM internally?
>>> yes, you have to.
>>> source of the compiler near line 165:
>>> http://hg.openjdk.java.net/jdk7/jdk7/langtools/file/1383d1ee8b5d/src/share/classes/com/sun/tools/javac/code/Source.java
>>>
>>> public boolean allowTryWithResources() {
>>>          return compareTo(JDK1_7)>= 0;
>>> }
>>>
>>>> -michael
>>> Rémi
>>>
>> hmm. In this case it would be much easier (and less risky regarding QA)
>> do just use simple string replacement and build the library twice.
>> (since we can't create one jar which is compatible in both scenarios)
>>
>> Once with
>>     com.jogamp.common.AutoCloseable extends java.lang.AutoCloseable (with
>> JDK7 lang level7)
>> and once with
>>     com.jogamp.common.AutoCloseable /*extends java.lang.AutoCloseable*/
>> (with JDK6 lang level5)
>>
>> should have the same effect, right?
>>
>> michael
>>
> Almost, you also have to downgrade the classfile version.
>
> Rémi
>
Hello,

In case someone is interested thats how i ended up implementing it:
A little bit sourcecode preprocessing and we can build now eather 
against our AutoCloseable dummy or against a AutoCloseable extending 
JDK7's AutoCloseable.
This lets us produce one set of binaries which are compatible with 1.5 
and an other set of jars which support the try-with-resource feature but 
require 1.7.
Thats not perfect but its at least simple to maintain.

bytecode processing and/or using custom compilers where both no-gos for 
us at least not for this kind of nice-to-have features.

thank you all for the help,
michael

-- 
http://michael-bien.com/