2.8.0 RC1 is here!

[Daniel Kurka]

Hi all,

I just build the GWT 2.8.0 RC1 and pushed it to maven central. The complete SDK is also available from here.

Please start testing and let us know if you run into any trouble. You can either reply to this thread on gwt-contrib or file bugs.

We are planing to release this as GWT 2.8.0 if we do not here about any serious issues within the next two weeks. The release notes for RC1 will be made available shortly after this notice, in the mean time you can take a look at the github repository.

Daniel,

on behalf of the GWT team

[kim young ill]

nice, thanx for the great work.

the only blocking point for me now is GIN.

--
You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-tool...@googlegroups.com.
To post to this group, send email to google-we...@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

[Jens]

the only blocking point for me now is GIN.

Why its blocking? 

-- J.

[Juan Pablo Gardella]

You could replace it with dagger2.

--

[Thomas Broyer]

On Friday, July 29, 2016 at 11:23:41 AM UTC+2, kimi wrote:

nice, thanx for the great work.

the only blocking point for me now is GIN.

GIN or Java 7? Because GIN with Java 8 works (in our project I didn't even need the workaround)

No, what's blocking many of use is currently Guava (20.0-SNAPSHOT works, but depending on a snapshot…)

Daniel is in touch with the Guava team so they release 20.0 by the time we do 2.8.0 (or shortly after)

[Thomas Broyer]

On Friday, July 29, 2016 at 12:16:30 PM UTC+2, Juan Pablo Gardella wrote:

You could replace it with dagger2.

+1

Easier said than done though. For example, we have a lot of factories, and moving them to AutoFactory is not straightforward either (we have many factories able to provide many types, something AutoFactory doesn't support AFAICT)

Private modules could be an issue too.

[kim young ill]

ok, didn"t know gin work with jdk7, just saw this in the release note :https://github.com/gwtproject/gwt/issues/9311

i'm on jdk7, guava18 and gin 2.

--

[Jens]

ok, didn"t know gin work with jdk7, just saw this in the release note :https://github.com/gwtproject/gwt/issues/9311

i'm on jdk7, guava18 and gin 2.

Then Guava 18 is most likely blocking you, and you would need to use Guava 20 SNAPSHOT. Guava 18/19 use some private GWT API that does not exist anymore in GWT 2.8. This has been fixed for Guava 20.

-- J.

[Thomas Broyer]

On Friday, July 29, 2016 at 1:41:33 PM UTC+2, kimi wrote:

ok, didn"t know gin work with jdk7, just saw this in the release note :https://github.com/gwtproject/gwt/issues/9311

i'm on jdk7, guava18 and gin 2.

The thing with GIN is that it uses a custom ClassLoader to be able to "read" super-source classes, and code generated by GWT generators, and that custom classloader reads bytecode generated by the GWT Compiler, which in 2.8.0-rc1 will always generate Java 8 bytecode, so it'll fail in a Java 7 VM. This is why I said that it would be Java 7 that blocks you rather than GIN.

If you can move to Dagger 2, then IMO you should do it anyway (missing features: assisted inject –can be replaced with Google AutoFactory–, private modules, and static injection); and if you used GinModuleAdapter, you can move to Guice's DaggerAdapter.

FWIW, our project at work still compiles with JDK 7 and GIN 1.5.0; I just updated GWT to 2.8.0-rc1 and Guava to 20.0-SNAPSHOT (note: I haven't tested SuperDevMode yet, but I'm rather confident)

If I update to GIN 2.1.2 (which uses its custom classloader), than it fails with:

[INFO] Caused by: java.lang.UnsupportedClassVersionError: xxx/xxx/xxx/XxxGinjector : Unsupported major.minor version 52.0

[Frank Hossfeld]

Does using the compiler flag: 

-setProperty gin.classloading.exceptedPackages=com.google.gwt.core.client,
com.google.gwt.core.client.impl

as mentioned in the workaround solve this issue. 

[Thomas Broyer]

No, this is another issue; once you updated to Java 8, but still due to the custom classloader.

[Harald Pehl]

Running SuperDevMode using GWT 2.8.0-rc1 and the GWT Maven Plugin from Thomas (net.ltgt.gwt.maven:gwt-maven-plugin:1.0-rc-6:devmode) throws an exception. Not sure whether it's related to RC1 or the maven plugin. 

[INFO] The code server is ready at http://127.0.0.1:9876/

[WARNING] Exception in thread "main" java.lang.NoSuchMethodError: javax.servlet.ServletContext.getJspConfigDescriptor()Ljavax/servlet/descriptor/JspConfigDescriptor;

[WARNING]   at org.apache.jasper.servlet.TldScanner.scanJspConfig(TldScanner.java:148)

[WARNING]   at org.apache.jasper.servlet.TldScanner.scan(TldScanner.java:97)

[WARNING]   at org.apache.jasper.servlet.JasperInitializer.onStartup(JasperInitializer.java:103)

[WARNING]   at org.eclipse.jetty.plus.annotation.ContainerInitializer.callStartup(ContainerInitializer.java:140)

[WARNING]   at org.eclipse.jetty.annotations.ServletContainerInitializersStarter.doStart(ServletContainerInitializersStarter.java:65)

[WARNING]   at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)

[WARNING]   at org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:274)

[WARNING]   at org.eclipse.jetty.webapp.WebAppContext.startWebapp(WebAppContext.java:1349)

[WARNING]   at org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1342)

[WARNING]   at org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:741)

[WARNING]   at org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:505)

[WARNING]   at com.google.gwt.dev.shell.jetty.JettyLauncher$WebAppContextWithReload.doStart(JettyLauncher.java:552)

[WARNING]   at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)

[WARNING]   at org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:132)

[WARNING]   at org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:114)

[WARNING]   at org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:61)

[WARNING]   at org.eclipse.jetty.server.handler.RequestLogHandler.doStart(RequestLogHandler.java:140)

[WARNING]   at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)

[WARNING]   at org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:132)

[WARNING]   at org.eclipse.jetty.server.Server.start(Server.java:387)

[WARNING]   at org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:114)

[WARNING]   at org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:61)

[WARNING]   at org.eclipse.jetty.server.Server.doStart(Server.java:354)

[WARNING]   at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)

[WARNING]   at com.google.gwt.dev.shell.jetty.JettyLauncher.start(JettyLauncher.java:761)

[WARNING]   at com.google.gwt.dev.DevMode.doStartUpServer(DevMode.java:630)

[WARNING]   at com.google.gwt.dev.DevModeBase.startUp(DevModeBase.java:923)

[WARNING]   at com.google.gwt.dev.DevModeBase.run(DevModeBase.java:706)

[WARNING]   at com.google.gwt.dev.DevMode.main(DevMode.java:426)

[Thomas Broyer]

Check your dependencies, you may have Servlets API pre-3.0 (which introduced this method); either coming before Servlets API 3.1 in the classpath (they don't have the same artifactId so they could both be present), or in place of 3.1 (if javax.servlet:javax.servlet-api is somehow excluded).

[Harald Pehl]

Thanks Thomas. As always you pointed me in the right direction. I've got a dependency to com.gwtplatform::gwtp-all which depends on javax.servlet::servlet-api::2.5. Adding an <exclusion/> fixes this and SuperDevMode is running again!

[clou...@gmail.com]

FWIW, our project at work still compiles with JDK 7 and GIN 1.5.0; I just updated GWT to 2.8.0-rc1 and Guava to 20.0-SNAPSHOT (note: I haven't tested SuperDevMode yet, but I'm rather confident)

If I update to GIN 2.1.2 (which uses its custom classloader), than it fails with:

[INFO] Caused by: java.lang.UnsupportedClassVersionError: xxx/xxx/xxx/XxxGinjector : Unsupported major.minor version 52.0

My project is using JDK 1.7, GWT 2.8b1, GIN 2.1.2, and Guava 20.0-SNAPSHOT...

Changing the JDK to 1.8 is not an option for the near future.
I would like to upgrade the GWT version, but sounds like GIN is an issue... would downgrading GIN to 1.5.0 be worth it?

I was happy to see an RC1, less so after reading the notes and seems like I may have to stay on b1 (or remove GIN usage).

[P.G.Taboada]

Got my application compiled and running, just needed to update a few dependencies.

Since I am using a report generator, I have the JDT compiler on my classpath, 

solved it by adding the exact same version that got bundled in gwt-dev into my app.

Interestingly I am having troubles with server refresh (not restart) in intellij:

java.util.concurrent.RejectedExecutionException: org.eclipse.jetty.annotations.AnnotationConfiguration$1@2a5ec0a4

at org.eclipse.jetty.util.thread.QueuedThreadPool.execute(QueuedThreadPool.java:362)

at org.eclipse.jetty.annotations.AnnotationConfiguration.scanForAnnotations(AnnotationConfiguration.java:541)

at org.eclipse.jetty.annotations.AnnotationConfiguration.configure(AnnotationConfiguration.java:447)

at org.eclipse.jetty.webapp.WebAppContext.configure(WebAppContext.java:479)

at org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1337)

at org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:741)

at org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:505)

any tips/ tricks?

[Frank]

Why is javaemul.internal.ConsoleLogger removed from gwt-user.jar.

I did some stuff with supercode and creating my own java.util.logging.SimpleConsoleLogHandler to achieve logs being send over a rest service to have serverside logging with a .NET server.

In this SimpleConsoleLogHandler I make use of the javaemul.internal.ConsoleLogger.

But now the : import javaemul.internal.ConsoleLogger gives an error that this can not be found anymore.

Digging around in the source code I found out that in commit https://github.com/gwtproject/gwt/commit/e1fcefa15e96a5d7450d9f874101226a72bbeefb?diff=split#diff-db5a748e4adfed6e2e6135eac6f2c04a the build.xml was modified to specificly exclude the ConsoleLogger from gwt-user.jar


<gwt.javac excludes="**/EmulatedCharset.java,**/HashCodes.java,**/ConsoleLogger.java,**/SuperDevModeLogger.java">
Why is this the case ? And any way how I can get work my way around this ?

[Jens]

Why is this the case ?

It relies on internal API and because of this it can not be compiled using javac (ConsoleLogger calls Throwable.getBackingJsObject() which does not exist in JRE so you can not javac the file). The super sourced code is still present in com/google/gwt/emul/javaemul/internal.

 

And any way how I can get work my way around this ?

I don't know what exactly you have done but if nothing helps, copy the code and adjust it to your needs.

-- J.

[Frank]

Hi Jens,

Thanks for the quick response.

I will try to explain what I needed, and what I did...

I needed to have the following loglevels : ERROR and EXCEPTION. I asked this I think in this Google Group when I needed it but the only reply I got was that this was not possible.

In the end I found out that if I created a super-source (<super-source path="super"/>) I could override the default GWT implementation of classes.

So what I did is I copied the java.util.logging.Level class from the GWT source tree, and modified it by adding my two needed levels.

This however gave compilation errors because methods from java.util.Logger where called that are not available in the rt.jar version of java.util.Logger.
So I just copied the java.util.Logger from the GWT source tree to my own project.

I just kept doing this until everything worked. In the end I copied Logger.java, LogManager.java and SimpleConsoleLogHandler.java to my own project and everything worked without a problem.

But now when I upgrade to RC1 I get a compilation error in SimpleConsoleLogHandler.java that it can not find  javaemul.internal.ConsoleLogger. 
Now I did try to copy this class into my own project, but this then needs other files, which in their turn need again other files. Maybe if I copy the complete GWT super source code to my own project I will get it to work. But that is not really a good way to work I think, and hard to maintain.


Is there maybe a way that I just put Level.java in my own project. And do something so that it knows not to look for java.util.Logger in rt.jar, but in gwt-dev.jar or gwt-user.jar ?

Op woensdag 3 augustus 2016 16:14:42 UTC+2 schreef Jens:

[Frank]

I fixed this by removing the reference to Logger in my own Level class.

Now all seems to be working ok :-)

Op woensdag 3 augustus 2016 16:46:15 UTC+2 schreef Frank:

[dflorey]

I just installed 2.8 rc1 and try to run my project. I'm using Eclipse and try to start the SuperDevMode without any changes to my previous 2.7 config.

I'm getting:

2016-08-07 20:47:28.033:WARN:oejs.ServletHandler:qtp1910695180-49: Error for /recompile-requester/ultradoc

java.lang.NoSuchMethodError: javax.servlet.http.HttpServletResponse.getHeader(Ljava/lang/String;)Ljava/lang/String;

at org.eclipse.jetty.servlets.GzipFilter.doFilter(GzipFilter.java:322)

at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)

at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)

at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:221)

at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)

at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)

at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)

at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)

at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)

at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)

at org.eclipse.jetty.server.Server.handle(Server.java:499)

at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:311)

at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257)

at org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:544)

at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)

at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)

I did not investigate yet, just wanted to post this stacktrace in case it's helpful to improve the user experience for users coming from 2.7.

Thanks,

Daniel

Am Freitag, 29. Juli 2016 07:40:30 UTC+2 schrieb Daniel Kurka:

[Thomas Broyer]

Check your classpath, you must be downgrading the servlet API to a 2.x version: http://docs.oracle.com/javaee/7/api/javax/servlet/http/HttpServletResponse.html#getHeader-java.lang.String-