OpenJDK/IcedTea support

Patch attached.

Sorry, but I don't understand this one. icedtea-6/7 identifies itself with vendor Oracle (7) or Sun (6) and XStream runs therefore already flawlessly in enhanced mode on this JVM. However, JamVM from JENKINS-10752 is a different story. I have on my Gentoo box latest version 1.5.4 installed and its runtime does not contain sun.reflect.ReflectionFactory used by Sun14ReflectionProvider. So XStream cannot run in enhanced more with this JVM as long as it has no alternate implementation (for some time we had an alternative one for Harmony, but I never got it stable and it has been ditched in the meanwhile).

I don't personally have any environment to test this out myself.

I do know the guy who reported the problem — he is at Canonical and he maintains the Jenkins package for the official Ubuntu repository, so I just generally trust what he's doing. https://bugs.launchpad.net/ubuntu/+source/jenkins-xstream/+bug/827463 sheds more light into this, and here is how I understand this patch.

JamVM is just a JVM, so it needs to "borrow" class libraries from somewhere else. According to that Wikipedia article, it supports GNU Classpath and OpenJDK, and in case of Ubuntu it uses OpenJDK class libraries (which presumably also includes its native counterparts.) This is the combination that supports sun.misc.Unsafe that the author wanted to make work.

While it is possible to detect JamVM as a JVM vendor, this won't be accurate because whether the enhanced mode is available or not depends on the choice of class libraries — JamVM+GNU classpath will presumably not work in this mode. So the author opted to check java.runtime.name.

As you observed, if you are to run Hotspot JVM in OpenJDK (with its associated class libraries), it identifies the vendor to be Oracle/Sun, but it won't if you are to run JamVM + OpenJDK class libraries.

Given your observation about JamVM 1.5.4 on Gentoo, I assume there are some combinations of JamVM + some class libraries that do not have sun.misc.Unsafe (what class libaries do your JamVM uses? GNU Classpath or OpenJDK?), but given that you check the existence of sun.misc.Unsafe anyway, I claim that this patch is the correct fix to the problem.

(Zero VM is probably another JVM that would benefit from this patch, as it probably reports yet separate vendor name.

Note, it is not sun.misc.Unsafe! That one is present. JamVM on Gentoo is using GNU classpath and that one is missing sun.reflect.ReflectionFactory. I'll investigate a bit ...

Perhaps would it be more productive if we rewrite JVM.canUseSun14ReflectionProvider() such that it actually tests if all the relevant classes and methods are present and usable, as opposed to trying to guess whether Sun14ReflectionProvider can be used from other circumstancial evidence?

The code as it is today does feel like a browser capability detection badly done (i.e., "check if the user agent is IE, and if so I can't use window.dispatchEvent")

I can change Sun14ReflectionProvider constructor so that it calls its own methods with some harmless parameters to check if it's functioning correctly, then all that we have to do is to try to instantiate Sun14ReflectionProvider then fall back to PureJavaReflectionProvider.

This code predates my involvement in XStream. However, as it turns out, we do not need the ReflectionFactory at all, since Unsafe has a method allocateInstance that will also create an instance without calling any ctor or initializer. And I've verified, that it also works for IBM JDK 1.4 and Blackdown JDK 1.4. On top of it we get rid of the constructor cache

It seems my enthusiasm was a bit early. As it turns out, GNU Classpath's Unsafe does not have an allocateInstance method

Your patch will not work either, because it looks for the value of system property java.runtime.name, but it is not specified and the value is therefore null.

For icedtea-6 I get following interesting values:

java.specification.version: 1.6
java.specification.vendor: Sun Microsystems Inc.
java.specification.name: Java Platform API Specification
java.vm.vendor: Sun Microsystems Inc.
java.vendor: Sun Microsystems Inc.
java.vm.name: OpenJDK 64-Bit Server VM

while JamVM on Gentoo reports:

java.specification.version: 1.5
java.specification.vendor: Sun Microsystems, Inc.
java.specification.name: Java Platform API Specification
java.vm.vendor: Robert Lougher
java.vendor: GNU Classpath
java.vm.name: JamVM

It is really nonsense to check for the vendor name just to determine the support of Sun14ReflectionProvider ... especially when I look at this method in JVM:

    private boolean canUseSun14ReflectionProvider() {
        return (isSun()
            || isOracle()
            || isApple()
            || isHPUX()
            || isIBM()
            || isBlackdown()
            || isBEAWithUnsafeSupport()
            || isHitachi()
            || isSAP() 
            || isDiablo())
            && is14()
            && loadClass("sun.misc.Unsafe") != null;
    }

Room for improvement ...

I've implemented now a dynamic detection of a working enhanced mode with Sun14ReflectionProvider. Fixed in trunk.