kryo 2.22 requires sun.nio.ch and sun.misc package dependencies

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Use kryo 2.22 in my Java 1.6.0.26 OSGI executable.
2. Launch the exe in eclipse or via a built exe.
3. The app immediately fails because OSGI cannot find package imports of 
sun.misc and sun.nio.ch

What version of the Kryo are you using?
2.22

Where do I find the jar (OSGI compatible) that includes these packages? Do I 
need to be on Java 1.7 in order to have these resolved? Up until this release, 
I have been able to successfully use Java 1.6 with Kryo.

Thanks for the help in advance!

Original issue reported on code.google.com by zsol...@gmail.com on 15 Oct 2013 at 10:53

[GoogleCodeExporter]

Both packages are usually not publically exposed by the JDK, because they 
provide very platform specific APIs which are not guaranteed to be supported in 
the future or by other JDK implementations. Sometimes, access to these APIs is 
also restricted by a SecurityManager.

I see two possible solutions here:
1) May be we can do something with packaging of Kryo, so that we properly 
require/expose certain things related to this issue?
@Martin: Do you think something can be done in this direction?

2) We can try to refactor Kryo in such a way, so that it does not statically 
depend on sun.misc and sun.nio.ch
   Instead, it would try to load and use classes from these packages if available. If not, it will use the old implementation (which does not use Unsage) as a fallback.

-Leo

Original comment by romixlev on 16 Oct 2013 at 7:33

[GoogleCodeExporter]

IMHO we want to support jvms/jdks as well that don't provide those packages. So 
I don't see how 1) would be a solution, but IMHO 2) sounds like the way to go.

Original comment by martin.grotzke on 17 Oct 2013 at 7:39

[GoogleCodeExporter]

@Martin: Obviously (1) is not a solution on platforms which don't provide those 
packages. But I meant that even on platforms that provide those packages, they 
may be eventually inaccessible due to problems with our packaging (e.g. OSGI 
manifests, list of exported, imported classes and packages, etc). It seems like 
the submitter of this issue uses his JDK on a desktop, but cannot access those 
packages for some reason.

BTW, I'm working on (2) now, which should solve most of the problems.

Original comment by romixlev on 17 Oct 2013 at 2:03

[GoogleCodeExporter]

I'm hoping to use this in an app I am releasing soon. Could I get an idea for 
when this modification might be complete?

Original comment by zsol...@gmail.com on 21 Oct 2013 at 4:24

[GoogleCodeExporter]

I have a refactored version implemented in my local setup. But I cannot easily 
test it in an environment which is not supporting Unsafe properly, as I only 
have Windows, LInux or Mac OS X machines at my disposal. I could commit my 
changes to the trunk and let you try it out

-Leo 

Original comment by romixlev on 21 Oct 2013 at 4:30

[GoogleCodeExporter]

If you can give me a snapshot jar that I can drop in, I'll give it a run.

Original comment by zsol...@gmail.com on 21 Oct 2013 at 4:39

[GoogleCodeExporter]

OK. Changes are just committed and snapshots should be automatically published 
(soon, may be in one hour or a bit earlier) in this Sonatype repository:
https://oss.sonatype.org/content/repositories/snapshots/com/esotericsoftware/kry
o/kryo

Please read the home page to find out how to use this repo (it provides a Maven 
snippet to use).

I'd be really interested to hear if my changes solve problems with Unsafe.

Original comment by romixlev on 21 Oct 2013 at 4:46

[GoogleCodeExporter]

Could try firing up a non-Sun VM.

Original comment by nathan.s...@gmail.com on 21 Oct 2013 at 11:01