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
