On Thursday, June 8, 2017 at 12:13:35 AM UTC+2, James Nelson wrote:
>
> 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.
>
Could that work if we complemented the "instanceof URLClassLoader" with
some check for "is the system classloader" and then use
System.getProperty("java.class.path") (or the equivalent
ManagementFactory.getRuntimeMXBean().getClassPath()) to get the system
classpath entries? (do we also need the bootclasspath?)
> That would be a broader discussion to have though.
>
IIRC, when CodeServer was added, with its -src argument, I suggested
passing classpaths as argument rather than using the system classpath.
At the time though, there was even more code that relied on the context
classloader than today (rather than using the ResourceOracle). This was
fixed later for the most part, but I believe there's still code that uses
the context classloader (including looking up annotations from
com.google.gwt.core.ext.typeinfo, and AFAIK also JDT loading bytecode that
ends up being looked up in the context classloader;
see 8b584f412d055ff39949d8b28a8e78d6b0bfe9b6 for example)
I suppose that could be fixed by using a child URLClassLoader from the
classpath argument (that could be necessary anyway for generators and
linkers)
> 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").
>
Apparently
not:
http://openjdk.java.net/projects/jigsaw/spec/issues/#AvoidConcealedPackageConflicts
IIUC, they say this can be worked around using classloaders, or
shading/shadowing (i.e. what you're doing)
> 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.
>
Does that also apply to subpackage? Because it looks like the only
conflicting packages are c.g.g.core.client and c.g.g.core.shared, so maybe
moving classes around could be enough?
> 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/9d17a4b1-449e-42d4-914d-d7f0549d9a85%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
