On Thursday, January 31, 2019 at 8:35:15 AM UTC+1, Jens wrote:
>
>
> Likewise, has someone had the chance to look at Java 9+ support for our
>> ant build?
>>
>
> I tried building GWT a few days ago with Java 11. Seems like we first have
> to apply the patch of Andrei (
>
> Likewise, has someone had the chance to look at Java 9+ support for our
> ant build?
>
I tried building GWT a few days ago with Java 11. Seems like we first have
to apply the patch of Andrei
(https://gwt-review.googlesource.com/c/gwt/+/2) and then make javadoc
API available
to
Colin, Thomas;
Since Google doesn't utilize all the code paths, I think it is important to
manually test these in supported JVMs by our contributors. Any place that
might have different classpath entries or places with potentially different
class loaders probably good places to verify; like
The correct link for the patches are
https://gwt-review.googlesource.com/#/c/19000/
https://gwt-review.googlesource.com/#/c/19020/
On Wed, Jul 26, 2017 at 6:29 PM, Roberto Lublinerman
wrote:
> I have uploaded two patches for review to allow GWT to run under a Java 9
> vm.
>
I have uploaded two patches for review to allow GWT to run under a Java 9
vm.
https://gwt-review.googlesource.com/#/c/19000/
https://gwt-review.googlesource.com/#/c/19001/
The main issue is (as noted by James) that the class loading has been
revamped and GWT can no longer assume that the class
>
>
> It is my understanding that we use ASM to load the annotation attributes
> from source classes, and then create a Proxy to load member values /
> classes / enums off the classpath. JDT is not involved at all (strange
> that it isn't...).
>
>
The most likely reason we aren't using JDT
>
>
> Fwiw, I think it would work, according to
> https://github.com/AdoptOpenJDK/openjdk-jdk9/blob/f9129bba032f3b75be9b67f45636f76940e029a6/jdk/src/java.base/share/classes/jdk/internal/loader/ClassLoaders.java#L70-L73
> (for now, I'm not interested in supporting modules, just making GWT 2 work
On Tuesday, June 13, 2017 at 5:55:33 PM UTC+2, James Nelson wrote:
>
>
>> 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
>>
>
>
> 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
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
>
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
>
> Are there specific Java9 JRE classes that we should focus on to get into
> GWT?
>
>
I didn't go through the full changelog, but I believe there have been more
helper methods added to Optional and other classes; will need emul updates
for sure.
> Would making GWT support Java9 sources
Are there specific Java9 JRE classes that we should focus on to get into
GWT?
Would making GWT support Java9 sources and running in a Java9 env cause
backward incompatible changes that prevent GWT from running in Java8?
On Wednesday, June 7, 2017 at 2:56:46 PM UTC-5, James Nelson wrote:
>
> As
As I've mentioned
elsewhere, https://plus.google.com/+JamesNelsonX/posts/gBfpBDnwV9V , java 9
support is entirely possible.
When I last tried it out, it required a fair number of hacks, but it worked
fine.
I expect the final version of java 9 modules to require slightly fewer
hacks,
and for
14 matches
Mail list logo