> EG I haven't yet tested for JAR drop-in compatibility, eg if in 3.1 we > wanted to swap in more generics, would a 3.0 app be able to drop in > the 3.1 Lucene jar w/o problems?
It should, because in the compiled JVM code, generics do simply not appear. This is why you can simply run a very old java class file using the collection API with generics in Java 1.5 or 6. So you see, the best example is Java itself. Old programs e.g. link to ArrayList, but Java 1.5 has ArrayList<Something>. The program will simply run, there changed nothing in the code semantics, only in compile time semantics. The only thing: Somebody compiling code with Java 1.5, that was written for older Lucene, but using a new generics-enabled Lucene would get warnings about unsafe use of generics APIs. Sun states: "Generics are implemented by type erasure: generic type information is present only at compile time, after which it is erased by the compiler. The main advantage of this approach is that it provides total interoperability between generic code and legacy code that uses non-parameterized types (which are technically known as raw types). The main disadvantages are that parameter type information is not available at run time, and that automatically generated casts may fail when interoperating with ill-behaved legacy code. There is, however, a way to achieve guaranteed run-time type safety for generic collections even when interoperating with ill-behaved legacy code." (http://java.sun.com/j2se/1.5.0/docs/guide/language/generics.html) Uwe --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
