On Wednesday, October 3, 2012 7:10:28 PM UTC+2, fabrizio.giudici wrote: > > > Let's first reset the discussion and have a check on a piece of > information of mine that I'm probably getting wrong. I'm still assuming > Java 8 will do generics reification. Is this right? > > No, that is most definitely not in the cards, and it was only a very small maybe for a very short period of time. Generics Reification is highly unlikely to show up in 9, either.
> > Let's define my concept of backward-compatible in this scenario. I'm a > corporate, I have a large codebase in Java 6 (for instance). My upgrade to > > JAva 7 will be incremental and made by a path such as: > > 1. I move to JDK 7 with --source --target 6 and check whether it runs on > JDK 6. Eventually I fix things so this happens. > This is a strange decision; you're sticking with java6 (the language) and java6 (the class file format), but you're moving to java7 (the runtime library), by doing this, except that last part is a mix of what you compile against and what you run on (are you running on JVM7 or JVM6 with the class files that fall out of this compile run?) If JVM6, then you should probably also use a JVM6 bootclasspath. However, at that point, what are you really testing here? Every javac ever released gets this right, with extremely tiny edge cases where it doesn't (such as trying to call a private method on a parameterized type whose erasure matches your own type. This was legal in Java6 and Java5, and is not legal on Java7, even with --source 1.6). > 2. Then I check whether the thing runs on JDK 7. Eventually I fix things > so this happens. At this point I'm mostly happy, since the biggest trouble > > with Java 6 is when it goes EOL. Now I'm on a runtime that is still > getting patches. > Okay, but this is a _much_ more complex switch than making sure your code compiles when using -source 1.7 -target 1.7. Of course, if you do that, you HAVE TO run on JVM7, because JVM6 won't accept the output, and you can't make an intermediate step with -source 1.7 -target 1.6, because javac does not accept that. > 3. I now move to --source --target 7. Eventually I fix things so this > happens. > Right, so this is pretty much a gimme when you've gotten this far. > 4. At this point, I can incrementally start using features of Java 7. > > Sure. > "Fix things so this happens" admits that I have some work to do, if this > work is very well confined I still call it (practical) backward > compatibility of a new JDK. Perhaps I'm using the wrong term? > > Java8 will also give you the opportunity to use the above schedule. Nothing will change; javac8 will accept -source 1.7 -target 1.7 and will produce class files that run just fine on either JVM7 or JVM8, and you are quite unlikely to run into any issues when you do so. When you are ready, you can take your 1.7 source files and compile them using javac8 -source 1.8 -target 1.8 and it'll most likely compile just fine with no errors. The biggest clash here will be 'default' methods and how there might be some weirdness if you e.g. extended java.util.List with a custom class and gave it a sort() method. That SHOULD work fine, but I can foresee some minor issues there. At that point you can start using J8 features. That was my point, really: Java 8 is no different from java7, 6, 5, 4, 3, 2, or 1.1. In fact, it is 'nicer' - java4 and java5 remain the least backwards compatible releases; java4 introduced 'assert', and java5 introduced thousands of warnings if you tried to compile java4 code on it with -source 1.5. -- You received this message because you are subscribed to the Google Groups "Java Posse" group. To view this discussion on the web visit https://groups.google.com/d/msg/javaposse/-/pVK4j6roM0kJ. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
