So, to be pedantic: Language features -> no issues there at all, since JDT happily compiles java 8 code w/ a java 9-compatible compiler. Emul updates -> standard "don't use java 9 methods if you need java 8 support" Classpathery -> Made it use ugly reflection to not require java 9 classes on classpath; it does require more opening of modules and ugliness, but ensures that we don't break when using java 8.
I'm actually using the java 9 compatible version of gwt daily in java 8 code. we could make the classpath nastiness a little better using sane feature detection and loading classes that don't need (as much) reflection to be able to extract the URLs from java 9 classloader... ...however, long term, I still think that we should reconsider how ResourceLoader works, and possibly consider something that accepts classpaths as arguments. It's fairly trivial to have arbitrary java code use maven to cache/download dependencies, so we could, technically, get classpath into Gwt without relying on classloader scanning. That would be a broader discussion to have though. The one big caveat is code modularity. We can't release two jars with code in the same packages (unless recent changes to module system now allowed "concealed package conflicts"). So, that means either one big, ugly uber-jar for compilation (my hack unzips gwt-user and gwt-dev locally to avoid these issues)... or we actually, finally modularize the codebase. Given the intent to rip out useful bits and get them supported in the 3.X line, I'd angle towards modularization as that is necessary anyway to create smaller, independent libraries. -- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/c3dc1778-a6a2-4a7c-b760-1c09f1212974%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
