Summary: | JDT compiler bytecode incompatibility with JDK bytecode results in serialization error | ||
---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Eldon Metz <eldonm> |
Component: | Core | Assignee: | JDT-Core-Inbox <jdt-core-inbox> |
Status: | RESOLVED DUPLICATE | QA Contact: | |
Severity: | normal | ||
Priority: | P3 | CC: | eric.kaplan, martin.hackmann, stephen |
Version: | 2.1 | ||
Target Milestone: | 2.1 M5 | ||
Hardware: | PC | ||
OS: | Windows 2000 | ||
Whiteboard: |
Description
Eldon Metz
2003-01-24 16:04:28 EST
Unfortunately, the Java language specs does specify one particular implementation for the class literal. Our implementation is different from others, causing the serialization issues you are seeing; but none is more right than the other. Ours is generating more compact code (one method less). If the specs were enforcing one particular implementation to be the proper one, then we would follow it. On the other end, serialization should ignore synthetics, and it doesn't thus this is a dead-end. Your best take is to use the same binaries on the way in and out. Either use binaries from JDT or from a different compiler on both ends. Similar issues arise with local innerclasses. At last, you could resort to using the serialVersionUID trick to workaround these issues. Oops, my previous post should read: Unfortunately, the Java language specs does NOT specify one particular implementation for the class literal. Thanks for the detailed information and rapid response! When we ran into this a few weeks ago, we reverted to just using JDT compiled code everywhere. Has anyone pushed on Sun to improve serialization to ignore synthetics, or to at least remove this ambiguity in the specification? It seems, from my perspective, that even though the JDT code is a bit more compact, it would be great (for portability) to mimic what Sun has been doing until the specification or serialization issue can be worked out. Our primary concern was ensuring automated nightly builds using ant produced the same bytecode the development machines produced so that a complex deployment of a multi-tier system where serialization is used to move data between tiers would succeed. We successfully worked around the issue by replicating the eclipse build process using ant with the build.compiler property set to org.eclipse.jdt.core.JDTCompilerAdapter. It would have been extremely beneficial if Eclipse included a Export to Ant build script feature or a way to execute Eclipse in headless mode from the command-line, as we had to replicate the eclipse setup manually in the ant build script. Eclipse can certainly be run in headless mode, and in particular the JDT/Core component will run under these conditions (no dependency on UI code). You could setup a workspace in headless mode (our test suites are precisely doing it, you could check org.eclipse.jdt.core.tests.model project on dev.eclipse.org). As for getting Sun to spec either serialization or compiler internals, I remember hearing one of the language guru clearly saying no. This is very unfortunate, and trying to mimic some unspecified behavior is hard (adjusting on a moving target). I think using the same binaries on both ends is the only true answer. FYI, we recently made a couple fixes to our compiler which could result in some serialization issues with respect to serialized instances of local innerclasses (we posted it on jdt-core-dev mailing list). This to say that binaries have to be produced with the exact same compiler to be trustable (same vendor, same version) to be reliable. Hope this helps, and anyway thanks for your original diagnosis of this issue. Won't change current implementation unless spec would. *** Bug 30357 has been marked as a duplicate of this bug. *** *** Bug 32227 has been marked as a duplicate of this bug. *** *** Bug 37328 has been marked as a duplicate of this bug. *** Should have been tagged as duplicate *** This bug has been marked as a duplicate of 10104 *** |