Hi.
Per this thread:
-- Per this thread:
https://plus.google.com/+JamesNelsonX/posts/gBfpBDnwV9V
I have actually dove into Java 9 support, and cleared all the roadblocks once (before the JCP pushback force the module system to get more last minute changes).
The main issue was not language support (easy upgrade from eclipse jdt), or a tiny change for try-with-resources (allows effectively final variable references, instead of only local variable declarations)...
The biggest problem was the changes to the classloading system.
Specifically, they no longer use URLClassLoader for system classloaders, meaning that any attempts to "rip out the classpath" will not work any longer.
I managed to hack together a working compile where I check if java 9 classloaders are in use, and if so, use reflection (with requires --add-opens for using reflection on the classloader, plus opening the source module so that the gwt code can see external resources), to get access to those URLs.
What I did is only one way to fix; we could also add classpath declarations to gwt (I use an annotation system that can reference maven modules for my own compiles, so I could actually get classpath without looking inside classloader). There might also be less terrible hacks we can use once the module APIs are cemented in place.
If you really want to play with this RFN, I can push a build of my gwt fork to maven central for you to try out. I don't really have a snapshot repo, or time to respond to bugfixes atm (though I am considering opening a gwt support shop this fall, and will "do it right" at that time). If you are comfortable doing local installs to maven just to assess possibilities (or if you maintain your own nexus repo), I could just send you jars directly (though, that is generally a bit sketchy, imho).
I have actually dove into Java 9 support, and cleared all the roadblocks once (before the JCP pushback force the module system to get more last minute changes).
The main issue was not language support (easy upgrade from eclipse jdt), or a tiny change for try-with-resources (allows effectively final variable references, instead of only local variable declarations)...
The biggest problem was the changes to the classloading system.
Specifically, they no longer use URLClassLoader for system classloaders, meaning that any attempts to "rip out the classpath" will not work any longer.
I managed to hack together a working compile where I check if java 9 classloaders are in use, and if so, use reflection (with requires --add-opens for using reflection on the classloader, plus opening the source module so that the gwt code can see external resources), to get access to those URLs.
What I did is only one way to fix; we could also add classpath declarations to gwt (I use an annotation system that can reference maven modules for my own compiles, so I could actually get classpath without looking inside classloader). There might also be less terrible hacks we can use once the module APIs are cemented in place.
If you really want to play with this RFN, I can push a build of my gwt fork to maven central for you to try out. I don't really have a snapshot repo, or time to respond to bugfixes atm (though I am considering opening a gwt support shop this fall, and will "do it right" at that time). If you are comfortable doing local installs to maven just to assess possibilities (or if you maintain your own nexus repo), I could just send you jars directly (though, that is generally a bit sketchy, imho).
Let me know; I won't have time to do a release this weekend as it is my wife's birthday, but I can fit it in if you'd like (and the comments in the G+ post aren't helpful enough).
You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.
No comments:
Post a Comment