JDK6 backwards compatible AutoCloseable from a libraries perspective

[Joe Darcy]

Michael Bien wrote:
> 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
>   

Hello.

If you're willing to use annotation processing during your build, you 
could also declare your class to implement a *missing* superclass.  That 
missing superclass could then be generated via annotation processing, by 
apt if you're stuck on JDK 5 or by javac if you can use JDK 6 or later.  
The annotation processor can generate a target-appropriate superclass, 
having it implement java.lang.AutoCloseable on JDK 7 and some other 
interface otherwise.

-Joe