The future of OpenJDK6

[Alex Kasko]

On 03/14/2013 07:10 PM, Andrew Haley wrote:
> On 03/14/2013 12:14 PM, Alex Kasko wrote:
>> On 03/14/2013 01:18 PM, Andrew Haley wrote:
>>> On 03/13/2013 09:14 PM, Alex Kasko wrote:
>>>> On 03/13/2013 09:02 PM, Andrew Haley wrote:
>>>>>
>>>>> OpenJDK 6 is a legacy project.  People only use it because they want
>>>>> long-term stability and compatibility.  Therefore, only changes that
>>>>> fix significant bugs should be made.  This is not a policy change from
>>>>> that discussed on http://openjdk.java.net/projects/jdk6/
>>>>
>>>> Question about two features, that are not bugfixes, but may be useful in
>>>> jdk6:
>>>>
>>>> 1) unlimited crypto support:
>>>>     - makefile patch from jdk7 [1]
>>>>     - maillist thread [2]
>>>>
>>>> 2) missed copyMemory method in sun.misc.Unsafe:
>>>>     - maillist thread [3]
>>>>     - patch that I'm using in my local jdk6 builds [4]
>>>>     - original patch that removed proper copyMemory method [5]
>>>>
>>>> Are there any chances for them to be included into jdk6?
>>>
>>> I would strongly prefer it if neither of these patches went in, but I
>>> am open to argument.
>>
>> I'm OK with it, I'm maintaining public windows builds of openjdk6 and
>> going to add these patches into my next build anyway (so I've asked
>> about them).
>>
>>> Almost nothing would persuade me to accept 2).  This is an internal
>>> method that no application should use.
>>
>> Not arguing, just for your information, situation happened to me some
>> weeks ago.
>> My teammate C++ programmer with little java knowledge was working on
>> Snappy [1] compatibility with C++ streams. He wanted to build Snappy on
>> his Linux box using openjdk6 from packets and was not able to do it -
>> got NoSuchMethodError. At the same time it compiles fine with later
>> versions of Oracle JDK6. Yes, this Snappy implementation uses
>> undocumented API (for optimization purposes) and it has fallback
>> implementation and will run on openjdk6. But it cannot be compiled with
>> default java6 in Linux without downloading Oracle JDK6 and this caused
>> some frustration.
>
> Ah, that is a pain.  Maybe I'm starting to persuade myself this should
> go in.
>
> The right way for upstream to handle this would be so use reflection
> to probe for the method in question: then this program wouldn't have
> any problems.
I'm sorry, I mistakenly said about NoSuchMethodError. It was compilation 
error: copyMemory(long,long,long) in sun.misc.Unsafe cannot be applied 
to (byte[],long,byte[],long,int) .

Snappy uses reflection to load classes that depends on sun.misc.Unsafe 
[1] and checks for proper copyMemory availability [2] and uses fallback 
implementation otherwise. So it runs fine (maybe somewhat slower) on 
openjdk6, but cannot be compiled with it (without explicit exclusion of 
some sources).

> But if upstream won't do that, I'll accept a patch that
> re- enables copyMemory.
The code part of the patch (without comments) is:

-     public native void copyMemory(long srcAddress, long destAddress, 
long bytes);
+     public native void copyMemory(Object srcBase, long srcOffset, 
Object destBase, long destOffset, long bytes);
+     public void copyMemory(long srcAddress, long destAddress, long 
bytes) {
+         copyMemory(null, srcAddress, null, destAddress, bytes);
+     }

I can prepare webrev/OCA if necessary.

>
>> Also sun.misc.Unsafe usage is quite popular for specific optimizations,
>> I've even seen it once in java job position requirements (as additional
>> point).
>
> Good lord.  Unsafe is probably going to disappear from view when
> modularization happens, so people had better get used to its absence.
>
> Andrew.
>
>

[1] 
https://github.com/dain/snappy/blob/e1fd96830b86df6c2e2874628373d9a644498ced/src/main/java/org/iq80/snappy/SnappyInternalUtils.java#L28
[2] 
https://github.com/dain/snappy/blob/01f0a37ca40196e08336532ea6d328eb3ed22b67/src/main/java/org/iq80/snappy/UnsafeMemory.java#L28

-- 
Regards,
Alex Kasko