Roadmap Question for GWT 3.0

[Ed]

If I wanted to start now for the the GWT 3.0 release, what would be the
best mechanism to replace:

1. GWT.create

2. RPC

We starting a refactor of existing code, and would like some foresight into
this matter.

Thanks

Ed

[Jens]

Post by Ed
1. GWT.create

<generate-with>: Annotation processors
<replace-with>: Dagger 2.x + AutoFactory (assisted inject) for injection
and System.getProperty() to build the Dagger dependency graph based on your
deferred binding properties.

For Dagger I created a pull request that generates a dagger-gwt artifact
including a GWT module: https://github.com/google/dagger/pull/119



2. RPC
Anything that generates code in a way that is compatible with annotation
processors so they can migrate to APT in the future. I guess you need to
ask maintainers of your preferred alternatives and hear what they say.
Regardless of GWT 3.0 I would never really use GWT-RPC again because things
like RPC policy files, "do not use interfaces in serializable types" and
that it is hard to consume outside of GWT are annoying.



-- J.

[Ed]

Thanks Jens, Great response, gives our devs something to learn.

Post by Ed
1. GWT.create
<generate-with>: Annotation processors
<replace-with>: Dagger 2.x + AutoFactory (assisted inject) for injection
and System.getProperty() to build the Dagger dependency graph based on your
deferred binding properties.
For Dagger I created a pull request that generates a dagger-gwt artifact
including a GWT module: https://github.com/google/dagger/pull/119
2. RPC
Anything that generates code in a way that is compatible with annotation
processors so they can migrate to APT in the future. I guess you need to
ask maintainers of your preferred alternatives and hear what they say.
Regardless of GWT 3.0 I would never really use GWT-RPC again because things
like RPC policy files, "do not use interfaces in serializable types" and
that it is hard to consume outside of GWT are annoying.
-- J.
--
You received this message because you are subscribed to the Google Groups
"Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

[Ed]

@jens

Is there any downside to Request Builder? Possible deprecation in GWT 3.0?

Best Regards

Ed

Post by Ed
Thanks Jens, Great response, gives our devs something to learn.

Post by Ed
1. GWT.create
<generate-with>: Annotation processors
<replace-with>: Dagger 2.x + AutoFactory (assisted inject) for injection
and System.getProperty() to build the Dagger dependency graph based on your
deferred binding properties.
For Dagger I created a pull request that generates a dagger-gwt artifact
including a GWT module: https://github.com/google/dagger/pull/119
2. RPC
Anything that generates code in a way that is compatible with annotation
processors so they can migrate to APT in the future. I guess you need to
ask maintainers of your preferred alternatives and hear what they say.
Regardless of GWT 3.0 I would never really use GWT-RPC again because things
like RPC policy files, "do not use interfaces in serializable types" and
that it is hard to consume outside of GWT are annoying.
-- J.
--
You received this message because you are subscribed to the Google Groups
"Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

[Jens]

Post by Ed
Is there any downside to Request Builder? Possible deprecation in GWT 3.0?

Well the internally used XMLHttpRequest / Timer classes would need to be
ported to JsInterop of course because they use JSNI.

There are some general to consider with RequestBuilder as well:
- It is quite low level
- RequestCallback is not Java8 friendly (lambda / method references) as it
is not a SAM interface.
- for now does not support XHR 2 (ArrayBuffer, Blob, Document response
types) out of the box


-- J.

[Ümit Seren]

In addition to what Jens said:
If possible, go Restful. it makes it much easier to later add non-GWT
clients and also forces you to think about your domain model as resources
(might lead to a clean API).

I guess once Elemental 2.0 is released (AFAIK along the lines with GWT 3.0)
you could either use XMLHttpRequest or fetch (
https://developers.google.com/web/updates/2015/03/introduction-to-fetch?hl=en)
if you don't mind to use a polyfill for non-supported browser (maybe at
that point all the evergreen browsers already support it natively) or use a
higher abstraction (like RestyGWT, etc)

Post by Ed
@jens
Is there any downside to Request Builder? Possible deprecation in GWT 3.0?
Best Regards
Ed

Post by Ed
Thanks Jens, Great response, gives our devs something to learn.

Post by Ed
1. GWT.create
<generate-with>: Annotation processors
<replace-with>: Dagger 2.x + AutoFactory (assisted inject) for injection
and System.getProperty() to build the Dagger dependency graph based on your
deferred binding properties.
For Dagger I created a pull request that generates a dagger-gwt artifact
including a GWT module: https://github.com/google/dagger/pull/119
2. RPC
Anything that generates code in a way that is compatible with annotation
processors so they can migrate to APT in the future. I guess you need to
ask maintainers of your preferred alternatives and hear what they say.
Regardless of GWT 3.0 I would never really use GWT-RPC again because things
like RPC policy files, "do not use interfaces in serializable types" and
that it is hard to consume outside of GWT are annoying.
-- J.
--
You received this message because you are subscribed to the Google
Groups "Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send
<javascript:>.
<javascript:>.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

[Ed]

@jens @umit

Thank you very much for this insight.

Best Regards

Ed

Post by Ümit Seren
If possible, go Restful. it makes it much easier to later add non-GWT
clients and also forces you to think about your domain model as resources
(might lead to a clean API).
I guess once Elemental 2.0 is released (AFAIK along the lines with GWT
3.0) you could either use XMLHttpRequest or fetch (
https://developers.google.com/web/updates/2015/03/introduction-to-fetch?hl=en)
if you don't mind to use a polyfill for non-supported browser (maybe at
that point all the evergreen browsers already support it natively) or use a
higher abstraction (like RestyGWT, etc)

Post by Ed
@jens
Is there any downside to Request Builder? Possible deprecation in GWT 3.0?
Best Regards
Ed

Post by Ed
Thanks Jens, Great response, gives our devs something to learn.

Post by Ed
1. GWT.create
<generate-with>: Annotation processors
<replace-with>: Dagger 2.x + AutoFactory (assisted inject) for
injection and System.getProperty() to build the Dagger dependency graph
based on your deferred binding properties.
For Dagger I created a pull request that generates a dagger-gwt
https://github.com/google/dagger/pull/119
2. RPC
Anything that generates code in a way that is compatible with
annotation processors so they can migrate to APT in the future. I guess you
need to ask maintainers of your preferred alternatives and hear what they
say. Regardless of GWT 3.0 I would never really use GWT-RPC again because
things like RPC policy files, "do not use interfaces in serializable types"
and that it is hard to consume outside of GWT are annoying.
-- J.
--
You received this message because you are subscribed to the Google
Groups "Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

--

You received this message because you are subscribed to the Google Groups
"Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

[P.G.Taboada]

I cannot disagree more. Restful, as far as I understand, does not replace
gwt-rpc as it does not provide polymorphism. It might be an issue with the
current implementations I had a look - can someone tell me some
implementation that can handle object graphs and polymorphism as gwt-rpc
does?

There are some folks (like me), that stick to the command pattern once
introduced by ray in his google io talk.
I am not giving away batching, caching, versioning of my services that
easy...

My code is doing

<A extends Action<R>, R extends Result>
void execute(A action, AsyncCallback<R> callback);


all over the place. It is a piece of cake for to change the communication
layer, as long as I can send Actions through it.

is dagger + ... an alternative to gwt-rpc?

Post by Ümit Seren
If possible, go Restful. it makes it much easier to later add non-GWT
clients and also forces you to think about your domain model as resources
(might lead to a clean API).
I guess once Elemental 2.0 is released (AFAIK along the lines with GWT
3.0) you could either use XMLHttpRequest or fetch (
https://developers.google.com/web/updates/2015/03/introduction-to-fetch?hl=en)
if you don't mind to use a polyfill for non-supported browser (maybe at
that point all the evergreen browsers already support it natively) or use a
higher abstraction (like RestyGWT, etc)

Post by Ed
@jens
Is there any downside to Request Builder? Possible deprecation in GWT 3.0?
Best Regards
Ed

Post by Ed
Thanks Jens, Great response, gives our devs something to learn.

Post by Ed
1. GWT.create
<generate-with>: Annotation processors
<replace-with>: Dagger 2.x + AutoFactory (assisted inject) for
injection and System.getProperty() to build the Dagger dependency graph
based on your deferred binding properties.
For Dagger I created a pull request that generates a dagger-gwt
https://github.com/google/dagger/pull/119
2. RPC
Anything that generates code in a way that is compatible with
annotation processors so they can migrate to APT in the future. I guess you
need to ask maintainers of your preferred alternatives and hear what they
say. Regardless of GWT 3.0 I would never really use GWT-RPC again because
things like RPC policy files, "do not use interfaces in serializable types"
and that it is hard to consume outside of GWT are annoying.
-- J.
--
You received this message because you are subscribed to the Google
Groups "Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

[Lars]

Both gwt-jackson (https://github.com/nmorel/gwt-jackson/wiki/Type-support)
and restygwt (resty-gwt.github.io/documentation/restygwt-user-guide.html)
supports polymorphism (and gwt-jackson in addition generics)!

gwt-rpc is nice at the beginning (fast learning curve), but hurts later on
- because it's mixes data(-structure) with implementation :-(

Post by P.G.Taboada
I cannot disagree more. Restful, as far as I understand, does not replace
gwt-rpc as it does not provide polymorphism. It might be an issue with the
current implementations I had a look - can someone tell me some
implementation that can handle object graphs and polymorphism as gwt-rpc
does?
There are some folks (like me), that stick to the command pattern once
introduced by ray in his google io talk.
I am not giving away batching, caching, versioning of my services that
easy...
My code is doing
<A extends Action<R>, R extends Result>
void execute(A action, AsyncCallback<R> callback);
all over the place. It is a piece of cake for to change the communication
layer, as long as I can send Actions through it.
is dagger + ... an alternative to gwt-rpc?

Post by Ümit Seren
If possible, go Restful. it makes it much easier to later add non-GWT
clients and also forces you to think about your domain model as resources
(might lead to a clean API).
I guess once Elemental 2.0 is released (AFAIK along the lines with GWT
3.0) you could either use XMLHttpRequest or fetch (
https://developers.google.com/web/updates/2015/03/introduction-to-fetch?hl=en)
if you don't mind to use a polyfill for non-supported browser (maybe at
that point all the evergreen browsers already support it natively) or use a
higher abstraction (like RestyGWT, etc)

Post by Ed
@jens
Is there any downside to Request Builder? Possible deprecation in GWT 3.0?
Best Regards
Ed

Post by Ed
Thanks Jens, Great response, gives our devs something to learn.

Post by Ed
1. GWT.create
<generate-with>: Annotation processors
<replace-with>: Dagger 2.x + AutoFactory (assisted inject) for
injection and System.getProperty() to build the Dagger dependency graph
based on your deferred binding properties.
For Dagger I created a pull request that generates a dagger-gwt
https://github.com/google/dagger/pull/119
2. RPC
Anything that generates code in a way that is compatible with
annotation processors so they can migrate to APT in the future. I guess you
need to ask maintainers of your preferred alternatives and hear what they
say. Regardless of GWT 3.0 I would never really use GWT-RPC again because
things like RPC policy files, "do not use interfaces in serializable types"
and that it is hard to consume outside of GWT are annoying.
-- J.
--
You received this message because you are subscribed to the Google
Groups "Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

[Jens]

Post by P.G.Taboada
is dagger + ... an alternative to gwt-rpc?

Dagger is an injection library like google-gin with the difference that it
uses annotation processors instead of GWT.create(). It has nothing to do
with gwt-rpc.

[Jurjen van Geenen]

+1: RPC is one of GWT's strong suits. Haven't seen another web-oriented
(de-)serialization mechanism that handles polymophism, generics and bidi
relations without config or pain. Doesn't litter your domain classes with
non-standard annotations or dependencies. AnyGWT 3.0 alternative should be
just as good.

Post by P.G.Taboada
I cannot disagree more. Restful, as far as I understand, does not replace
gwt-rpc as it does not provide polymorphism. It might be an issue with the
current implementations I had a look - can someone tell me some
implementation that can handle object graphs and polymorphism as gwt-rpc
does?
There are some folks (like me), that stick to the command pattern once
introduced by ray in his google io talk.
I am not giving away batching, caching, versioning of my services that
easy...
My code is doing
<A extends Action<R>, R extends Result>
void execute(A action, AsyncCallback<R> callback);
all over the place. It is a piece of cake for to change the communication
layer, as long as I can send Actions through it.
is dagger + ... an alternative to gwt-rpc?

Post by Ümit Seren
If possible, go Restful. it makes it much easier to later add non-GWT
clients and also forces you to think about your domain model as resources
(might lead to a clean API).
I guess once Elemental 2.0 is released (AFAIK along the lines with GWT
3.0) you could either use XMLHttpRequest or fetch (
https://developers.google.com/web/updates/2015/03/introduction-to-fetch?hl=en)
if you don't mind to use a polyfill for non-supported browser (maybe at
that point all the evergreen browsers already support it natively) or use a
higher abstraction (like RestyGWT, etc)

Post by Ed
@jens
Is there any downside to Request Builder? Possible deprecation in GWT 3.0?
Best Regards
Ed

Post by Ed
Thanks Jens, Great response, gives our devs something to learn.

Post by Ed
1. GWT.create
<generate-with>: Annotation processors
<replace-with>: Dagger 2.x + AutoFactory (assisted inject) for
injection and System.getProperty() to build the Dagger dependency graph
based on your deferred binding properties.
For Dagger I created a pull request that generates a dagger-gwt
https://github.com/google/dagger/pull/119
2. RPC
Anything that generates code in a way that is compatible with
annotation processors so they can migrate to APT in the future. I guess you
need to ask maintainers of your preferred alternatives and hear what they
say. Regardless of GWT 3.0 I would never really use GWT-RPC again because
things like RPC policy files, "do not use interfaces in serializable types"
and that it is hard to consume outside of GWT are annoying.
-- J.
--
You received this message because you are subscribed to the Google
Groups "Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

[marian lux]

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?

[Jens]

Post by marian lux
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 topic from the GWT 2015 meet up
at https://www.youtube.com/playlist?list=PL1yReUCGwGvrqscLu1EAyYRPrr0ceEHLE

Slides are linked in the playlist description.

-- J.

[Ed]

It was process but we ported everything to the low level
RequestBuildner.and json. Now we have just one timer in the UI a huge
reduction from the async nature of RPC.

In our situation we render everything out of a DataDictionary on the
server side and use a Frame for the results,

The GUI is pure GWT. Size of application rose from 182k to 1.5 meg
including split points. Without profiling it is noticeably faster without
RPC. I am guessing that there are less instantiations of classes on server
and UI.

All in all, we are ready for GWT 3.0 and look forward to the stable 2.8.

Thanks for all your help!

Best Regards

Post by marian lux
Where can I read that GWT RPC and widget system will be dropped with GWT

Post by marian lux
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 topic from the GWT 2015 meet up at
https://www.youtube.com/playlist?list=PL1yReUCGwGvrqscLu1EAyYRPrr0ceEHLE
Slides are linked in the playlist description.
-- J.
--
You received this message because you are subscribed to the Google Groups
"Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

[marian lux]

Thank you for your answer Jens. So much GWT solutions build on widget system so I think there will be a port/solution (thinking about the new GWT Material Project which was startend a view months ago...).

@Ed: so you use a REST service on backend? Seems also for us a good solution but debugging inside IDE will be lost.

It was process but we ported everything to  the low level RequestBuildner.and json. Now we have just one timer in the UI a huge reduction from the async nature of RPC.
 In our situation we render everything out of a DataDictionary on the server side and use a Frame for the results,
The GUI is pure GWT. Size of application rose from 182k to 1.5 meg including split points.  Without profiling it is noticeably faster without RPC.  I am guessing that there are less instantiations of classes on server and UI.
All in all, we are ready for GWT 3.0 and look forward to the stable 2.8.
Thanks for all your help!
Best Regards
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 topic from the GWT 2015 meet up at https://www.youtube.com/playlist?list=PL1yReUCGwGvrqscLu1EAyYRPrr0ceEHLE
Slides are linked in the playlist description.
-- J.
--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

[salk31]

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

Post by marian lux
Where can I read that GWT RPC and widget system will be dropped with GWT

Post by marian lux
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 topic from the GWT 2015 meet up at
https://www.youtube.com/playlist?list=PL1yReUCGwGvrqscLu1EAyYRPrr0ceEHLE
Slides are linked in the playlist description.
-- J.

[Thomas Broyer]

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.

Post by salk31
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

Post by marian lux
Where can I read that GWT RPC and widget system will be dropped with GWT

Post by marian lux
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 topic from the GWT 2015 meet up at
https://www.youtube.com/playlist?list=PL1yReUCGwGvrqscLu1EAyYRPrr0ceEHLE
Slides are linked in the playlist description.
-- J.

[salk31]

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.

Post by Thomas Broyer
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.

Post by salk31
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

Post by marian lux
Where can I read that GWT RPC and widget system will be dropped with GWT

Post by marian lux
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 topic from the GWT 2015 meet up at
https://www.youtube.com/playlist?list=PL1yReUCGwGvrqscLu1EAyYRPrr0ceEHLE
Slides are linked in the playlist description.
-- J.

[steve Zara]

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.

Post by salk31
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

Post by Thomas Broyer
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.

Post by salk31
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

Post by marian lux
Where can I read that GWT RPC and widget system will be dropped with

Post by marian lux
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 topic from the GWT 2015 meet up at
https://www.youtube.com/playlist?list=PL1yReUCGwGvrqscLu1EAyYRPrr0ceEHLE
Slides are linked in the playlist description.
-- J.

[salk31]

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?

Post by steve Zara
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.

Post by salk31
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

Post by Thomas Broyer
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.

Post by salk31
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

Post by marian lux
Where can I read that GWT RPC and widget system will be dropped with

Post by marian lux
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 topic from the GWT 2015 meet up at
https://www.youtube.com/playlist?list=PL1yReUCGwGvrqscLu1EAyYRPrr0ceEHLE
Slides are linked in the playlist description.
-- J.

['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.

Post by salk31
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?

Post by steve Zara
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.

Post by salk31
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

Post by Thomas Broyer
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.

Post by salk31
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

Post by marian lux
Where can I read that GWT RPC and widget system will be dropped with

Post by marian lux
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 topic from the GWT 2015 meet up at
https://www.youtube.com/playlist?list=PL1yReUCGwGvrqscLu1EAyYRPrr0ceEHLE
Slides are linked in the playlist description.
-- J.

--

You received this message because you are subscribed to a topic in the
Google Groups "GWT Users" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/google-web-toolkit/SjvCh37nahw/unsubscribe
.
To unsubscribe from this group and all its topics, send an email to
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

[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?

Post by '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.

Post by salk31
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?

Post by steve Zara
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.

Post by salk31
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

Post by Thomas Broyer
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.

Post by salk31
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

Post by marian lux
Where can I read that GWT RPC and widget system will be dropped with

Post by marian lux
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 topic from the GWT 2015 meet up at
https://www.youtube.com/playlist?list=PL1yReUCGwGvrqscLu1EAyYRPrr0ceEHLE
Slides are linked in the playlist description.
-- J.

--

You received this message because you are subscribed to a topic in the
Google Groups "GWT Users" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/google-web-toolkit/SjvCh37nahw/unsubscribe
.
To unsubscribe from this group and all its topics, send an email to
<javascript:>.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

[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.

Post by salk31
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?

Post by steve Zara
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.

Post by salk31
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

Post by Thomas Broyer
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.

Post by salk31
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

Post by marian lux
Where can I read that GWT RPC and widget system will be dropped with

Post by marian lux
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 topic from the GWT 2015 meet up at
https://www.youtube.com/playlist?list=PL1yReUCGwGvrqscLu1EAyYRPrr0ceEHLE
Slides are linked in the playlist description.
-- 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
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

[Ü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.

Post by 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.

Post by salk31
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?

Post by steve Zara
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.

Post by salk31
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

Post by Thomas Broyer
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.

Post by salk31
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

Post by marian lux
Where can I read that GWT RPC and widget system will be dropped with

Post by marian lux
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 topic from the GWT 2015 meet up at
https://www.youtube.com/playlist?list=PL1yReUCGwGvrqscLu1EAyYRPrr0ceEHLE
Slides are linked in the playlist description.
-- 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
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 a topic in the
Google Groups "GWT Users" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/google-web-toolkit/SjvCh37nahw/unsubscribe
.
To unsubscribe from this group and all its topics, send an email to
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

[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.

[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.

Post by 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.

[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.

Post by 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.

Post by 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
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

[Jens]

Post by salk31
* 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.

Post by salk31
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.

[Thomas Broyer]

Post by Jens

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

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.)