The reflection stuff is required to get all required information to recreate an instance ofĪ Java type at unmarshalling time. XStream fails since Java 17, because types in modules cannot be accessed from the unnamed module!Īgain, this is normal. You will have to permit this access currently, otherwise XStream will not work. A big part of XStream is reflection based and there is currently no replacement for theĬomplete required functionality. Java runtime warns me about an illegal reflective access by XStream! This mode has some restrictions though: Feature In a secured secured environment, older Java run times or a limited Java environment might prevent the usage of theĮnhanced mode and XStream uses the plain Java API as fallback. Mode uses some undocumented, but wide-spread available functionality to recreate such instances nevertheless. What are the advantages of using enhanced mode over pure Java mode?Ĭurrently it is not possible to recreate every instance of a type using the official Java API only. Since Java 9 it is required to permit the now illegal access. Note, that an active SecurityManager might prevent the usage of the enhanced mode also. The enhanced mode as well as the Google Application Engine, but the latter's security model limits the types thatĬan be handled. Generally it works for all modern Java runtimes based on OpenJDK. This enhanced mode is known to be working on the Oracle/Sun, Apple, HP, IBM and Blackdownġ.4 JVMs and onwards, for IcedTea 6 and onwards, for Hitachi, SAP and Diablo from 1.5 and onwards, for BEA JRockit XStream checks since version 1.4.5 automatically for a working enhanced mode - based on undocumented internal Which JVMs allow XStream to operate in enhanced mode? XStream does not have these limitations, however this mode of operation is not available to all JVMs. Reflection allows, meaning it cannot serialize certain classes or fields. XStream behaves in the same way across different JVMs, however its features are limited to what XStream has two modes of operation: Pure Java and Enhanced. Does XStream behave differently across different JVMs? Note, that XStream's manifest contains OSGi entries that declare all dependencies as optional.
Or the StAX driver in combination with Java 6 or greater. XStream will run without dependencies using the DOM driver on all Java runtimes Which dependencies are required to run XStream?Īll dependencies are optional, XStream uses since version 1.4.1 by default xpp3:xpp3_min and xmlpull:xmlpull. Note, that such Java archives will fail on higher Java runtimes then. Depending on the target environment this can be useful (e.g. Otherwise the resulting jar file will miss some class files not available onĮarlier runtimes. However, to support the latest features it XStream 1.4.x can be build still with JDK 1.4 (see BUILD.txt). You can build your own version of XStreamįor Java 9 and later you will currently have to permit the now illegal access for XStream to operate.
Is running on an appropriate runtime environment.Įnvironments that load all class files of a Java archive can fail with this approach, theĪndroid runtime is such an example. These classes are loaded by reflection and only used if XStream Note, that the XStream libraries contains class files targetingĭifferent Java runtime versions or Java features. XStream 1.4.x requires Java 1.4 or later. You still need custom deserialization for singletons so that you always get the same object back.Ģ.Compatibility Which Java runtime is required to run XStream? Let me make a couple of additional points.ġ. I’ll flag the main body content accordingly. Thanks for the really clear counterexample. ObjectInputStream in = new ObjectInputStream(new FileInputStream(“r”)) ObjectOutputStream out = new ObjectOutputStream(new FileOutputStream(“r”)) Public static void main(String args) throws FileNotFoundException, IOException, ClassNotFoundException Suppose we have a simple immutable class we want to serialize: Java lets you take complete control over serialization, and I strongly advise you to use this control for forward compatibility, working around non-serializable (but constructable) member objects like singletons, and minimizing the size of serialized objects.
Josh Bloch discusses the serialization proxy pattern in the very last section of the second edition of Effective Java. I decided to kick up the abstraction level of the answer and discuss LingPipe’s serialization proxy approach to serializing everything, including singletons and immutables.
A question recently came up on our mailing list/newsgroup that asked how to implement java.io.Serializable for classes containing non-serializable singletons.