[gwt-contrib] Github issue tracker label cleanup

2016-02-18 Thread Jens 
I noticed that the Github issue tracker has a large number of labels and 
IMHO most of them are not used anymore. If time permits I thought about 
cleaning labels up so its more streamlined:

- Convert Milestone labels to Github Milestones
- Adjust category labels to 
match 
https://docs.google.com/document/d/1vyncxfuujIJ3L-PBLNM68tfeXRFZ4qDdnWEodblmvRg/edit
- Delete very old unused labels (reviewBy-* and such)
- Merge GPE labels into a single one
- see whats left and if it can be streamlined

In addition Github now supports Issue and Pull request templates. As pull 
request template we could use a notice pointing to Gerrit instructions. 
Issue template needs to be discussed but I could create a general purpose 
one to begin with (similar to the old google code one).

Everyone fine with it? Just asking here because I have no idea if anyone is 
in charge of the issue tracker.

-- J.

-- 
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-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/5986fd18-5a98-4ca4-bbb6-25dbb7775a6f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: Compiler failing with java 7

2016-02-18 Thread 'Goktug Gokdogan' via GWT Contributors 
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.

On Thu, Feb 18, 2016 at 9:51 AM, Thomas Broyer  wrote:

>
>
> 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.
>
> --
> 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-contributors+unsubscr...@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
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAN%3DyUA3P043Po3XpfD-FikDc8tMZjH0Xx0_QA5SzfxBSTC-YKg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: Compiler failing with java 7

2016-02-18 Thread 'Goktug Gokdogan' via GWT Contributors 
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.

On Wed, Feb 17, 2016 at 11:57 PM, Manuel Carrasco Moñino 
wrote:

> 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.
>
>
>
> On Wed, Feb 17, 2016 at 9:13 PM, 'Goktug Gokdogan' via GWT Contributors <
> google-web-toolkit-contributors@googlegroups.com> 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.
>>
>> On Tue, Feb 16, 2016 at 11:35 PM, Manuel Carrasco Moñino <
>> man...@apache.org> wrote:
>>
>>> 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.
>>>
>>>
>>> On Wed, Feb 17, 2016 at 2:32 AM, 'Goktug Gokdogan' via GWT Contributors
>>>  wrote:
>>>
 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.)

 On Mon, Feb 15, 2016 at 5:12 AM, Thomas Broyer 
 wrote:

>
>
> 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/
>
> --
> 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-contributors+unsubscr...@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
> 
>

Re: [gwt-contrib] Re: Compiler failing with java 7

2016-02-18 Thread 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.

-- 
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-contributors+unsubscr...@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.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: Compiler failing with java 7

2016-02-18 Thread 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.

-- 
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-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/7d940cf7-d743-4845-9e82-70567c52eb27%40googlegroups.com.
For more options, visit

Re: [gwt-contrib] Re: Compiler failing with java 7

2016-02-18 Thread 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.

-- 
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-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/9e6107b4-143b-4f22-839b-f745dc8867c3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: Compiler failing with java 7

2016-02-18 Thread Thomas Broyer 
Isn't GIN unmaintained anyway?
(and what we're all waiting for is proper GWT support in Dagger 2 ;-) )

On Thursday, February 18, 2016 at 1:20:34 PM UTC+1, Jens wrote:
>
> 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.
>
>
>

-- 
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-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/google-web-toolkit-contributors/2ede1376-6d7b-47c8-b4db-8df55c1ef646%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [gwt-contrib] Re: Compiler failing with java 7

2016-02-18 Thread 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.

On Thu, Feb 18, 2016 at 10:17 AM, 'Daniel Kurka' via GWT Contributors <
google-web-toolkit-contributors@googlegroups.com> wrote:

> 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.
>
> On Thu, Feb 18, 2016 at 8:57 AM Manuel Carrasco Moñino 
> wrote:
>
>> 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.
>>
>>
>>
>> On Wed, Feb 17, 2016 at 9:13 PM, 'Goktug Gokdogan' via GWT Contributors <
>> google-web-toolkit-contributors@googlegroups.com> 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.
>>>
>>> On Tue, Feb 16, 2016 at 11:35 PM, Manuel Carrasco Moñino <
>>> man...@apache.org> wrote:
>>>
 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.


 On Wed, Feb 17, 2016 at 2:32 AM, 'Goktug Gokdogan' via GWT Contributors
  wrote:

> 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.)
>
> On Mon, Feb 15, 2016 at 5:12 AM, Thomas Broyer 
> wrote:
>
>>
>>
>> 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/
>>

Re: [gwt-contrib] Re: Compiler failing with java 7

2016-02-18 Thread 'Daniel Kurka' via GWT Contributors 
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.

On Thu, Feb 18, 2016 at 8:57 AM Manuel Carrasco Moñino 
wrote:

> 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.
>
>
>
> On Wed, Feb 17, 2016 at 9:13 PM, 'Goktug Gokdogan' via GWT Contributors <
> google-web-toolkit-contributors@googlegroups.com> 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.
>>
>> On Tue, Feb 16, 2016 at 11:35 PM, Manuel Carrasco Moñino <
>> man...@apache.org> wrote:
>>
>>> 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.
>>>
>>>
>>> On Wed, Feb 17, 2016 at 2:32 AM, 'Goktug Gokdogan' via GWT Contributors
>>>  wrote:
>>>
 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.)

 On Mon, Feb 15, 2016 at 5:12 AM, Thomas Broyer 
 wrote:

>
>
> 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/
>
> --
> 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-contributors+unsubscr...@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
>