Frequently asked question about Externalizer4J. If you have some questions that are not answered below please do not hesitate to contact us.

Q: Which version of Java are supported?
A: All versions of Java are supported, including Java 8.

Q: Is Externalizer4j working at the level of the source code?
A: No, bytecode analysis and generation are used. No access to the source code is needed.

Q: Does Externalizer4J generate some intermediate Java source which gets compiled later on by the java compiler?
A: The optimization occurs after compilation directly on the bytecode. There is no source code generation.

Q: What if I implemented readObject() and writeObject() already?
A: Externalizer4jJ will leave your class unchanged

Q: Can I prevent certain class from being optimized?
A: One can specify exclusions to instruct Externalizer4j not to optimize classes

Q: Does Externalizer4j mean an additional library is needed at runtime?
A: No, Externalizer4j is a tool. It is not used at runtime at all.

Q: Will I still be able to set breakpoints while debugging? Some AOP transformations cause breakpoints to become invalid due to a mismatch between the source and bytecode.
A: Externalizer4j pays special attention not to interfere with existing code and line number information. Debugging is not adversely affected.

Q: Can I decompiled the code generated by Externalizer4j?
A: Yes, no problem. The generated code is not obfuscated. Therefore decompilers will be able to do their job well. We want users of Externalizer4j to able to inspect the code that gets generated so that they can trust it.

Q: Can I debug the code generated by Externalizer4j?
A: One can think of Externalizer4j as a special purpose compiler for serialization logic. As such it does not produce any java code (or .java file). There is not                                source to step through (see decompilation question).

Q: Since Externalizer4j works on the bytecode should I use it before or after a bytecode obfuscator?<br>
A: Externalizer4j analyzes your classes and class hierarchy and should not be affected by field and/or class renaming operations. Yet, we advise using Externalizer4j before any obfuscator to be on the safe side.

Q: Will the serialization logic handle backward compatibility when the class definition changes (add new a field for example)?
A: No, the serialization logic it tailored to the class definition. This allows the use of optimized serialization calls. If the class changes the logic and serialized data will be different. This is the big difference between the Serializable and Externalizable interfaces of the JDK.

Q: Does the optimization generate the serialVersionUID for each class? AspectJ for instance generates this serialVersionUID to preserve the serialization compatibility.
A: No serialVersionUID is being generated to avoid mixing up optimized and unoptimized classes! This is a safety precaution. Note that if the class already declares the serialVersionUID it will NOT be removed

Leave a Reply

Your email address will not be published. Required fields are marked *