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.
