Hello there, I've been reading some documentation including JSR for the new Safe Type Enum feature in JDK1.5. Our group is considering the development of our own Safe Type Enum pattern or the adoption of the new JDK1.5 feature. As it is stated in the JSR for this new feature: "The proposed enum facility requires no JVM changes. It is implemented in the compiler with support from the libraries. Attributes are used to identify enum classes and enum constants in class files (JVMS 4.7). The enum facility interacts well with other language work proposed for Tiger, notably the static import statement, the enhanced for statement, and generics." It is not clear in this statement if classes compiled with this new feature could run in a 1.4, 1.3, 1.2 JRE. It seems that JVM is compatible but some kind of base class would be needed to run with this new feature. It is supposed that this new class will be part of the rt.jar for 1.5 version but, then the real fact would be that the compilad class wouldn't run in a 1.4/1.3/1.2 environment because rt.jar doesn't include this new enum class. Anyone there working in this can give us a little bit of light of this before new JDK1.5 is released. We should decide just now an strategy to follow. Many many thanks, Rafael Torcida Fern�ndez Dynasty Technology Group
Cindy Glass
"The Hood"
Sheriff
Joined: Sep 29, 2000
Posts: 8521
posted
0
This is true of any release. They are backwards compatible (for the most part) but not forwards compatible. Something compiled in 1.4 may well not run correctly in a 1.3 JVM. Something compiled in 1.5 will probably not run in the 1.4 rt environment. However stuff compiled in 1.3 or 1.4 will (with a few exceptions) run just fine in the 1.5 JVM and rt environment. Which is essentially the same situation as if you decide to implement your own enum functionality. You will have to include the classes that you write to implement enums in your release, or it won't work. However, with the 1.5 release only months away from beta, it seems a waste of your time to try to duplicate what Sun is doing, and your solution will not integrate with the other new functionality very well. I suppose that it depends on your deadlines.
"JavaRanch, where the deer and the Certified play" - David O'Meara
Jim Yingst
Wanderer
Sheriff
Joined: Jan 30, 2000
Posts: 18670
posted
0
However, with the 1.5 release only months away from beta, it seems a waste of your time to try to duplicate what Sun is doing, and your solution will not integrate with the other new functionality very well. But if Rafael needs to target 1.3 and 1.4 JVMs, 1.5 won't really help anyway. The new enum functionality does depend on an Enum class, and older JVMs won't have it. The "other new functionality" will also not work on the target VMs. Which is essentially the same situation as if you decide to implement your own enum functionality. You will have to include the classes that you write to implement enums in your release, or it won't work. Right - the difference though is that you can include those classes, if they're your own custom classes, without worrying too much about the JVM version. You just include the classes in the jar file that you would have had to distribute anyway in odrer to install your application. But if you use 1.5's functionality, you basically have to force all the clients to upgrade to 1.5. Historic note - back when collections were introduced to Java (1.2), you could use them in 1.1 applications if you included a a special jar file Sun had released for this purpose - collections.jar. Though as I recally there were a few little differences between the versions; it was annoying to switch from 1.1 collections.jar to 1.2 collections. And it made figuring out environments a pain. I think Sun has chosen to keep things simpler nowadays by not trying to support this type of forward compatibility. The goal seems to be to discourage people from trying to use complex hybird environments with an old JVM and a bunch of extra customizations to use newer eatures along with the old JVM. Instead, if you want to use the new features, ya gotta upgrade the JVM. Period. I'm not entirely happy with this approach, but it does keep things simpler.
0
