The future of OpenJDK6

[Andrew Haley]

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.  But if upstream won't do that, I'll accept a patch that
re- enables copyMemory.

> 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.