Java10 support

[Alexander Leshkin]

Is there anyone who works on Java10 support? I mean dependencies update (ASM, JDT) and new language feature - Local-Variable Type Inference.

If not, I can try to create PR.

[Jens]

Is there a stable Eclipse JDT release supporting local variable type inference? Doesn't look like Eclipse itself already supports Java 10 language features.

-- J.

[Alexander Leshkin]

There is no stable JDT release yet (only RC), but it's scheduled in middle of April. So, some work on this one already may be started.

[Thomas Broyer]

On Tuesday, April 3, 2018 at 9:00:32 AM UTC+2, Alexander Leshkin wrote:

Is there anyone who works on Java10 support? I mean dependencies update (ASM, JDT) and new language feature - Local-Variable Type Inference.

If not, I can try to create PR.

The first thing is to make sure GWT works with a Java 10 runtime (net.ltgt.gwt.maven:gwt-maven-plugin currently does not, it throws an NPE in gwt:test, I need to upgrade surefire; but apparently GWT itself does work, at least the compiler).

The next step will be to support Java 10 APIs (we still have some Java 9 ones to add) and language features.

Overall, I think most importantly the work shouldn't really be about Java 10 per se, but rather preparation for Java 11 (the next LTS release)  in 6 months and the EOL of Java 8 in 9 months or so. In other words, I, for one, don't really care whether GWT supports Java 10 (it should at least "run" in Java 10 runtime though), as long as it'll be ready for Java 11.

[Jens]

The next step will be to support Java 10 APIs (we still have some Java 9 ones to add) and language features.

I have a partial JDiff report (some packages still missing) between current GWT HEAD emulation and JDK 10. It is a bit annoying to run javadoc/jdiff against GWT HEAD emulation as it does not have module-info files but with some preprocessing it is doable. So soon I could either publish the jdiff result or directly create github issues for everything I think should be emulated. Might also be a good thing to attract some new contributors.

 

Overall, I think most importantly the work shouldn't really be about Java 10 per se, but rather preparation for Java 11 (the next LTS release)  in 6 months and the EOL of Java 8 in 9 months or so. In other words, I, for one, don't really care whether GWT supports Java 10 (it should at least "run" in Java 10 runtime though), as long as it'll be ready for Java 11.

For now Java 11 only seem to have JEP 323 which seem relevant for GWT. Depending on how JDT has implemented the "var" keyword, changes in GWT compiler might be minimal when adding Java 11 support (assuming Java 10 support is already done).

-- J.

[Roberto Lublinerman]

 

Overall, I think most importantly the work shouldn't really be about Java 10 per se, but rather preparation for Java 11 (the next LTS release)  in 6 months and the EOL of Java 8 in 9 months or so. In other words, I, for one, don't really care whether GWT supports Java 10 (it should at least "run" in Java 10 runtime though), as long as it'll be ready for Java 11.

For now Java 11 only seem to have JEP 323 which seem relevant for GWT. Depending on how JDT has implemented the "var" keyword, changes in GWT compiler might be minimal when adding Java 11 support (assuming Java 10 support is already done).

My guess it that both JEP 286 and JEP 323 will be transparently handled by JDT requiring no actual changes to GWT. The main issue in general upgrading JDT are changes in type inference which render some valid programs invalid (e.g. last update required a change to daggerhttps://github.com/google/dagger/commit/4e74fcefd7bb3b3d2d49a93c4bca39e5eb1c7277) and performance degradation.

[Alexander Leshkin]

 

Overall, I think most importantly the work shouldn't really be about Java 10 per se, but rather preparation for Java 11 (the next LTS release)  in 6 months and the EOL of Java 8 in 9 months or so. In other words, I, for one, don't really care whether GWT supports Java 10 (it should at least "run" in Java 10 runtime though), as long as it'll be ready for Java 11.

For now Java 11 only seem to have JEP 323 which seem relevant for GWT. Depending on how JDT has implemented the "var" keyword, changes in GWT compiler might be minimal when adding Java 11 support (assuming Java 10 support is already done).

My guess it that both JEP 286 and JEP 323 will be transparently handled by JDT requiring no actual changes to GWT. The main issue in general upgrading JDT are changes in type inference which render some valid programs invalid (e.g. last update required a change to daggerhttps://github.com/google/dagger/commit/4e74fcefd7bb3b3d2d49a93c4bca39e5eb1c7277) and performance degradation.

I tried "var type" with latest JDT RC. And for exact, denotable types GWT works fine without any changes in compiler. JDT AST already contains inferred type for local variable. E.g.:

var s = "s";

in type binding looks like 

String s = "s";

But for non-denotable types GWT compiler breaks with assertion. E.g. it breaks for anonymous local class:

var tuple = new Object(){ int first, second; };

It's because type binding for this declaration looks like:

$Local$ tuple = new Outer$1();

So,it looks like some changes in GWT compiler still have to be made to support JEP 286.

[Roberto Lublinerman]

On Wed, Apr 4, 2018 at 12:36 AM Alexander Leshkin <alexande...@gmail.com> wrote:

But for non-denotable types GWT compiler breaks with assertion. E.g. it breaks for anonymous local class:

var tuple = new Object(){ int first, second; };

It's because type binding for this declaration looks like:

$Local$ tuple = new Outer$1();

So,it looks like some changes in GWT compiler still have to be made to support JEP 286.

In any  case, I don't expect the compiler changes to be significant. There are no new abstraction to be introduced nor structural changes. Could you start adding tests to GwtAstBuilderTest for these cases, even if they have to be disabled or commented out. 

BTW, which assertion is failing, is it one in JProgram.createLocal?

[Alexander Leshkin]

On Wednesday, April 4, 2018 at 7:17:18 PM UTC+3, Roberto Lublinerman wrote:

In any  case, I don't expect the compiler changes to be significant. There are no new abstraction to be introduced nor structural changes. Could you start adding tests to GwtAstBuilderTest for these cases, even if they have to be disabled or commented out. 

Yes, all i had to do to make non-denotable type to work, is to replace `$Local$` type with anonymous synthetic class name `Outer$1` when creating JClassType for JLocal.

Regarding tests - are you sure that GwtAstBuilderTest is a sutable place for these tests? I noticed that Java9 tests were placed into the new class Java9AstTest.

 

BTW, which assertion is failing, is it one in JProgram.createLocal?

 

No, it is UnifyAst:

Compiling module sample.Java10
   [ERROR] Could not find $Local$ in types compiled from source. Is the source glob too strict?
   [ERROR] An internal compiler exception occurred
com.google.gwt.dev.jjs.InternalCompilerException: Unexpected error during visit.
 at com.google.gwt.dev.jjs.ast.JVisitor.translateException(JVisitor.java:111)
 at com.google.gwt.dev.jjs.ast.JModVisitor.acceptImmutable(JModVisitor.java:313)
 at com.google.gwt.dev.jjs.ast.JMethodBody.traverse(JMethodBody.java:82)
 at com.google.gwt.dev.jjs.ast.JModVisitor.traverse(JModVisitor.java:361)
 at com.google.gwt.dev.jjs.ast.JModVisitor.accept(JModVisitor.java:273)
 at com.google.gwt.dev.jjs.ast.JModVisitor.accept(JModVisitor.java:265)
 at com.google.gwt.dev.jjs.ast.JMethod.visitChildren(JMethod.java:786)
 at com.google.gwt.dev.jjs.ast.JMethod.traverse(JMethod.java:778)
 at com.google.gwt.dev.jjs.ast.JModVisitor.traverse(JModVisitor.java:361)
 at com.google.gwt.dev.jjs.ast.JModVisitor.accept(JModVisitor.java:273)
 at com.google.gwt.dev.jjs.ast.JModVisitor.accept(JModVisitor.java:265)
 at com.google.gwt.dev.jjs.impl.UnifyAst.mainLoop(UnifyAst.java:1401)
 at com.google.gwt.dev.jjs.impl.UnifyAst.exec(UnifyAst.java:896)
 at com.google.gwt.dev.jjs.JavaToJavaScriptCompiler.unifyJavaAst(JavaToJavaScriptCompiler.java:1410)
 at com.google.gwt.dev.jjs.JavaToJavaScriptCompiler.constructJavaAst(JavaToJavaScriptCompiler.java:1222)
 at com.google.gwt.dev.jjs.JavaToJavaScriptCompiler.precompile(JavaToJavaScriptCompiler.java:1140)
 at com.google.gwt.dev.jjs.JavaToJavaScriptCompiler.precompile(JavaToJavaScriptCompiler.java:255)
 at com.google.gwt.dev.Precompile.precompile(Precompile.java:255)
 at com.google.gwt.dev.Precompile.precompile(Precompile.java:202)
 at com.google.gwt.dev.Precompile.precompile(Precompile.java:143)
 at com.google.gwt.dev.Compiler.compile(Compiler.java:204)
 at com.google.gwt.dev.Compiler.compile(Compiler.java:155)
 at com.google.gwt.dev.Compiler.compile(Compiler.java:144)
 at com.google.gwt.dev.Compiler$1.run(Compiler.java:118)
 at com.google.gwt.dev.CompileTaskRunner.doRun(CompileTaskRunner.java:55)
 at com.google.gwt.dev.CompileTaskRunner.runWithAppropriateLogger(CompileTaskRunner.java:50)
 at com.google.gwt.dev.Compiler.main(Compiler.java:125)
Caused by: java.lang.AssertionError
 at com.google.gwt.dev.jjs.impl.UnifyAst.translate(UnifyAst.java:1577)
 at com.google.gwt.dev.jjs.impl.UnifyAst.translate(UnifyAst.java:1590)
 at com.google.gwt.dev.jjs.impl.UnifyAst.access$1(UnifyAst.java:1586)
 at com.google.gwt.dev.jjs.impl.UnifyAst$UnifyVisitor.endVisit(UnifyAst.java:371)
 at com.google.gwt.dev.jjs.ast.JVisitor.endVisit(JVisitor.java:328)
 at com.google.gwt.dev.jjs.ast.JLocal.traverse(JLocal.java:55)
 at com.google.gwt.dev.jjs.ast.JModVisitor.traverse(JModVisitor.java:361)
 at com.google.gwt.dev.jjs.ast.JModVisitor.acceptImmutable(JModVisitor.java:305)
 ... 25 more
      [ERROR] at Java10Sample.java(14): $Local$ o
         com.google.gwt.dev.jjs.ast.JLocal
      [ERROR] at Java10Sample.java(13): <source info not available>
         com.google.gwt.dev.jjs.ast.JMethodBody
      [ERROR] at Java10Sample.java(13): sample.Java10Sample.onModuleLoad()V
         com.google.gwt.dev.jjs.ast.JMethod

[Roberto Lublinerman]

On Thu, Apr 5, 2018 at 2:07 AM Alexander Leshkin <alexande...@gmail.com> wrote:

Yes, all i had to do to make non-denotable type to work, is to replace `$Local$` type with anonymous synthetic class name `Outer$1` when creating JClassType for JLocal.

Ok.  So you changed GwtAstBuilder and to get the actual type from the typebinding in GwtAstBuilder.createLocal? Could you upload the patch to gwt so I can comment there? :) It might just be the case that because the variable declaration happens before the Anonymous inner class s created it has not been registered in typeMap, and probably this is the only case in which a variable declaration can have the type of local or anonymous class that is defined after.

I am guessing that your fix is in GwtAstBuilder. The error shows in UnifyAst only because the case is not properly handled in GwtAstBuilder. If not then that is where it should be.

Regarding tests - are you sure that GwtAstBuilderTest is a sutable place for these tests? I noticed that Java9 tests were placed into the new class Java9AstTest.

You can write it in either GwtAstBuilderTest or introduce a Java10AstTest. In any case you would want to add a programmatic assertion that the type of the variable is the anonymous class (something in the spirit of GwtAstBuilder.testIntersectionBound).

And also add integration tests in Java8Test (see how this is done because Java8Test is super sourced), you coul introduce Java10Test using Java8Test as a model.

[Alexander Leshkin]

On Thursday, April 5, 2018 at 9:02:51 PM UTC+3, Roberto Lublinerman wrote:

Could you upload the patch to gwt so I can comment there? :) It might just be the case that because the variable declaration happens before the Anonymous inner class s created it has not been registered in typeMap, and probably this is the only case in which a variable declaration can have the type of local or anonymous class that is defined after.

Ok. I'll prepare and upload the patch.

Thanks for pointing out the solution's direction.

[Roberto Lublinerman]

On Thu, Apr 5, 2018 at 10:59 PM Alexander Leshkin <alexande...@gmail.com> wrote:

Ok. I'll prepare and upload the patch.

Thanks for pointing out the solution's direction.

Np. Thanks for contributing to the compiler proper :).

I was giving another look at the code and the safest place to fix (if the problem is what I think it is) is in ReferenceMapper.createType. The name computed there assumes that is not a local class (not anonymous nor local) because locals and anonymous would be seen in the source before their usages and be registered as source types (not external).

I am not sure if the binding we get there from the variable is a LocalTypeBinding, but if it is, then you can extract the name computation from GwtAstBulider.createTypes and use it in both situations. If it is not a LocalTypeBinding you can actually just see if it is isAnonymousType() and and use a similar logic.

 

[Alexander Leshkin]

I'm stuck with a few issues in JDT compiler those make not possible to launch "super sourced" tests at source level >= 9.

So, I have to first make patches for JDT and create custom JDT build before proceeding with patch for JEP286.

Just for information.

The first issue with JDT is about how GwtIncompatible annotaion handled by the GWT compiler.

JDT AST TypeDeclaration may contains empty arrays of methods and fields after applying GwtIncompatible.

But JDT assumes that for type without methods and fields the corresponding members are equal to `null` instead of empty arrays.

E.g.: TypeDeclaration.java#L730

The line above throws AIOOBE for type wich methods had been removed due to GwtIncompatible.

On other side, this issue may be fixed on GWT side, I think.

The second issue is a bug with handling Deprecated annotation that was introduced in https://github.com/eclipse/eclipse.jdt.core/commit/79d5afecf5f237634a5562279fdceca6591b2b58.

This issue leads to AIOOBE when there is an annotation marked as Deprecated. I noticed this issue for GwtScriptOnly annotation.

[Roberto Lublinerman]

On Mon, Apr 9, 2018 at 11:19 PM Alexander Leshkin <alexande...@gmail.com> wrote:

I'm stuck with a few issues in JDT compiler those make not possible to launch "super sourced" tests at source level >= 9.

So, I have to first make patches for JDT and create custom JDT build before proceeding with patch for JEP286.

Hmm. One option is to wait till JDT stabilizes. The required patches are probably going to be part 4.8M7 (or whatever follows the M6). For testing purposes you could use  http://download.eclipse.org/eclipse/downloads/drops4/I20180409-2000/ or the latest or more stable integration build which contains the patches but you are probably using this one judging from the commit you are referencing at the end.

Just for information.

The first issue with JDT is about how GwtIncompatible annotaion handled by the GWT compiler.

JDT AST TypeDeclaration may contains empty arrays of methods and fields after applying GwtIncompatible.

But JDT assumes that for type without methods and fields the corresponding members are equal to `null` instead of empty arrays.

E.g.: TypeDeclaration.java#L730

The line above throws AIOOBE for type wich methods had been removed due to GwtIncompatible.

On other side, this issue may be fixed on GWT side, I think.

Yes, this can be fixed in GwtIncompatiblePreprocessor. Previously JDT used zero length arrays instead of null, but null should be fine if it doesn't trip any of our assumptions. 

 

The second issue is a bug with handling Deprecated annotation that was introduced in https://github.com/eclipse/eclipse.jdt.core/commit/79d5afecf5f237634a5562279fdceca6591b2b58.

This issue leads to AIOOBE when there is an annotation marked as Deprecated. I noticed this issue for GwtScriptOnly annotation.

Intermediate builds of JDT are normally quite fragile, I wouldn't be surprised if this is the case. Just out of curiosity what is it stack trace for this failure? Might it have been triggered by a changed assumption in JDT?

 

--
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 google-web-toolkit-co...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/37d9249d-0a6a-4403-b07d-e3cb09492bc5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Alexander Leshkin]

On Tuesday, April 10, 2018 at 8:21:59 PM UTC+3, Roberto Lublinerman wrote:

On Mon, Apr 9, 2018 at 11:19 PM Alexander Leshkin <alexande...@gmail.com> wrote:

I'm stuck with a few issues in JDT compiler those make not possible to launch "super sourced" tests at source level >= 9.

So, I have to first make patches for JDT and create custom JDT build before proceeding with patch for JEP286.

Hmm. One option is to wait till JDT stabilizes. The required patches are probably going to be part 4.8M7 (or whatever follows the M6). For testing purposes you could use  http://download.eclipse.org/eclipse/downloads/drops4/I20180409-2000/ or the latest or more stable integration build which contains the patches but you are probably using this one judging from the commit you are referencing at the end.

I'm currently using http://download.eclipse.org/eclipse/downloads/drops4/M-4.7.3aRC2-201803300640. The 4.7.3a must be the first stable JDT release with Java10 support.

I thought that after release it could be used for Java10 support in GWT compiler. But now it seems that JDT patch will not landed in 4.7.3a (https://bugs.eclipse.org/bugs/show_bug.cgi?id=532913#c15).

So, probably, I'll switch to 4.8M.

 

The second issue is a bug with handling Deprecated annotation that was introduced in https://github.com/eclipse/eclipse.jdt.core/commit/79d5afecf5f237634a5562279fdceca6591b2b58.

This issue leads to AIOOBE when there is an annotation marked as Deprecated. I noticed this issue for GwtScriptOnly annotation.

Intermediate builds of JDT are normally quite fragile, I wouldn't be surprised if this is the case. Just out of curiosity what is it stack trace for this failure? Might it have been triggered by a changed assumption in JDT?

This one is definitely an issue in JDT. It's not a GWT compiler issue. I see the same exception in Eclipse java editor for reproducible code snippet.

Anyway, here is the stack trace:

java.lang.ArrayIndexOutOfBoundsException: 3

at org.eclipse.jdt.internal.compiler.lookup.AnnotationBinding.addStandardAnnotations(AnnotationBinding.java:82)

at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.retrieveAnnotations(BinaryTypeBinding.java:1586)

at org.eclipse.jdt.internal.compiler.lookup.ReferenceBinding.getAnnotations(ReferenceBinding.java:993)

at org.eclipse.jdt.internal.compiler.problem.ProblemReporter.lambda$3(ProblemReporter.java:1822)

at org.eclipse.jdt.internal.compiler.problem.ProblemReporter$$Lambda$2/1844381234.get(Unknown Source)

at org.eclipse.jdt.internal.compiler.problem.ProblemReporter.deprecatedSinceValue(ProblemReporter.java:1841)

at org.eclipse.jdt.internal.compiler.problem.ProblemReporter.deprecatedType(ProblemReporter.java:1822)

at org.eclipse.jdt.internal.compiler.problem.ProblemReporter.deprecatedType(ProblemReporter.java:1808)

at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.checkAndRecordImportBinding(CompilationUnitScope.java:960)

at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.faultInImports(CompilationUnitScope.java:471)

at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.faultInTypes(CompilationUnitScope.java:501)

at org.eclipse.jdt.internal.compiler.Compiler.process(Compiler.java:878)

at com.google.gwt.dev.javac.JdtCompiler$CompilerImpl.process(JdtCompiler.java:283)

at org.eclipse.jdt.internal.compiler.Compiler.processCompiledUnits(Compiler.java:568)

at org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:468)

at org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:419)

at com.google.gwt.dev.javac.JdtCompiler.doCompile(JdtCompiler.java:1019)

at com.google.gwt.dev.javac.CompilationStateBuilder$CompileMoreLater.compile(CompilationStateBuilder.java:322)

at com.google.gwt.dev.javac.CompilationStateBuilder.doBuildGeneratedTypes(CompilationStateBuilder.java:616)

at com.google.gwt.dev.javac.CompilationStateBuilder$CompileMoreLater.addGeneratedTypes(CompilationStateBuilder.java:225)

at com.google.gwt.dev.javac.CompilationState.addGeneratedCompilationUnits(CompilationState.java:127)

at com.google.gwt.dev.javac.StandardGeneratorContext.finish(StandardGeneratorContext.java:551)

at com.google.gwt.dev.jjs.impl.UnifyAst$UnifyVisitor.createStaticRebindExpression(UnifyAst.java:526)

at com.google.gwt.dev.jjs.impl.UnifyAst$UnifyVisitor.createRebindExpression(UnifyAst.java:487)

at com.google.gwt.dev.jjs.impl.UnifyAst$UnifyVisitor.maybeHandleMagicMethodCall(UnifyAst.java:415)

at com.google.gwt.dev.jjs.impl.UnifyAst$UnifyVisitor.visit(UnifyAst.java:402)

at com.google.gwt.dev.jjs.ast.JMethodCall.traverse(JMethodCall.java:265)

at com.google.gwt.dev.jjs.ast.JModVisitor.traverse(JModVisitor.java:361)

at com.google.gwt.dev.jjs.ast.JModVisitor.accept(JModVisitor.java:273)

at com.google.gwt.dev.jjs.ast.JModVisitor.accept(JModVisitor.java:265)

at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:118)

at com.google.gwt.dev.jjs.ast.JCastOperation.traverse(JCastOperation.java:76)

at com.google.gwt.dev.jjs.ast.JModVisitor.traverse(JModVisitor.java:361)

at com.google.gwt.dev.jjs.ast.JModVisitor.accept(JModVisitor.java:273)

at com.google.gwt.dev.jjs.ast.JModVisitor.accept(JModVisitor.java:265)

at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:118)

at com.google.gwt.dev.jjs.ast.JCastOperation.traverse(JCastOperation.java:76)

at com.google.gwt.dev.jjs.ast.JModVisitor.traverse(JModVisitor.java:361)

at com.google.gwt.dev.jjs.ast.JModVisitor.accept(JModVisitor.java:273)

at com.google.gwt.dev.jjs.ast.JModVisitor.accept(JModVisitor.java:265)

at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:118)

at com.google.gwt.dev.jjs.ast.JDeclarationStatement.traverse(JDeclarationStatement.java:49)

at com.google.gwt.dev.jjs.ast.JModVisitor$ListContext.traverse(JModVisitor.java:88)

at com.google.gwt.dev.jjs.ast.JModVisitor.acceptWithInsertRemove(JModVisitor.java:331)

at com.google.gwt.dev.jjs.ast.JBlock.traverse(JBlock.java:94)

at com.google.gwt.dev.jjs.ast.JModVisitor.traverse(JModVisitor.java:361)

at com.google.gwt.dev.jjs.ast.JModVisitor.accept(JModVisitor.java:273)

at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:139)

at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:135)

at com.google.gwt.dev.jjs.ast.JMethodBody.traverse(JMethodBody.java:83)

at com.google.gwt.dev.jjs.ast.JModVisitor.traverse(JModVisitor.java:361)

at com.google.gwt.dev.jjs.ast.JModVisitor.accept(JModVisitor.java:273)

at com.google.gwt.dev.jjs.ast.JModVisitor.accept(JModVisitor.java:265)

at com.google.gwt.dev.jjs.ast.JMethod.visitChildren(JMethod.java:786)

at com.google.gwt.dev.jjs.ast.JMethod.traverse(JMethod.java:778)

at com.google.gwt.dev.jjs.ast.JModVisitor.traverse(JModVisitor.java:361)

at com.google.gwt.dev.jjs.ast.JModVisitor.accept(JModVisitor.java:273)

at com.google.gwt.dev.jjs.ast.JModVisitor.accept(JModVisitor.java:265)

at com.google.gwt.dev.jjs.impl.UnifyAst.mainLoop(UnifyAst.java:1401)

at com.google.gwt.dev.jjs.impl.UnifyAst.exec(UnifyAst.java:896)

at com.google.gwt.dev.jjs.JavaToJavaScriptCompiler.unifyJavaAst(JavaToJavaScriptCompiler.java:1410)

at com.google.gwt.dev.jjs.JavaToJavaScriptCompiler.constructJavaAst(JavaToJavaScriptCompiler.java:1222)

at com.google.gwt.dev.jjs.JavaToJavaScriptCompiler.precompile(JavaToJavaScriptCompiler.java:1140)

at com.google.gwt.dev.jjs.JavaToJavaScriptCompiler.precompile(JavaToJavaScriptCompiler.java:255)

at com.google.gwt.dev.Precompile.precompile(Precompile.java:255)

at com.google.gwt.dev.Precompile.precompile(Precompile.java:202)

at com.google.gwt.dev.Precompile.precompile(Precompile.java:143)

at com.google.gwt.dev.Compiler.compile(Compiler.java:204)

at com.google.gwt.dev.Compiler.compile(Compiler.java:155)

at com.google.gwt.junit.JUnitShell.compileForWebMode(JUnitShell.java:1102)

at com.google.gwt.junit.JUnitShell.maybeCompileForWebMode(JUnitShell.java:1167)

at com.google.gwt.junit.CompileStrategy.maybeCompileModuleImpl2(CompileStrategy.java:183)

at com.google.gwt.junit.CompileStrategy.maybeCompileModuleImpl(CompileStrategy.java:113)

at com.google.gwt.junit.SimpleCompileStrategy.maybeCompileModule(SimpleCompileStrategy.java:36)

at com.google.gwt.junit.JUnitShell.runTestImpl(JUnitShell.java:1358)

at com.google.gwt.junit.JUnitShell.runTestImpl(JUnitShell.java:1326)

at com.google.gwt.junit.JUnitShell.runTest(JUnitShell.java:682)

at com.google.gwt.junit.client.GWTTestCase.runTest(GWTTestCase.java:421)

at junit.framework.TestCase.runBare(TestCase.java:134)

at junit.framework.TestResult$1.protect(TestResult.java:110)

at junit.framework.TestResult.runProtected(TestResult.java:128)

at junit.framework.TestResult.run(TestResult.java:113)

at junit.framework.TestCase.run(TestCase.java:124)

at com.google.gwt.junit.client.GWTTestCase.run(GWTTestCase.java:247)

[Lars]

Eclipse 4.7.3a is ready (including Java 10 support) - https://www.eclipse.org/eclipse/news/4.7.3a/

[Alexander Leshkin]

On Thursday, April 12, 2018 at 8:50:19 PM UTC+3, Lars wrote:

Eclipse 4.7.3a is ready (including Java 10 support) - https://www.eclipse.org/eclipse/news/4.7.3a/

Yes, but unfortunately I was late with https://bugs.eclipse.org/bugs/show_bug.cgi?id=533488. And this one may lead to broken user code. At least now it cause errors when launching GWT compiler tests.

So, I have to switch to 4.8M or use custom build of 4.7 with cherry-picked fix. I'm tend to the last option, since release should be more stable than milestone.

 

[Michel do Couto]

Hello guys. So, I understand there are people working on this, so we will be able to run GWT on a Java 10 runtime.

I know it is a tough question but, do we have a plan on when this would be available?

[Alexander Leshkin]

Java 10 language features support already in HEAD-SNAPSHOT and scheduled for 2.9. But there is only "local var" support. There are no new Java 9/10 JRE API emulation.

I don't know about 2.9 release plans, but you can use HEAD-SNAPSHOT or create a custom build until release. My company is used the second option.

[Ignacio Baca Moreno-Torres]

There are some other bugs recently fixed in eclipse ECJ, at this moment looks a good idea to at least wait for the ECJ 4.9 release.

https://bugs.eclipse.org/bugs/show_bug.cgi?id=477894

JRE emulation, hehe just contribute it! (:P) I recommend to create some super source in your project and try out some types you really want! it is much easier than it looks, it will work instantly in your project and when it gets mature, you can finally contribute back to GWT. Also, are you interested in any API in particular?

[Alexander Leshkin]

On Monday, July 2, 2018 at 10:30:22 AM UTC+3, Ignacio Baca Moreno-Torres wrote:

JRE emulation, hehe just contribute it! (:P) I recommend to create some super source in your project and try out some types you really want! it is much easier than it looks, it will work instantly in your project and when it gets mature, you can finally contribute back to GWT. Also, are you interested in any API in particular?

I just wanted to warn Michel do Couto, that he should not expect a new API in current state of the repository.

[stuckagain]

Thomas,

would you mind pushing a new snapshot release of your maven plugin release to sonatype ?
I see that you have migrated to a newer version of the surefire plugin on github, but this version is not yet available on sonatype. (latest update is 20170920)
I can’t build the verson myself, due to security restrictions, but we want to prepare for java 10. The NPE that you mention is stopping us from completing this migration.

I thought it would be better to ask now, before Belgium beats France on saturday :-P

[David Nouls]

I guess I am bit overworked :) ignore the last statement!

--
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 google-web-toolkit-co...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/8b159ed2-9ca5-4b30-8d57-6940badd77ef%40googlegroups.com.

[Jens]

I guess I am bit overworked :) ignore the last statement!

:D :D and now you are sad? :) 

[David Nouls]

Just a little bit, but mostly because we can’t seem to get the Java 10 working properly. 

We are having problems running the GWTTestCase using the maven plugin from Thomas.

The snapshot release in sonatype of the maven plugin looks to be quite old so it is still depending on older versions of the surefire maven plugin.

But we tried overriding it (upgrading both the surefire and common-lang3 dependencies to Java 10 compatible versions) without success.

But at the same time we also notice that the HEAD-SNAPSHOT release of GWT that we are pulling in seems to not be very recent… (old non-java-10 asm version for example). But I need to figure out if this is a local problem due to our mirrors of the maven repos or if the HEAD-SNAPSHOT is maybe not updated for some time.

On 12 Jul 2018, 22:03 +0200, Jens <jens.ne...@gmail.com>, wrote:

I guess I am bit overworked :) ignore the last statement!

:D :D and now you are sad? :) 

--

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 google-web-toolkit-co...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/526591e7-bb40-4e09-a280-31206f705d86%40googlegroups.com.

[Jens]

But I need to figure out if this is a local problem due to our mirrors of the maven repos or if the HEAD-SNAPSHOT is maybe not updated for some time.

Likely a local problem. You can see GWT builds at http://build.gwtproject.org/job/gwt/ and each successful build pushes HEAD-SNAPSHOT to Sonatype. 

-- J.

[Thomas Broyer]

On Thursday, July 12, 2018 at 4:18:38 PM UTC+2, stuckagain wrote:

Thomas,

would you mind pushing a new snapshot release of your maven plugin release to sonatype ?
I see that you have migrated to a newer version of the surefire plugin on github, but this version is not yet available on sonatype. (latest update is 20170920)
I can’t build the verson myself, due to security restrictions, but we want to prepare for java 10. The NPE that you mention is stopping us from completing this migration.

Should be OK within minutes: https://travis-ci.org/tbroyer/gwt-maven-plugin/jobs/403569831

 

I thought it would be better to ask now, before Belgium beats France on saturday :-P

I'm absolutely not a football/soccer fan (quite the contrary actually; except during Euro or World cup when France has a good team), but that match (last tuesday ;-) ) was a good watch; Belgian team was probably as deserving as Frenchies. See ya at Euro 2020? ;-)

(crossing fingers for Sunday, with Croatia still resentful after 20 years… but in the mean time, Bastille Day!)