Re: Next release

[Cristiano]

Hi Thomas, Hi all,

I've recently studied and "hacked" the code server and I have grown an 
opinion about this, let me share some thoughts.

I do prefer too that Jetty get stripped off from GWT, I find generically 
the same issue of Luis and Bendg; 
it is true there are many ways to work around these issues, but it can get 
very annoying in the end.

In my studies I have "hacked" the code server, and I've noted that the 
codeserver's com.google.gwt.dev.codeserver.WebServer is the class 
responsible of depending on Jetty.
It basically creates an anonymous Servlet and start it with an embedded 
Jetty, but it is all merged on a single class with many responsibilities 
and it is very hard to reuse.

Well, the good news is that even if Jetty has very bad records of backward 
compatibility, the servlet standard has a very good one, and I think that 
if we split the CodeServer's Servlet from the Embedded Jetty Server 
implementation, anyone can get happy.

This is not an hypothesis, I've actually made it working: I have created a 
pure servlet, extracted from WebServer, that provides the code server 
functionality.
I've been able to run this servlet on the Jetty version that I prefer 
(Jetty 9.2.11.v20150529), and moreover, I've used a single embedded Jetty 
server, written by myself that run both the GWT application and the Code 
Server's servlet. This CodeServer don't runs on port 9876, it runs instead 
on sub-path /dev-mode, same port.
With this configuration, I've achieved another goal (well, actually it was 
my primary one): I've been able to use the SSO linker with SuperDevMode 
(with limitations, I need to open manually the url http://localhost:**/
*dev-mode*
/recompile/my_module?_callback=__gwt_sdm_globals.callbacks.c1444718136184 

  
to trigger recompilation, and the SuperDevMode compiled Javascript is 
included with a script tag like http://localhost:8082/dev-mode/wunit_logic/wunit_logic.nocache.js>"> 
- anyway this can be improved and automated easily).

Another relevant consideration is that with these configuration, I've been 
able to develop and debug (server side for the moment) GWT *without the 
Eclipse Plugin*: 
I think next generation of GWT should follow such approach, that it is 
inspired on what the Wicket framework provides: if you try to create a 
Wicket archetype (use this command: mvn archetype:generate 
-DarchetypeGroupId=org.apache.wicket 
-DarchetypeArtifactId=wicket-archetype-quickstart -DarchetypeVersion=7.0.0 
-DgroupId=org.example.jetty.embedded.wicket.check 
-DartifactId=check-wicket-embedded-jetty 
-DarchetypeRepository=https://repository.apache.org/ -DinteractiveMode=false), 
you'll see that it creates an embedded Jetty server in test sources, and it 
can be started in Eclipse as any regular Java application. If GWT would 
follow the same approach, it could create an embedded jetty server that 
also starts a CodeServer Servlet, or maybe a Servlet Filter that intercepts 
Javascript requests for GWT's *.nocache.js files and recompiles them on the 
fly.


I don't have "clean" code to share, but if there is interest I can share 
these modified classes or describe the modification I've ade (note though 
I'm not using this code in production, I've just hacked it while studying 
the feasibility of some other PoC using SSO linker).

If I reach some more concrete results, I'll show them to the GWTcon in 
Florence next 11 november, where I hope to meet and discuss about these 
topics with a wide community.

Hope this is interesting,
have a nice day,

Cristiano

-- 
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-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: GWT app shows wrong on iPad/Safari?

[Magnus]

On Saturday, October 17, 2015 at 3:18:11 PM UTC+2, james0072 wrote:
>
> Did you use the viewport in the html?
>
> https://developer.mozilla.org/en-US/docs/Mozilla/Mobile/Viewport_meta_tag
>

No, but the page you pointed to sounds like there could be a solution.
But if I add a viewport tag, what about the "normal" PCs where my app 
already shows correctly?

And what width should I set in the viewport?
I don't know the device my app is running on. Do I have to "detect" the 
device and set the viewport then? Sounds cumbersome...

Thank you
Magnus

-- 
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-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: byte array to Image

[Anonymous]

Hello Magallo

You can use a code like this:

*protected* *void* doGet(HttpServletRequest request, HttpServletResponse 
response) *throws* ServletException, IOException { 

response.setContentType("image/png"); 

*if*(request.getParameter("id") != *null*) {

*   if*(request.getParameter("id").equals("")) {

  response.sendError(500, "Bad request | Please provide an existing 
...?id=X");

   }

*  else* {

*int* mapID = Integer.*parseInt*(request.getParameter("id"));

*byte*[] image = *null*; 

*try* { 

   yourClientWrapper wrapper = yourDao.readById((*long*) mapID);

   image = wrapper.getYourImage();

} 

*catch* (Exception e) { 

   e.printStackTrace(); 

} 

 OutputStream out = response.getOutputStream(); 

 out.write(image); 

 out.close(); 

  }

}

*else* {

   response.sendError(500, "Bad request | Please provide an existing id 
with ...?id=X");

}

} 

On the client side: You just insert your Servlet-Url as the Image Resource 
(src-Attribute) like 
http://www.yourfancyurl.com/yourgwtapplication/servlet/imageGetter?id=31) 
and that's it. The servlet returns the image to the corresponding id 
without saving it to the disk.
I hope that this little explanation helps :)


Best regards



Am Montag, 4. Juni 2012 12:34:14 UTC+2 schrieb Magallo:

> Excuse me Agito M, I'm intereseted in this solution. You said that "Code 
> on the client side didn't change from what I earlier posted.". What do you 
> mean? How do you call the servlet and how do you process the result and 
> create the image client side? Please, could you possibly post some code to 
> let me understand this? Thanks.
>
> Il giorno martedì 27 settembre 2011 12:56:12 UTC+2, AgitoM ha scritto:
>>
>> Decided to deal with the 32kb limit in Internet Explorer 8. (Internet 
>> Explorer 9 is not a problem). 
>> Dealt with the problem by creating a servlet that outputs the byte 
>> array as a image. 
>> I'm sending the ID of the image, in this case a map, to the servlet 
>> using the GET method. 
>>
>> This is the code for the doGet operation for my dedicated 
>> ImageServlet: 
>>
>> protected void doGet(HttpServletRequest request, HttpServletResponse 
>> response) throws ServletException, IOException { 
>> response.setContentType("image/png"); 
>>
>> if(request.getParameter("MapID") != null) { 
>> int mapID = 
>> Integer.parseInt(request.getParameter("MapID")); 
>>
>> byte[] image = null; 
>> try { 
>> image = wsStub.getMapImage(mapID); 
>> } 
>> catch (Exception e) { 
>> e.printStackTrace(); 
>> } 
>>
>> OutputStream out = response.getOutputStream(); 
>> out.write(image); 
>> out.close(); 
>> } 
>> } 
>>
>> On my RPC Servlet side, I simply return this as the "URL" of the 
>> image: 
>> ("ImageServlet?MapID=" + mapID) 
>>
>> Code on the client side didn't change from what I earlier posted.
>
>

-- 
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-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: Roadmap Question for GWT 3.0

[Thomas Broyer]

On Monday, October 19, 2015 at 12:22:19 PM UTC+2, Jens wrote:
>
>
>> * Stick with 2.x and risk being left behind and the project becoming 
>> neglected due to split effort.
>>
>
> You are not behind when using 2.x:
>
> GWT 2 = GWT 2.x Compiler + JsInterop + Elemental 1 + Elemental 2 when 
> released + all current GWT SDK code + all GWT libraries.
> GWT 3 = J2CL + JsInterop + Elemental 2 + anything from GWT SDK and other 
> GWT libraries that is compatible with J2CL
>
> So not such a difference right? In fact with GWT 3 you currently get less 
> than with GWT 2.x because you can not use all library code available. 
> However everything that works with GWT 3 should automatically also work 
> with GWT 2.
>

I don't think "JSNI 2" (the one without the 'native' keyword and special 
comment syntax) will be backported to GWT 2.x, and evolutions to JsInterop 
are likely to be GWT 3+ only too.
I think what salk31 meant is that in one or 2 years from now, GWT 2.x might 
really be "behind", depending on who puts the efforts in supporting GWT 
2.x. Who knows if existing library code won't break in newer versions of 
evergreen browsers? (just like History.newItem in GWT <=2.6 breaks in 
Firefox 41+ because Firefox finally aligned its behavior on the "consensus" 
specified in "HTML the living standard"; more generally, all 
permutation-specific code might break in the future as browsers converge to 
an interoperable behavior, so GWT 2.x will have to be actively maintained). 
And as GWT 3.x and 2.x will start diverging (JSNI 2, JsInterop 2; Java 9 
?), libraries will start to become incompatible with GWT 2.x.

So I really think that this is a legitimate concern, and that nobody has 
the answer yet. The only thing we're sure is that Google will push 
internally to moving to j2cl; we just don't know how they'll do it (rewrite 
parts of the apps that aren't compatible with j2cl, or start bringing to 
GWT 3.x the libs that they internally need, possibly not in a fully 
backwards-compatible way though, as they have the tooling to refactor all 
their codebase at once: kythe, refaster, etc.)

-- 
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-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: Roadmap Question for GWT 3.0

[Jens]

>
>
> * Stick with 2.x and risk being left behind and the project becoming 
> neglected due to split effort.
>

You are not behind when using 2.x:

GWT 2 = GWT 2.x Compiler + JsInterop + Elemental 1 + Elemental 2 when 
released + all current GWT SDK code + all GWT libraries.
GWT 3 = J2CL + JsInterop + Elemental 2 + anything from GWT SDK and other 
GWT libraries that is compatible with J2CL

So not such a difference right? In fact with GWT 3 you currently get less 
than with GWT 2.x because you can not use all library code available. 
However everything that works with GWT 3 should automatically also work 
with GWT 2. 

 

> FWIW Our team works on a single app that is meant to have a life of 10+ 
> years.
>

Same here, but I am not concerned at all about using GWT 2. However maybe I 
get jealous if GWT 3 provides a lot faster developer workflow.


-- J.

-- 
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-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: Roadmap Question for GWT 3.0

[Vassilis Virvilis]

Actually what makes sense for me in an after split era is

* compile with the newest GWT 3.5, 4, 5 to pick up new features
* link with legacy but compatible gwt-widgets until I can gradually get rid
of them - or not.

This way I can migrate step by step my application (widget per widget) and
stay relevant in the meantime or for some application to not upgrade at all.

Of course that assumes that gwt widgets will be maintained at least
minimally to the point that they are compilable with the newer GWT versions.



On Mon, Oct 19, 2015 at 12:46 PM, salk31  wrote:

> I'm trying to understand my options.
> * Stick with 2.x and risk being left behind and the project becoming
> neglected due to split effort.
> * Try to migrate to 3.x and possibly throw away a big investment.
> * Look to move to something other than GWT.
>
> Obviously we will also be taking action to isolate ourselves from this
> uncertainty. A lot of that is just good practice anyway.
>
> FWIW Our team works on a single app that is meant to have a life of 10+
> years.
>
> On Monday, October 19, 2015 at 10:00:48 AM UTC+1, Jens wrote:
>>
>> Somehow people seem to forget that they don't have to migrate at all if
>> its not profitable. Just stay on GWT 2.8.x and only start new projects with
>> new technology. There will be plenty of companies that have huge apps that
>> will not be rewritten anytime soon (if at all) so IMHO GWT 2.8.x will
>> continuously get bug fixes for years. Maybe in the long run not from the
>> Google GWT team because Google has the power to actually migrate their apps
>> and will probably focus on the new compiler then once that has happened.
>>
>> Personally I consider the new Java to Closure compiler/transpiler as a
>> separate product. Migrating to a new product costs money and time so its
>> totally valid to not migrate. Our company will definitely not migrate
>> anytime soon unless there is an easy incremental migration path. Only new
>> stuff might be build with the new Java to Closure compiler.
>>
>> -- J.
>>
> --
> 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-toolkit+unsubscr...@googlegroups.com.
> To post to this group, send email to google-web-toolkit@googlegroups.com.
> Visit this group at http://groups.google.com/group/google-web-toolkit.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Vassilis Virvilis

-- 
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-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: Roadmap Question for GWT 3.0

[salk31]

I'm trying to understand my options.
* Stick with 2.x and risk being left behind and the project becoming 
neglected due to split effort.
* Try to migrate to 3.x and possibly throw away a big investment.
* Look to move to something other than GWT.

Obviously we will also be taking action to isolate ourselves from this 
uncertainty. A lot of that is just good practice anyway.

FWIW Our team works on a single app that is meant to have a life of 10+ 
years.

On Monday, October 19, 2015 at 10:00:48 AM UTC+1, Jens wrote:
>
> Somehow people seem to forget that they don't have to migrate at all if 
> its not profitable. Just stay on GWT 2.8.x and only start new projects with 
> new technology. There will be plenty of companies that have huge apps that 
> will not be rewritten anytime soon (if at all) so IMHO GWT 2.8.x will 
> continuously get bug fixes for years. Maybe in the long run not from the 
> Google GWT team because Google has the power to actually migrate their apps 
> and will probably focus on the new compiler then once that has happened.
>
> Personally I consider the new Java to Closure compiler/transpiler as a 
> separate product. Migrating to a new product costs money and time so its 
> totally valid to not migrate. Our company will definitely not migrate 
> anytime soon unless there is an easy incremental migration path. Only new 
> stuff might be build with the new Java to Closure compiler. 
>
> -- J.
>

-- 
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-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: Roadmap Question for GWT 3.0

[Jens]

Somehow people seem to forget that they don't have to migrate at all if its 
not profitable. Just stay on GWT 2.8.x and only start new projects with new 
technology. There will be plenty of companies that have huge apps that will 
not be rewritten anytime soon (if at all) so IMHO GWT 2.8.x will 
continuously get bug fixes for years. Maybe in the long run not from the 
Google GWT team because Google has the power to actually migrate their apps 
and will probably focus on the new compiler then once that has happened.

Personally I consider the new Java to Closure compiler/transpiler as a 
separate product. Migrating to a new product costs money and time so its 
totally valid to not migrate. Our company will definitely not migrate 
anytime soon unless there is an easy incremental migration path. Only new 
stuff might be build with the new Java to Closure compiler. 

-- J.

-- 
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-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: Roadmap Question for GWT 3.0

[Ümit Seren]

+1
I think the division of GWT-compiler and GWT-widgets is the right thing to
do. The web-platform is moving fast and to GWT has to adopt to stay
relevant.
Webcomponents have the potential to become the new widgets and the new
JSInterops will make it quite easy to consume webcomponents that are
developed in vanilla JS. Also, now that Microsoft moved to an evergreen
approach with their Edge browser, all the quirks with browser
incompatibilities will become less and less important.
Dart is also taking a similar appraoch. They are working on a new JSInterop
that is annotated based and looks quite similar to GWT's JSInterops (
http://work.j832.com/2015/10/byojsl.html) and they are working on a
DEV_compiler that allows to easily consume Dart from Javascript (similar to
what @JsExport does I guess).
I know that many people have huge legacy apps that are based on GWT-widgets
and it is a pain to migrate but it does not have to be an all or nothing
approach. It is possible to phase out gwt-widgets step by step with 2.8 and
once everything is phased out switch to GWT 3.0. Also there is no reason
why one couldn't just use GWT 2.8 because if one heavily use the
GWT-widgets abstractions and is not really working close the web plattform,
then GWT 3.0 won't give any real killer features that are not available in
2.8 (IMHO).

In general I am quite excited about the future of GWT.

On Mon, Oct 19, 2015 at 9:46 AM, Vassilis Virvilis 
wrote:

> If you just want to run java apps in the browser there are solutions out
> thtere
> Free: http://www.webswing.org
> Paying: http://www.creamtec.com/products/ajaxswing/overview.html
>
> Now if you want to run create webapps then it is another matter. For me
> the web stack is a crazy platform. But still since it is backed by all
> these people (us, developers) is the __platform__ and if you want to write
> for the __platform__ then you have to speak the platform language natively.
> That is HTML, CSS, JS. All the  new cool things, the new UI paradigms the
> new libraries the new API are happening in browser-land in JS.
>
> I think that the GWT did the right thing with the super dev mode. I
> develop in chromium and firefox. I occasionally test in IE and in Safari to
> deal with the weird platform idiosyncrasies (bugs?). I also test less often
> in mobile devices to get the touch events more or less right. How I am
> about to test all these things in classic dev mode with Firefox 24? Why do
> I need a java debugger when my main problem is not on the logical end of my
> program but on the assumptions my program makes for the platform it runs
> on? (Why the event didn't fire? Why it did fire multiple times? What does
> preventDefault() does in this case? Why there are extra padding? Where the
> hell is my padding? Who painted my pixels?)
>
> About the fork you mentioned. I think the GWT is on the right track also
> on this one. I am slowly phasing out the use of gwt widgets not because I
> want to, not because they are not working good enough. They are perfectly
> fine for me but my users want more shiny toys i.e. rotary dials instead of
> menus and drawers instead of pull down menus or menubars. And you have to
> admit the GWT widgets are somewhat rusty - most of them are designed with
> tables and they are impossible to change without breaking compatibility.
>
> So I believe a division of GWT to GWT-compiler and GWT-widgets as a
> separate compatible library is not a bad move especially if it accompanied
> with a better ([semi] automatic) way to interface new and cool JS libraries
> like JSInterop claims to be. It makes perfect sense to me.
>
>
> On Mon, Oct 19, 2015 at 9:39 AM, salk31  wrote:
>
>> Maybe there is effectively going to be a fork? So if the interest was
>> there could be GWT 2.9 - GWT 2.123
>>
>> I think that might represent the truth that there is one user base that
>> wants to build Java apps that happen to run in a browser vs users who are
>> working on products that need to squeeze everything out of the browser.
>>
>> The discussion about classic dev mode didn't seem very healthy
>> https://groups.google.com/forum/#!topic/google-web-toolkit/QSEjbhhHB4g
>>  maybe because of this split?
>>
>>
>>
>> On Sunday, October 18, 2015 at 5:13:12 PM UTC+1, steve Zara wrote:
>>>
>>> I'm eager for GWT 2.8 because of Lambda support, but I can't see that my
>>> company will ever use GWT 3.0 if what you write is true. We have products
>>> that make substantial use of GWT Widgets, and there is no prospect of
>>> re-writing to some other system.  GWT without the Widgets just isn't GWT -
>>> it's just a Java -> JavaScript transpiler.  We also use UIBinder heavily.
>>>
>>> Of course, this may not be what happens.  It's a symptom of what seems
>>> to be a common problem with GWT - lack of clear information about what is
>>> happening with the project (still no sign of GWT 2.8, and no indication of
>>> when there might be a sign).
>>>
>>> GWT really is wonderful and has been a source of grea

Re: Roadmap Question for GWT 3.0

[Vassilis Virvilis]

If you just want to run java apps in the browser there are solutions out
thtere
Free: http://www.webswing.org
Paying: http://www.creamtec.com/products/ajaxswing/overview.html

Now if you want to run create webapps then it is another matter. For me the
web stack is a crazy platform. But still since it is backed by all these
people (us, developers) is the __platform__ and if you want to write for
the __platform__ then you have to speak the platform language natively.
That is HTML, CSS, JS. All the  new cool things, the new UI paradigms the
new libraries the new API are happening in browser-land in JS.

I think that the GWT did the right thing with the super dev mode. I develop
in chromium and firefox. I occasionally test in IE and in Safari to deal
with the weird platform idiosyncrasies (bugs?). I also test less often in
mobile devices to get the touch events more or less right. How I am about
to test all these things in classic dev mode with Firefox 24? Why do I need
a java debugger when my main problem is not on the logical end of my
program but on the assumptions my program makes for the platform it runs
on? (Why the event didn't fire? Why it did fire multiple times? What does
preventDefault() does in this case? Why there are extra padding? Where the
hell is my padding? Who painted my pixels?)

About the fork you mentioned. I think the GWT is on the right track also on
this one. I am slowly phasing out the use of gwt widgets not because I want
to, not because they are not working good enough. They are perfectly fine
for me but my users want more shiny toys i.e. rotary dials instead of menus
and drawers instead of pull down menus or menubars. And you have to admit
the GWT widgets are somewhat rusty - most of them are designed with tables
and they are impossible to change without breaking compatibility.

So I believe a division of GWT to GWT-compiler and GWT-widgets as a
separate compatible library is not a bad move especially if it accompanied
with a better ([semi] automatic) way to interface new and cool JS libraries
like JSInterop claims to be. It makes perfect sense to me.


On Mon, Oct 19, 2015 at 9:39 AM, salk31  wrote:

> Maybe there is effectively going to be a fork? So if the interest was
> there could be GWT 2.9 - GWT 2.123
>
> I think that might represent the truth that there is one user base that
> wants to build Java apps that happen to run in a browser vs users who are
> working on products that need to squeeze everything out of the browser.
>
> The discussion about classic dev mode didn't seem very healthy
> https://groups.google.com/forum/#!topic/google-web-toolkit/QSEjbhhHB4g
>  maybe because of this split?
>
>
>
> On Sunday, October 18, 2015 at 5:13:12 PM UTC+1, steve Zara wrote:
>>
>> I'm eager for GWT 2.8 because of Lambda support, but I can't see that my
>> company will ever use GWT 3.0 if what you write is true. We have products
>> that make substantial use of GWT Widgets, and there is no prospect of
>> re-writing to some other system.  GWT without the Widgets just isn't GWT -
>> it's just a Java -> JavaScript transpiler.  We also use UIBinder heavily.
>>
>> Of course, this may not be what happens.  It's a symptom of what seems to
>> be a common problem with GWT - lack of clear information about what is
>> happening with the project (still no sign of GWT 2.8, and no indication of
>> when there might be a sign).
>>
>> GWT really is wonderful and has been a source of great productivity for
>> my company for many years.  I really hope the heart of it isn't slashed out
>> to produce some incompatible new version.
>>
>> On Saturday, 17 October 2015 11:36:45 UTC+1, salk31 wrote:
>>>
>>> Thanks Thomas,
>>>
>>> For my own use I'm going to keep a list of what I think I know
>>> http://salk31.blogspot.co.uk/2015/10/gwt-30-migration.html corrections
>>> welcome.
>>>
>>> I can see why they want to reduce the scope of GWT and integrate (not
>>> build) but is such a high quality complete package in 2.7 it is a bit
>>> scary. I've had to use BroadVision, Vignette, Struts 1, Cocoon, Wicket...
>>> in the past and GWT felt like finally web development had grown up.
>>> o
>>> On Friday, October 16, 2015 at 5:44:25 PM UTC+1, Thomas Broyer wrote:

 I think nobody has such information yet; not even Google who are
 pushing for the change. They do have many apps that use widgets and RPC
 today (example: Google Groups, the exact app I'm typing this message into)
 and will need to come up with a migration path for those apps too.

 On Friday, October 16, 2015 at 2:19:02 PM UTC+2, salk31 wrote:
>
> Is there a guide somewhere of migration path to 3.0 per feature?
>
> I've been trying to follow these threads but I'm still not sure on the
> future of things like RequestFactory and Editor. They heavily depend on
> GWT.create and the latter depends on Widgets, are they really going away?
>
> We have a large-ish app so want to start worrying about migration e

Re: Roadmap Question for GWT 3.0

[salk31]

I can see the logic of GWT 3.0. The browser has evolved a lot since GWT was 
first designed. Back in those days every browser had significant quirks and 
the lowest common denominator was very low. In 2015 there is less reason 
for a big layer between domain code and the browser. I think the same 
applies to JQuery etc. I also think GWT wasn't quite sure how to do layout 
which harms love for it. There is a fork in the Widgets for the Layout and 
non-Layout classes. Hence two TabPanels etc? A fight between those that 
wanted to do layout like Swing and those that wanted to lean on the browser 
renderer?


On Monday, October 19, 2015 at 8:18:14 AM UTC+1, steve Zara wrote:
>
> I'm puzzled as to what the disadvantages could be of GWT Widgets.  They 
> are, after all, translated to efficient JavaScript and allow full use of 
> the browser.  I can see that some developers might want to integrate with 
> JavaScript frameworks, but others, like me, start writing applications in 
> pure GWT and use of JavaScript is just like use of JNI in typical Java code 
> - for those rare things you can't do in Java, or to connect with libraries.
>
> I guess if there was a split there could be much more work on what many 
> developers seem to want, such as a cross-browser debugging toolkit that 
> makes use of source maps consistent and gives a better Java-style view of 
> variables.  
>
> I want to see Java as a primary language for browser development, not some 
> secondary add-on to JavaScript frameworks.
>
> On 19 October 2015 at 07:39, salk31 > 
> wrote:
>
>> Maybe there is effectively going to be a fork? So if the interest was 
>> there could be GWT 2.9 - GWT 2.123
>>
>> I think that might represent the truth that there is one user base that 
>> wants to build Java apps that happen to run in a browser vs users who are 
>> working on products that need to squeeze everything out of the browser.
>>
>> The discussion about classic dev mode didn't seem very healthy 
>> https://groups.google.com/forum/#!topic/google-web-toolkit/QSEjbhhHB4g 
>>  maybe because of this split?
>>
>>
>>
>> On Sunday, October 18, 2015 at 5:13:12 PM UTC+1, steve Zara wrote:
>>>
>>> I'm eager for GWT 2.8 because of Lambda support, but I can't see that my 
>>> company will ever use GWT 3.0 if what you write is true. We have products 
>>> that make substantial use of GWT Widgets, and there is no prospect of 
>>> re-writing to some other system.  GWT without the Widgets just isn't GWT - 
>>> it's just a Java -> JavaScript transpiler.  We also use UIBinder heavily.  
>>>
>>> Of course, this may not be what happens.  It's a symptom of what seems 
>>> to be a common problem with GWT - lack of clear information about what is 
>>> happening with the project (still no sign of GWT 2.8, and no indication of 
>>> when there might be a sign).
>>>
>>> GWT really is wonderful and has been a source of great productivity for 
>>> my company for many years.  I really hope the heart of it isn't slashed out 
>>> to produce some incompatible new version.  
>>>
>>> On Saturday, 17 October 2015 11:36:45 UTC+1, salk31 wrote:

 Thanks Thomas,

 For my own use I'm going to keep a list of what I think I know 
 http://salk31.blogspot.co.uk/2015/10/gwt-30-migration.html corrections 
 welcome.

 I can see why they want to reduce the scope of GWT and integrate (not 
 build) but is such a high quality complete package in 2.7 it is a bit 
 scary. I've had to use BroadVision, Vignette, Struts 1, Cocoon, Wicket... 
 in the past and GWT felt like finally web development had grown up.
 o
 On Friday, October 16, 2015 at 5:44:25 PM UTC+1, Thomas Broyer wrote:
>
> I think nobody has such information yet; not even Google who are 
> pushing for the change. They do have many apps that use widgets and RPC 
> today (example: Google Groups, the exact app I'm typing this message 
> into) 
> and will need to come up with a migration path for those apps too.
>
> On Friday, October 16, 2015 at 2:19:02 PM UTC+2, salk31 wrote:
>>
>> Is there a guide somewhere of migration path to 3.0 per feature? 
>>
>> I've been trying to follow these threads but I'm still not sure on 
>> the future of things like RequestFactory and Editor. They heavily depend 
>> on 
>> GWT.create and the latter depends on Widgets, are they really going away?
>>
>> We have a large-ish app so want to start worrying about migration 
>> even if we are long way off.
>>
>> Cheers
>>
>> Sam
>>
>> On Tuesday, July 28, 2015 at 10:01:21 AM UTC+1, Jens wrote:
>>>
>>>
>>> Where can I read that GWT RPC and widget system will be dropped with 
 GWT 3.0? Is there a presentation / doc online? 

 And what does it mean that GWT.create will be dropped? 

 And: really dropped or set as deprecated? 

>>>
>>> GWT 3.0 drops support for JSNI and

Re: Roadmap Question for GWT 3.0

['steve Zara' via GWT Users]

I'm puzzled as to what the disadvantages could be of GWT Widgets.  They
are, after all, translated to efficient JavaScript and allow full use of
the browser.  I can see that some developers might want to integrate with
JavaScript frameworks, but others, like me, start writing applications in
pure GWT and use of JavaScript is just like use of JNI in typical Java code
- for those rare things you can't do in Java, or to connect with libraries.

I guess if there was a split there could be much more work on what many
developers seem to want, such as a cross-browser debugging toolkit that
makes use of source maps consistent and gives a better Java-style view of
variables.

I want to see Java as a primary language for browser development, not some
secondary add-on to JavaScript frameworks.

On 19 October 2015 at 07:39, salk31  wrote:

> Maybe there is effectively going to be a fork? So if the interest was
> there could be GWT 2.9 - GWT 2.123
>
> I think that might represent the truth that there is one user base that
> wants to build Java apps that happen to run in a browser vs users who are
> working on products that need to squeeze everything out of the browser.
>
> The discussion about classic dev mode didn't seem very healthy
> https://groups.google.com/forum/#!topic/google-web-toolkit/QSEjbhhHB4g
>  maybe because of this split?
>
>
>
> On Sunday, October 18, 2015 at 5:13:12 PM UTC+1, steve Zara wrote:
>>
>> I'm eager for GWT 2.8 because of Lambda support, but I can't see that my
>> company will ever use GWT 3.0 if what you write is true. We have products
>> that make substantial use of GWT Widgets, and there is no prospect of
>> re-writing to some other system.  GWT without the Widgets just isn't GWT -
>> it's just a Java -> JavaScript transpiler.  We also use UIBinder heavily.
>>
>> Of course, this may not be what happens.  It's a symptom of what seems to
>> be a common problem with GWT - lack of clear information about what is
>> happening with the project (still no sign of GWT 2.8, and no indication of
>> when there might be a sign).
>>
>> GWT really is wonderful and has been a source of great productivity for
>> my company for many years.  I really hope the heart of it isn't slashed out
>> to produce some incompatible new version.
>>
>> On Saturday, 17 October 2015 11:36:45 UTC+1, salk31 wrote:
>>>
>>> Thanks Thomas,
>>>
>>> For my own use I'm going to keep a list of what I think I know
>>> http://salk31.blogspot.co.uk/2015/10/gwt-30-migration.html corrections
>>> welcome.
>>>
>>> I can see why they want to reduce the scope of GWT and integrate (not
>>> build) but is such a high quality complete package in 2.7 it is a bit
>>> scary. I've had to use BroadVision, Vignette, Struts 1, Cocoon, Wicket...
>>> in the past and GWT felt like finally web development had grown up.
>>> o
>>> On Friday, October 16, 2015 at 5:44:25 PM UTC+1, Thomas Broyer wrote:

 I think nobody has such information yet; not even Google who are
 pushing for the change. They do have many apps that use widgets and RPC
 today (example: Google Groups, the exact app I'm typing this message into)
 and will need to come up with a migration path for those apps too.

 On Friday, October 16, 2015 at 2:19:02 PM UTC+2, salk31 wrote:
>
> Is there a guide somewhere of migration path to 3.0 per feature?
>
> I've been trying to follow these threads but I'm still not sure on the
> future of things like RequestFactory and Editor. They heavily depend on
> GWT.create and the latter depends on Widgets, are they really going away?
>
> We have a large-ish app so want to start worrying about migration even
> if we are long way off.
>
> Cheers
>
> Sam
>
> On Tuesday, July 28, 2015 at 10:01:21 AM UTC+1, Jens wrote:
>>
>>
>> Where can I read that GWT RPC and widget system will be dropped with
>>> GWT 3.0? Is there a presentation / doc online?
>>>
>>> And what does it mean that GWT.create will be dropped?
>>>
>>> And: really dropped or set as deprecated?
>>>
>>
>> GWT 3.0 drops support for JSNI and GWT.create(). JSNI will be
>> replaced with JsInterop and GWT.create() will be replaced with either
>> annotation processors (generate-with case) or dependency
>> injection/System.getProperty (replace-with case). So all library code of
>> GWT which depends on those two features need to be ported to the new GWT
>> compiler.
>>
>> Widget is probably doable but GWT-RPC might be really difficult (if
>> not impossible) because the current GWT-RPC generator asks questions like
>> "give me all types that implement XYZ" which an annotation processor can
>> only hardly answer (if at all). GWT-RPC might be portable if some
>> refactoring in the app using GWT-RPC is acceptable (e.g. slapping
>> annotations on DTOs instead of marking them with Serializable).
>>
>> You can see videos about that top