Question

TFile depends on java.nio.file.Path (toPath() method returns java.nio.file.Path) that isn’t available on Java 6 so calling any TFile method on Java 6 throws “java.lang.NoClassDefFoundError: java/nio/file/Path”

How do you manage to use TFile on Java 6? What I’m thinking of is getting the sources, re-compiling them without this method and using a patched version which is kind of unpleasant solution.

Answer 1

No, TrueZIP 7 does not require JSE 7, JSE 6 is enough as the home page documents. However, some features are only available on JSE 7 (e.g. the TrueZIP Path module) and hence a run time test is performed.

With correct class loader implementations you will never see NoClassDefFoundError. However, some environments have broken class loader implementations which do eager class loading – despite the lazy class loading which is mandated by the spec. Only then you would get a NoClassDefFoundError.

On another note, please mind the Eclipse license of the project. If you really wanted to fix this by patching (you can’t because there are circular dependencies between java.io.File and java.nio.file.Path which are the reason for this design), then you would have to publish this fork.

Appendix:

The Java Language Specification for Java 6, chapter 12.2.1 “The Loading Process” reads:

Different subclasses of ClassLoader may implement different loading policies. In particular, a class loader may cache binary representations of classes and interfaces, prefetch them based on expected usage, or load a group of related classes together. These activities may not be completely transparent to a running application if, for example, a newly compiled version of a class is not found because an older version is cached by a class loader. It is the responsibility of a class loader, however, to reflect loading errors only at points in the program where they could have arisen without prefetching or group loading.

English isn’t my mother tongue, but I take it from the last sentence that eager class loading is OK as long as the class loader doesn’t throw up just because an unused class failed to load eagerly. So if a class loader throws up because TFile.toPath() needs to return a java.nio.file.Path although you never call this method then I consider this to be a problem with the class loader. As an aside, TFile.toPath() throws an UnsupportedOperationException – please check the Javadoc for details.

I would have preferred to take another route but the circular dependency between java.io.File.toPath() and java.nio.file.Path.toFile() left me with no choice.