This seems like a very basic question, but I searched high and low and have found almost no mention of it anywhere. So, I'll ask it here here.
What is the current plan for supporting Java 8's new language constructs in GWT?
In addition, what subset of the proposed Java 8 libraries are slated for client-side emulation? The Stream API? The new Date/Time API?
And finally, where are the discussions relating this important topic taking place? I'm sure there are many of us who would like to participate in, and potentially contribute to, the effort.
The Java 8 betas have been around for a while now, and there are numerous articles discussing the proposed APIs. It is supposed to be related later this year, so it seems past time to at least be discussing how and when the much-desired language features will make their way into GWT.
My apologies if this question is answered somewhere else, or if I missed some important piece of information related to it. This would be a great place to have a link to such information, even if it has been answered. Thanks!
EDIT GWT 2.8.0 was released on Oct 20, 2016 with support for Java 8 language constructs (lambdas, method references) and emulation of some Java 8 APIs (streams mostly)
EDIT as of Apr 2014, GWT 2.6 supports Java 7, and work is underway to support Java 8 in GWT 2.7, to be released by the summer 2014. GWT 2.7 is likely to only support Java 8 language constructs though, and not emulate any new API (streams, javax.time, etc.)
The plan is to first support Java 7: https://github.com/gwtproject/gwt/labels/java7
This involves updating JDT, and this is being worked on (or alternatively, switch to something else entirely; JetBrains proposed using their parser which already supports Java 8, but GWT also needs a compiler and I don't know what they provide exactly). The next steps are to map new language constructs to JavaScript (strings-in-switch come to mind, as they could directly map to JavaScript without the hashCode-based desugaring that a Java compiler would be doing).
As long as GWT uses JDT for its Java parsing/munging/compiling, Java 8 can only be supported when JDT will support it (at an acceptable level, which is not yet the case AFAICT).
Time to update the answer.
UPDATE (May 13, 2020)
GWT 2.9.0 finally here. Release notes
Able to compile projects with jsinterop-base 1.0.0, elemental2 1.0.0, and jsinterop-annotations 2.0.0. With the exception of #JsAsync and #JsEnum, this brings GWT2 to be compatible across these tools with J2CL.
Added support for Java language levels 9, 10, and 11.
Officially, support is dropped for running the GWT compiler or server-side tooling on Java 7. The GWT distribution is still compiled to run on Java 7 for this release, but no guarantees are made about whether or not this will work. Future versions will compile bytecode for Java 8+. The release was tested and found to work cross platform when run with Java 8, 11, and 14.
UPDATE (October 2017)
GWT 2.8.2 available here. Release notes.
UPDATE (June 2017)
Official GWT 2.8.1 download location.
Release Notes for 2.8.1
UPDATE (October 2016)
GWT 2.8.0 is finally here!
The GWT team has released the 2.8.0 tag on Github. The official GWT website has not been updated yet, but a pull request for the changes on GWT's website is ready and in review process. So very very soon the compiled version will be available for download!
Available for download
UPDATE (September 2016)
Meanwhile, team GWT has tagged GWT 2.8.0 RC3 on GitHub mirror.
The GWT team (Daniel Kurka) has released the GWT 2.8.0 (RC2) version here.
The release notes are available for 2.8.0 (RC2):
Bug fixes
Fix incorrect unusable-by-js warning.
Fix an issue around DevMode server (jetty) restart.
Fix an issue in super dev mode with changing compiler options not triggering full recompiles.
Added missing command line parameters to DevMode entry point
Fixed a performance regression in String.
The release notes from RC1 are available on official website. Here are the most important changes regarding Java 8 support in the upcoming GWT 2.8.0:
Highlights
Partial support for Java 8 standard library APIs (see below for full list).
Fix memory leak with Java 8 compilation.
Source level set to Java 8.
Static and default methods in interfaces aren’t visible to generators. If you want to take advantage of those Java-8isms, you’re encouraged to switch to an annotation processor. This could break existing build if an interface is changed to turn a non-default method into a default method.
JDK 8 emulation support
Emulate java.io.UncheckedIOException.
Emulate Optional and its int, long, double variants.
Emulate Objects.requireNonNull() with message Supplier.
Fix Math.min/max(float/double) emulation behavior.
Emulate Character.isBmpCodePoint().
Emulate CharSequence.chars().
Emulate java.lang.SecurityException.
Emulate Java 8 API of
java.util.Arrays,
java.util.ArrayDeque,
java.math.BigInteger,
java.util.BitSet,
java.util.Comparator,
java.util.function,
java.util.Iterator,
java.lang.Iterable,
java.util.IntSummaryStatistics/LongSummaryStatistics/DoubleSummaryStatistics
java.util.Collection/Lists/Queues,
java.util.Map,
java.util.logging.Logger,
java.util.PrimitiveIterator,
java.util.Spliterator,
java.util.stream,
java.util.StringJoiner
The GWT 2.8.0 RC2 still has some issues, which the GWT team is expected to fix soon. The final release should be coming out soon ("as soon as it is ready").
Related
Is httpclient-4.5.2.jar backward compatible with httpclient-4.3.6.jar?
Same question also for httpcore-4.4.4.jar with httpcore-4.3.3.jar?
I have to use a newer version for supporting some functionality. but is there any impact of my older code?
Is those jar version controlling working conventional way for backward compatibility support like java JDK?
Short answer no. For minor upgrades (4.3.3 to 4.3.4) things usually work, but when you go from 4.3 to 4.5 you can expect changes. See release notes for hints about what you can expect.
Having said that, if you can compile without errors you are usually safe!
Since recently I get support cases where the browser (Firefox, IE11) does not offer Java Web Start for .jnlp files – even after fresh Java installations. The users have to search for javaws.exe on their own.
Did anything change? Maybe with Java 9? We currently recommend Java 9 as we had some trouble with a bug in latest Java 8 (Update 161/162).
Does the Java 9 installer no longer associate JNLP with Java Web Start? Maybe having to do with that deprecation? (I was shocked about it, by the way. No idea how we can distribute our many different clients to thousands of business partners without Java Web Start.)
As of Java 9, the file association for Java Web Start no longer exists. Note that when you download Java from Sun, the latest current version is still version 8, which should still work.
You can alternatively create that association of .jnlp to javaws.exe, even in Java 9 and 10.
As of this year, Java 11 no longer contains the binary javaws.exe at all.
We are considering the adoption of a library to generate and use JSON Web Tokens. Jose4j seems a good choice but library "Dependencies" state that "...Jose4j is compiled with/for Java 7 and will also run on Java 8..." and our current instalation run on Java 6 version (migration to higher versions is out of our reach), so our question is simple.
Is there any chance to integrate Jose4j with Java 6? (not at all, with some limitations, can be achieved in any way by adding some specific libraries, etc.)
Thanks in advance
Getting jose4j to run on Java 6 is (probably) possible but will require recompilation and some code changes.
There have been a couple forks of somewhat older versions that I believe have back-ported to compile and run with Java 6 - https://bitbucket.org/yosef_kitrossky/jose4j-jdk1.6/commits/all is the most recent that I know about and there's also https://bitbucket.org/ijazfx/jose4j/commits/all
You could probably do a back-port of the latest too without too much trouble. The code base uses some multi-catch, diamond, and try-with-resources syntax that will need to be converted to the pre Java 7 equivalents. Somewhat tedious perhaps but not rocket surgery. There are also some algorithms that won't work. Some might just not be available at runtime and some, like all the AES-GCM related bits, will need to be removed from the code to get it to compile.
You'll also want to have the JCE Unlimited Strength Jurisdiction Policy File(s) in place as some of the unit tests use AES keys that are larger than 128 bits http://www.oracle.com/technetwork/java/javase/downloads/jce-6-download-429243.html
I hope this helps. Unfortunately, I just don't have bandwidth to maintain a Java 6 compatible version myself.
Nimbus JOSE + JWT have support for Java 6 since 4.11.1 version.
From documentation, you just need inform the classifier in the dependency:
<dependency>
<groupId>com.nimbusds</groupId>
<artifactId>nimbus-jose-jwt</artifactId>
<classifier>jdk16</classifier>
<version>[ version ]</version>
</dependency>
You can find the available versions here.
Does anybody have successfully working module in DNN 6 with the Ajax Control Toolkit?
My modules stopped working when we migrated from DNN 5.x to to 6.x.
Modules compile without errors but I am getting client side script error:
'AjaxControlToolkit requires ASP.NET Ajax 4.0 scripts. Ensure the correct version of the scripts are referenced. If you are using an ASP.NET ScriptManager, switch to the ToolkitScriptManager in AjaxControlToolkit.dll'
Seems like this is conflict with Telerik's controls, according to information that I have found. But I didn't find any info how to fix it.
You should be able to use older versions of the ASP.NET AJAX Control Toolkit, but once they start requiring the ToolkitScriptManager, you're out of luck with DNN (though you'll be out of luck with any version of DNN, since there's not a way to override the type of ScriptManager it uses.
Starting with DNN 6, they use Telerik's RadScriptManager. Previously, you could modify the core code to switch out for the ToolkitScriptManager, but now switching out might cause other issues.
It could work together, but you'll need do some modifications to the core of DNN.
Here the list of things to do:
Check that you're using latest version of .Net 4.0 binaries of AjaxControlToolkit (I was able to let it work for DNN 6.0.1 with Telerik 2011.01.519 and ACT September 2011 v4.1.50927)
Check that in your web.config you have assembly binding redirects for System.Web.Extensions and System.Web.Extensions.Design to the version 4.0
Take DNN source package, find Library\Framework\AJAX.cs, locate method AddScriptManager, instantiation of RadScriptManager in it, for the version 6.0.1 look into line 54. Add one more property initializer:
EnableScriptCombine = false. Compile it (in Release configuration, of course), take DotNetNuke.dll and drop into your DNN installation.
You should be done.
Credits goes to Telerik support, despite it's stated there that it should work out of the box starting from 2010.1.625. Not sure, did I get them wrong, or they just reintroduced this bug.
P.S. DNN support promises to release version 6.1.0 in November with updated Telerik controls, which should fix this issue, at least on their opinion.
Just checked with nuke 6.1 and the last version of jaxcontroltoolkit - still the same error.
It looks like it's not supported anymore. Sad:(
I'm new to GWT development and I'm putting myself through the paces with Google's tutorial but I'm getting errors:
java[10574:80f] [Java CocoaComponent compatibility mode]: Enabled
2009-11-06 15:27:38.769 java[10574:80f] [Java CocoaComponent compatibility mode]: Setting timeout for SWT to 0.100000
I checked my Java prefs and I have Java SE6 (64 bit) as the preferred JVM. I'm really not sure how to clear this up.
I think gwt hosted mode only works in a 32 bit environment, as of gwt version 1.7.1. Try passing "-d32" as an argument to the jvm to tell java 6 to run in 32 bit mode. That seems to work for me in Eclipse 3.5, Gwt 1.7.1 in Snow Leopard.
If it still doesn't work, searching google for "Leopard GWT d32" should turn up some articles that should help you troubleshoot more.
This message just means that the GWT toolset has loaded the Mac Java AWT at some point, and when you do that in Eclipse or any other SWT application you will get this message.
For you it's harmless and isn't the result of anything that you did in your code.
There's an open issue on GWT and 64-bit Java that's been around for a long time, and includes various workarounds that you may be able to get to work. GWT 2 (not yet released) doesn't use the same hosted mode, and so the GWT developers say it won't have this issue.