Re: Compiler failing with java 7

[Colin Alworth]

Switching to gwt-contrib, we're losing voices who are involved in this discussion. 

Maybe I am missing something, but I had that that the discussion moved toward the fact that the compiler and dev mode will require Java8, but that gwt-servlet could still be compiled to Java7, allowing deployment on Java7. 

The supersource classes do require Java8 language level in the GWT compiler (in order to have "default" mean anything), but these emulation classes are not compiled to bytecode, and not required to compile the rest of GWT. 

We already have cases where GWT will not work without Java8 (specifically Dev Mode and anything that leans on it), so this isn't a change from the beta. I agree with Daniel that effort will be required to compile to Java7 bytecode (as previously discussed), and while I would be interested in helping to achieve this, we've also clearly stated that Java8 support is a more important goal (both in terms of keeping GWT modern and up to date in the Java world, but also in terms of staying relevant for web development with lambdas and JSInterop).

Even if we manage to compile to Java7 bytecode from a Java8 JDK, it has been encouraged that we extensively test to ensure that all of the code does as we expect, as regressions have been seen in the past. RetroLambda was another suggestion that also may have merit.

On Fri, Feb 12, 2016 at 10:28 AM Daniel Kurka <dank...@google.com> wrote:

GWT 2.8 needs to contain Java8 APIs so taht guava will start working again. All the outstanding Java8 patches need to go in before 2.8. So 2.8 will not work with Java7.

On Fri, Feb 12, 2016 at 5:25 PM Jens Nehlmeier <jens.ne...@gmail.com> wrote:

Its not just about adding new classes but we also add APIs to existing
classes that require Java8 classes in their signature. So you would
need to ignore these changes on method level.

AFAICT it was said that as soon as Java 8 APIs are committed GWT will
require Java8. If someone needs Java7 support they need to replace the
emulation code of GWT 2.8 with the one of GWT 2.7. Because of this
possibility we don't use Java8 APIs in gwt-user code. gwt-servlet.jar
is something to think about as soon as we want to add GWT-RPC
serializer for Java 8 classes. If we really want to give users the
possibility to compile GWT 2.8 with Java 7 after replacing the
emulation code we probably need a build target that builds
gwt-servlet-jdk8.jar when running Java8 only.

Generally I thought Java8 stuff will be committed after GWT 2.8 has
been released so that GWT 2.8 stays Java7 compatible. I don't know
about the Guava issue that requires GWT 2.8 to already have Java8 APIs
available. I thought Guava will just release Guava 20 when 2.8 is
released because Gauva 19 did use some private APIs of GWT that do not
exist anymore.



2016-02-12 16:06 GMT+01:00 Daniel Kurka <dank...@google.com>:
> +Colin Alworth  +Jens
>
> Colin and Jens have been doing a lot of the Java8 API work, I believe this
> will touch many classes within the JRE and thus will not be as easy as
> ignoring a few classes.
>
> To be clear:
> We won't be putting any resources into addressing this since its not an
> issue for us, if someone feels strongly (s)he can step up and tackle this,
> but the whole case does not seem to be convincing for me, why would agencies
> that are slow to adopt things adopt the latest GWT version?
>
> -Daniel
>
> On Fri, Feb 12, 2016 at 3:52 PM Manuel Carrasco Moñino <man...@apache.org>
> wrote:
>>
>> Well the situation I know, is that there are many big companies and
>> government agencies moving very slow, their standard server configuration is
>> java7, as well as their code standards.
>>
>> Their GWT projects are compiled in one phase (not client and server
>> sides). It could be very difficult for them to compile their byte code for
>> 1.7.
>> It's true that if they don't use java 8 many features in 2.8 are useless
>> for them, but we have to facilitate and encourage users to be in latest
>> version.
>>
>> I don't know how complex it could be, but if for example, ignoring java8
>> /emul/ classes could fix the problem I think it's worth to consider.
>>
>> On Fri, Feb 12, 2016 at 3:42 PM, 'Daniel Kurka' via gwt-maintainers
>> <gwt-mai...@googlegroups.com> wrote:
>>>
>>> I am not sure how this is connected to the beta1 release. Beta1 did not
>>> have any Java8 apis for the final release we need them to support the next
>>> version of guava.
>>>
>>> If you feel strongly you can always step in with a design that will
>>> support both modes and execute on it, but we went over this in the SC and
>>> this seems like a lot of work for something that almost all devs are fine
>>> with (run java8 while developing).
>>>
>>>
>>> On Fri, Feb 12, 2016 at 3:36 PM Manuel Carrasco Moñino
>>> <man...@apache.org> wrote:
>>>>
>>>> Since beta1 supports 1.7, isn't feasible someway to make the compiler
>>>> ignore java8 specific stuff when compiler level is set to java 7?
>>>>
>>>> On Fri, Feb 12, 2016 at 3:29 PM, 'Daniel Kurka' via gwt-maintainers
>>>> <gwt-mai...@googlegroups.com> wrote:
>>>>>
>>>>> Compiling GWT code will require Java 8, if someone is willing to put in
>>>>> the work we can potentially make GWT servlet run in java7
>>>>>
>>>>>
>>>>> On Fri, Feb 12, 2016, 3:18 PM Manuel Carrasco Moñino
>>>>> <man...@apache.org> wrote:
>>>>>>
>>>>>> Is it planed to be fixed? or do we break 1.7 compatibility ?
>>>>>>
>>>>>> On Fri, Feb 12, 2016 at 3:16 PM, 'Daniel Kurka' via gwt-maintainers
>>>>>> <gwt-mai...@googlegroups.com> wrote:
>>>>>>>
>>>>>>> This is expected since java8 emulation patches have gone in.
>>>>>>>
>>>>>>> On Fri, Feb 12, 2016 at 3:11 PM Manuel Carrasco Moñino
>>>>>>> <man...@apache.org> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Current master seems not supporting correctly compilation in java ,
>>>>>>>> take a look to CI output when compiling dynatablerf which is configured to
>>>>>>>> be compiled in 1.7 mode
>>>>>>>>
>>>>>>>> http://build.gwtproject.org/job/gwt-samples/15/console
>>>>>>>>
>>>>>>>> --
>>>>>>>> You received this message because you are subscribed to the Google
>>>>>>>> Groups "gwt-maintainers" group.
>>>>>>>> To unsubscribe from this group and stop receiving emails from it,
>>>>>>>> send an email to gwt-maintaine...@googlegroups.com.
>>>>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>>>
>>>>>>> --
>>>>>>> You received this message because you are subscribed to the Google
>>>>>>> Groups "gwt-maintainers" group.
>>>>>>> To unsubscribe from this group and stop receiving emails from it,
>>>>>>> send an email to gwt-maintaine...@googlegroups.com.
>>>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>>
>>>>>>
>>>>> --
>>>>> You received this message because you are subscribed to the Google
>>>>> Groups "gwt-maintainers" group.
>>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>>> an email to gwt-maintaine...@googlegroups.com.
>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups
>>> "gwt-maintainers" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an
>>> email to gwt-maintaine...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>



--
Mit freundlichen Grüssen

Jens Nehlmeier

[Brandon Donnelson]

I would choose Java 1.8 all the way if you have to choose. I would do this because this is going to be a long standing maintenance release. Just a note, the Eclipse neon out in June will require Java 1.8. I think it makes sense to upgrade. I think folks can go through the pain of upgrading there servlet containers to Java 1.8 if they want to move forward. 

[Manuel Carrasco Moñino]

Hi all, in the behave of gwt-maintainers, I'm forwarding this discussion started in the maintainer list to the contributors one. Feel free to contribute with your opinions.

Basically the matter is about the convenience of not breaking java7 compatibility in 2.8

Thanks

 -Manolo

On Fri, Feb 12, 2016 at 6:14 PM, Thomas Broyer <t.br...@gmail.com> wrote:

FWIW, I just tried the latest snapshot (from today) with Java 7 and it seems to work (for now; see below).

I think the issue in the samples is with -sourceLevel: the POMs there set maven.compiler.source to 1.7, which automatically passes -sourceLevel 1.7 to GWT, which then fails to parse the emul.

I think that:

 * now that we no longer run tests in "dev mode", it shouldn't be a problem using -sourceLevel 8 with a JDK 7 (it's a problem in dev mode as dev mode will compile sources to classes –using JDT so with the -sourceLevel compat– and then won't be able to read them back in a JDK 7; IIRC)

 * we should then be able to *build* GWT with a JDK 7, and ensure compatibility of gwt-servlet with Java 7 runtimes.

 * we could make GWT ignore "-sourceLevel 7" (automatically upgrading to "8", or simply removing -sourceLevel processing entirely and hard-coding the value as in older versions of GWT)

This only holds as long as we don't use Java 8 language features and APIs in GWT proper (and non-GWT tests), but maybe we could set it as a goal for 2.8?

Note: I said above that it works "for now", because if we build with JDK 8, we can never be sure that it'll run with a JDK 7, unless we correctly cross-compile, by passing the bootclasspath to a JDK 7 too (which is equivalent to use a JDK 7, except you're using a different version of JavaC that has a different set of bugs ;-) ) Hence my suggestion above to *build* the final SDK with a JDK 7.

Let's continue that discussion publicly on gwt-contrib though.

[Thomas Broyer]

Just to make it clearer, my suggestion is:

 * force sourceLevel to 8 (either make the argument a no-op –using 8 even if arg says 7–, or fail on "-sourceLevel 7")

 * build GWT with JDK 7; particularly the release artifacts (snapshots matter less). Note that this means changing the CI builds to run tests in prod mode rather than dev mode, this is probably a good idea anyway given we recently changed GWTTestCase to use prod mode by default.

We can revise those rules after 2.8.

On Saturday, February 13, 2016 at 6:06:24 PM UTC+1, Manuel Carrasco Moñino wrote:

Hi all, in the behave of gwt-maintainers, I'm forwarding this discussion started in the maintainer list to the contributors one. Feel free to contribute with your opinions.

Basically the matter is about the convenience of not breaking java7 compatibility in 2.8

Thanks

 -Manolo

On Fri, Feb 12, 2016 at 6:14 PM, Thomas Broyer <t.br...@gmail.com> wrote:

FWIW, I just tried the latest snapshot (from today) with Java 7 and it seems to work (for now; see below).

I think the issue in the samples is with -sourceLevel: the POMs there set maven.compiler.source to 1.7, which automatically passes -sourceLevel 1.7 to GWT, which then fails to parse the emul.

I think that:

 * now that we no longer run tests in "dev mode", it shouldn't be a problem using -sourceLevel 8 with a JDK 7 (it's a problem in dev mode as dev mode will compile sources to classes –using JDT so with the -sourceLevel compat– and then won't be able to read them back in a JDK 7; IIRC)

 * we should then be able to *build* GWT with a JDK 7, and ensure compatibility of gwt-servlet with Java 7 runtimes.

 * we could make GWT ignore "-sourceLevel 7" (automatically upgrading to "8", or simply removing -sourceLevel processing entirely and hard-coding the value as in older versions of GWT)

This only holds as long as we don't use Java 8 language features and APIs in GWT proper (and non-GWT tests), but maybe we could set it as a goal for 2.8?

Note: I said above that it works "for now", because if we build with JDK 8, we can never be sure that it'll run with a JDK 7, unless we correctly cross-compile, by passing the bootclasspath to a JDK 7 too (which is equivalent to use a JDK 7, except you're using a different version of JavaC that has a different set of bugs ;-) ) Hence my suggestion above to *build* the final SDK with a JDK 7.

Let's continue that discussion publicly on gwt-contrib though.

[Manuel Carrasco Moñino]

Thomas, I want to experiment with this, pls, could you give me some advise what are the classes I have to look at?

On Sun, Feb 14, 2016 at 12:00 PM, Thomas Broyer <t.br...@gmail.com> wrote:

Just to make it clearer, my suggestion is:

 * force sourceLevel to 8 (either make the argument a no-op –using 8 even if arg says 7–, or fail on "-sourceLevel 7")

 * build GWT with JDK 7; particularly the release artifacts (snapshots matter less). Note that this means changing the CI builds to run tests in prod mode rather than dev mode, this is probably a good idea anyway given we recently changed GWTTestCase to use prod mode by default.

We can revise those rules after 2.8.

On Saturday, February 13, 2016 at 6:06:24 PM UTC+1, Manuel Carrasco Moñino wrote:

Hi all, in the behave of gwt-maintainers, I'm forwarding this discussion started in the maintainer list to the contributors one. Feel free to contribute with your opinions.

Basically the matter is about the convenience of not breaking java7 compatibility in 2.8

Thanks

 -Manolo

On Fri, Feb 12, 2016 at 6:14 PM, Thomas Broyer <t.br...@gmail.com> wrote:

FWIW, I just tried the latest snapshot (from today) with Java 7 and it seems to work (for now; see below).

I think the issue in the samples is with -sourceLevel: the POMs there set maven.compiler.source to 1.7, which automatically passes -sourceLevel 1.7 to GWT, which then fails to parse the emul.

I think that:

 * now that we no longer run tests in "dev mode", it shouldn't be a problem using -sourceLevel 8 with a JDK 7 (it's a problem in dev mode as dev mode will compile sources to classes –using JDT so with the -sourceLevel compat– and then won't be able to read them back in a JDK 7; IIRC)

 * we should then be able to *build* GWT with a JDK 7, and ensure compatibility of gwt-servlet with Java 7 runtimes.

 * we could make GWT ignore "-sourceLevel 7" (automatically upgrading to "8", or simply removing -sourceLevel processing entirely and hard-coding the value as in older versions of GWT)

This only holds as long as we don't use Java 8 language features and APIs in GWT proper (and non-GWT tests), but maybe we could set it as a goal for 2.8?

Note: I said above that it works "for now", because if we build with JDK 8, we can never be sure that it'll run with a JDK 7, unless we correctly cross-compile, by passing the bootclasspath to a JDK 7 too (which is equivalent to use a JDK 7, except you're using a different version of JavaC that has a different set of bugs ;-) ) Hence my suggestion above to *build* the final SDK with a JDK 7.

Let's continue that discussion publicly on gwt-contrib though.

--
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/cd06c777-9644-43e4-95a4-59b7510ae81d%40googlegroups.com.

[Thomas Broyer]

On Monday, February 15, 2016 at 10:06:47 AM UTC+1, Manuel Carrasco Moñino wrote:

Thomas, I want to experiment with this, pls, could you give me some advise what are the classes I have to look at?

https://gwt-review.googlesource.com/14353

(currently running the testsuite locally)

 

To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscribe@googlegroups.com.

[Thomas Broyer]

On Monday, February 15, 2016 at 11:39:02 AM UTC+1, Thomas Broyer wrote:

On Monday, February 15, 2016 at 10:06:47 AM UTC+1, Manuel Carrasco Moñino wrote:

Thomas, I want to experiment with this, pls, could you give me some advise what are the classes I have to look at?

https://gwt-review.googlesource.com/14353

(currently running the testsuite locally)

Tests pass \o/

[Goktug Gokdogan]

To remind the backlog of this:

GWT 2.8 decided to support only Java8 source level (see related threads from last year) as the emulation will include Java 8 APIs which cannot be compiled in Java7 mode.

However, GWT compiler itself is intended to be runnable in a Java 7 JVM. This should enable slow-to-upgrade enterprises business to keep their legacy dev environments.

For any reason, if community wants to run the GWT 2.8 SDK in Java 7 source level, they can theoretically do it by supplying a java7 compatible JRE emulation without any compiler/SDK changes. That's why I didn't originally remove Java7 option from the SourceLevel flag.

By removing the flag (which seems submitted now), the community will not have that option.

(It is not import from Google side; just wanted to let you know if the community cares about it.)

--

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/a96d8bde-37f5-4bdd-92f2-7fda3492cc94%40googlegroups.com.

[Manuel Carrasco Moñino]

Removing the 1.7 flag does not make the compiler fail when using a java7 sdk.

Now the compiler always thinks that source code is sourced-level 1.8 so it does not fail when looking at java8 emul classes.

You can still have the java.source property set to 1.7 when compiling your project and javac will validate that your code is java7 compliant, because javac process your client code.

 

In summary javac and gwtc could use at the same time different source languages, but we always need to force gwtc to use 1.8 since new java8 api emul code.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAN%3DyUA2BRAZ1%2Bu33NNK%2BgqNdijZs7a0V7YY4fasWCes2iGJ%2Bvg%40mail.gmail.com.

[Goktug Gokdogan]

I think you didn't understand what I said. Let me try to clarify:

"For any reason, if community wants to run the GWT 2.8 SDK in Java 7 source level (i.e. gwtc sourcelevel 7), they can theoretically do it by supplying a java7 compatible JRE emulation without any compiler/SDK changes (but just setting the gwtc sourcelevel 7). That's why I didn't originally remove Java7 option from the SourceLevel flag.

By removing the flag (which seems submitted now), the community will not have that option (i.e. they need also supply a modified compiler together with the emulation)."

This may never happen but keeping the flag was cheap so I kept it.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAM28XAsQGwM4MRA-aBxoze-1MQ_fzeCQp4Jxw1Hc2o0FiOtmHA%40mail.gmail.com.

[Manuel Carrasco Moñino]

I follow, but I have a couple of thoughts

- Is it actually useful from the user perspective to use a sourceLevel=1.7 if he has to manually provide a compatible gwt-jre-emulation?

IMO, he might want that everything works out-of-the-boxy. Right now, gwt emul classes in the 2.8-snapshot make fail sourceLevel=1.7 though, so I don't see any reason to deliver gwt-2.8.0 with a non working flag.

- IMHO, for real users having to code in 1.7, it's not a problem to set javac.source=1.7 and have gwtc.sourceLevel=default=1.8. In this case the javac compiler will validate his source code and gwtc compiler does not need to do the validation, it simply works without raising any error when processing its internal jre-emul classes.

So, since gwtc can be run with a sdk7 (even with gwt java8 sources), there should not be any problem compiling gwt projects written in java7 and compiled with sdk7, and the user does not bother about the sourceLevel flag.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAN%3DyUA2LYKb1U_1eTH0whd%3DUjXgaudG1NBqugy54eEq8Rw7eoA%40mail.gmail.com.

[Daniel Kurka]

We have seen issues internally where some code would be a compile error in Java8 but not in Java7 (especially around type checking). This setup will leave users vulnerable to this since their code will compile in their IDE, but will fail GWT compile.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAM28XAvkc6jJFK2-Kooc%3DvuNB_z0dyFE4u4qRsSVJZr1c2uSZw%40mail.gmail.com.

[Manuel Carrasco Moñino]

Agree, there are some corner cases, but normally gwt developers have to deal with a bunch of differences between java and gwt.

Anyway I think that it's better that SDK7 users assume some language issues than not be able to compile their projects at all.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CALLujiquSAbDD3x35B21JYfK5EWJuNr2YSW8evHZvbGhsQ87Sw%40mail.gmail.com.

[Jens]

Seems like GWT apps that use GIN will still require Java 8. I just tried latest master from today using Guava 20-SNAPSHOT, Gin 2.1.2, Guice 4.

When we compile our app using JDK 1.7 and -sourceLevel 1.8 for GWT compiler we get warnings for all java.util.function.* emulated classes that reference java.lang.FunctionalInterface, e.g.

Resolving java.util.Objects

            Found type 'java.util.Objects'

               Resolving method requireNonNull

                  Found type 'java.util.function.Supplier'

                     [WARN] Ignoring unresolvable annotation type java.lang.FunctionalInterface

         Resolving java.util.Optional

            Found type 'java.util.Optional'

               Resolving method ifPresent

                  Found type 'java.util.function.Consumer'

                     [WARN] Ignoring unresolvable annotation type java.lang.FunctionalInterface

               Resolving method filter

Thats not really nice for a potential final release of GWT.

But the real issue is GIN as it fails with unsupported major.minor version 52.0:

Caused by: java.lang.UnsupportedClassVersionError: xx/xx/xx/xx/SomeGinjector : Unsupported major.minor version 52.0

at java.lang.ClassLoader.defineClass1(Native Method)

at java.lang.ClassLoader.defineClass(ClassLoader.java:800)

at java.lang.ClassLoader.defineClass(ClassLoader.java:643)

at com.google.gwt.inject.rebind.GinBridgeClassLoader.findClass(GinBridgeClassLoader.java:160)

at com.google.gwt.inject.rebind.GinBridgeClassLoader.loadClass(GinBridgeClassLoader.java:106)

at java.lang.ClassLoader.loadClass(ClassLoader.java:358)

at java.lang.Class.forName0(Native Method)

at java.lang.Class.forName(Class.java:278)

at com.google.gwt.inject.rebind.GinjectorGenerator.loadClass(GinjectorGenerator.java:223)

at com.google.gwt.inject.rebind.GinjectorGenerator.getGinjectorType(GinjectorGenerator.java:104)

at com.google.gwt.inject.rebind.GinjectorGenerator.generate(GinjectorGenerator.java:60)

at com.google.gwt.core.ext.IncrementalGenerator.generateNonIncrementally(IncrementalGenerator.java:40)

at com.google.gwt.dev.javac.StandardGeneratorContext.runGeneratorIncrementally(StandardGeneratorContext.java:745)

at com.google.gwt.dev.cfg.RuleGenerateWith.realize(RuleGenerateWith.java:103)

at com.google.gwt.dev.shell.StandardRebindOracle$Rebinder.rebind(StandardRebindOracle.java:78)

at com.google.gwt.dev.shell.StandardRebindOracle.rebind(StandardRebindOracle.java:262)

at com.google.gwt.dev.shell.StandardRebindOracle.rebind(StandardRebindOracle.java:251)

at com.google.gwt.dev.PrecompilationContextCreator$1.getAllPossibleRebindAnswers(PrecompilationContextCreator.java:86)

Looks like GIN, executed with JDK 7, loads a class generated by JDT in Java8 mode. Not sure if that can be fixed in GIN. For now we will use master branch without the first Java 8 commits.

So I guess if we want GWT 2.8 to be fully JDK 7 compatible we have to revert Java 8 commits and reintroduce -sourceLevel 1.7. However that would mean we would need to release GWT 2.9 with Java 8 only support in a couple of month at the time Guava 21 will be released (mid 2016, requires Java 8). So I am not sure if its worth it to buy people a couple of extra month of 1.7 support.

Alternatively we could also make two releases 2.7.1 and 2.8 with 2.7.1 containing everything of 2.8 up until the first Java 8 commit. Then 2.7.1 will be Java 7 compatible and has lots of bug fixes while 2.8 is Java 8 only and contains only a couple more commits.

-- J.

[Thomas Broyer]

Isn't GIN unmaintained anyway?

(and what we're all waiting for is proper GWT support in Dagger 2 ;-) )

[Jens]

Isn't GIN unmaintained anyway?

(and what we're all waiting for is proper GWT support in Dagger 2 ;-) )

 

I don't know. GIN works well and a ton of apps use it. A lot of these apps will probably not migrate to Dagger 2 anytime soon (especially not if it takes ages for a PR to be accepted).

Anyways any generator that tries to load JDT generated classes while being executed with Java 7 will fail. I wouldn't bet that GIN is the only library affected. I just wanted to note that the current situation is not "GWT 2.8 is fully compatible to Java 7", its more like "GWT 2.8 might work with Java 7 depending on the library you use" which is kind of a bad statement.

-- J.

[Thomas Broyer]

On Wednesday, February 17, 2016 at 9:13:43 PM UTC+1, Goktug Gokdogan wrote:

I think you didn't understand what I said. Let me try to clarify:

"For any reason, if community wants to run the GWT 2.8 SDK in Java 7 source level (i.e. gwtc sourcelevel 7), they can theoretically do it by supplying a java7 compatible JRE emulation without any compiler/SDK changes (but just setting the gwtc sourcelevel 7). That's why I didn't originally remove Java7 option from the SourceLevel flag.

By removing the flag (which seems submitted now), the community will not have that option (i.e. they need also supply a modified compiler together with the emulation)."

This may never happen but keeping the flag was cheap so I kept it.

Thanks for the reminder Goktug.

We had a quick discussion with Manolo about whether we should remove the -sourceLevel entirely, remove the 1.7 value only (only keeping 1.8), or "aliasing" 1.7 to 1.8 (with a warning).

The immediate goal was to make it possible to build GWT with a JDK 7. Things can still change back.

Let's see what we had and we could have (incl. what we have now):

The problem we were having is that -sourceLevel defaulted to the level of the Java version being used to run GWTC, and defaulting to 7 as a last resort, which means that with a Java 7 (or 6) VM you'd have to pass "-sourceLevel 8" to make it work with the new Java 8-only emul.

We have (had) several options:

• leave it like that, forcing every Java 7 user to explicitly pass "-sourceLevel 8". They'd see it as a breaking change (which it could be, according to Daniel in this thread) and wouldn't understand why there's a "7" value that doesn't work. As a user, I'd probably see it as a bug.
• change the default value to Java 8 (independently of the current JVM). This is backwards-compatible with people passing "-sourceLevel 8", breaking those passing "-sourceLevel 7" with cryptic errors due to GWT being incapable of compiling the Java 8-only emul, and "transparently upgrades" others to sourceLevel 8.
• remove the "7" value, only leaving "8" as a valid value. Given that the default value depends on the current JVM and always has a valid fallback, that means GWT always uses Java 8, but starts to fail if you pass a sourceLevel with a value different from 8 or 1.8. This is backwards-compatible with people passing "-sourceLevel 8", breaking those passing "-sourceLevel 7" with an explicit error that this value is not supported, and "transparently upgrades" others to sourceLevel 8. This is what we did.
• remove the -sourceLevel flag entirely; this would break many, many people; including those passing a "compatible" sourceLevel value.
• alias the "-sourceLevel 7" to "-sourceLevel 8". In many cases this wouldn't break builds, except for those cases where people run into differences between Java 7 and Java 8, as Daniel mentioned. Those people possibly won't understand why their explicit "-sourceLevel 7" isn't honored (even if we issue a warning).
• deprecate -sourceLevel and make it a no-op. This "transparently upgrades" everyone to Java 8, and is similar to the above case where "-sourceLevel 7" is aliased to "-sourceLevel 8"

I think we chose the "least bad" of those options, by being explicit. People using Java 7 *and* using an explicit sourceLevel should be aware that JavaC and GWTC would use different rules, so let's force them to be extra-explicit.

Note that whether you pass -sourceLevel or not, and with which value depends on how you call GWTC:

In Maven, you have to configure your project with an explicit source level version (even for JavaC) unless you're OK with Java 1.4 or 1.5 (depending on the version of the maven-compiler-plugin, whose default version depends on the version of Maven you're using), and depending on how you configure it, it could instruct the gwt-maven-plugin (both flavors) to pass an explicit -sourceLevel to GWTC. This would break people using Java 7. In other words, it's quite likely that many projects (but far from all) have a configured (possibly implicitly) sourceLevel matching their JavaC source level.

Gradle (gwt-gradle-plugin) only passes a sourceLevel if configured explicitly (through a specific property), independently of the source level configured for JavaC.

Others (Ant, Buck, etc.) probably have to pass arguments explicitly.

I have no idea what IDEs (Eclipse, IntelliJ) do.

[Thomas Broyer]

On Thursday, February 18, 2016 at 6:29:22 PM UTC+1, Jens wrote:

Isn't GIN unmaintained anyway?

(and what we're all waiting for is proper GWT support in Dagger 2 ;-) )

 

I don't know. GIN works well and a ton of apps use it.

Well, at least it's not actively developed: with the last version released nearly 2.5 years ago, the last commit exactly two years ago tomorrow (on the Ant build, so without the need to re-release), and more importantly with the repository being archived on Google Code Hosting and not migrated to GitHub.

That sounds like "unmaintained" to me.

 

A lot of these apps will probably not migrate to Dagger 2 anytime soon (especially not if it takes ages for a PR to be accepted).

So they probably won't migrate to GWT 2.8 either.

 

Anyways any generator that tries to load JDT generated classes while being executed with Java 7 will fail.

Just like when "-sourceLevel 7"  was added a few years back; except that at the time it would break DevMode also (it still does, the difference being that nobody will use it anymore).

 

I wouldn't bet that GIN is the only library affected. I just wanted to note that the current situation is not "GWT 2.8 is fully compatible to Java 7", its more like "GWT 2.8 might work with Java 7 depending on the library you use" which is kind of a bad statement.

What GIN does with the classloader is clearly a hack, people using hacks shouldn't complain when the hacks stop working (remember CSS hacks?)

YMMV.

[Goktug Gokdogan]

That's fair. I wasn't expecting much need either but just wanted a simpler way out if it ended up being important for the community. 

To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAM28XAvkc6jJFK2-Kooc%3DvuNB_z0dyFE4u4qRsSVJZr1c2uSZw%40mail.gmail.com.

[Goktug Gokdogan]

It is true that GIN is kind of unmaintained. There has been some internal patches but nobody bothered moving the project out of Google code and export those due to initial overhead.

Bu regardless, right now GIN uses reflection with a ClassLoader hack to access types. And at least some code visible by GIN will be compiled by JDT (e.g. super-source code, classes generated by other generators etc.) so it will see java8 byte code (hence the error). I don't see a practical way to make GIN work in a JDK 7 environment.

If there are other similar generators, they will not work in JDK7 as well but I don't believe there are many like that.

--
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/eb227511-e93a-434d-9d1f-08784d75f4a9%40googlegroups.com.