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 <[email protected]> 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 <[email protected]> >> 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. >>> >>> On Fri, Feb 12, 2016 at 5:28 PM 'Daniel Kurka' via gwt-maintainers < >>> [email protected]> 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 < >>>> [email protected]> 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 <[email protected]>: >>>>> > +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 < >>>>> [email protected]> >>>>> > 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 >>>>> >> <[email protected]> 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 >>>>> >>> <[email protected]> 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 >>>>> >>>> <[email protected]> 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 >>>>> >>>>> <[email protected]> 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 >>>>> >>>>>> <[email protected]> wrote: >>>>> >>>>>>> >>>>> >>>>>>> This is expected since java8 emulation patches have gone in. >>>>> >>>>>>> >>>>> >>>>>>> On Fri, Feb 12, 2016 at 3:11 PM Manuel Carrasco Moñino >>>>> >>>>>>> <[email protected]> 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 Contributors" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/google-web-toolkit-contributors/cd06c777-9644-43e4-95a4-59b7510ae81d%40googlegroups.com > <https://groups.google.com/d/msgid/google-web-toolkit-contributors/cd06c777-9644-43e4-95a4-59b7510ae81d%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAM28XAu%3D6o%2ByjW5p_kQU-kdtoVE0AZuaMW1wPMj%3D24r_kSeMxw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
