Hi guys, I've had a discussion with Roy about GWT vs. Java plans, he asked me to share this information, so here we go. GWT 2.6 ======= - patch pending merge: http://gerrit.ovirt.org/#/c/32135/ - support for Java 7 language syntax like <> operator etc. - once patch ^^ is merged, we can consolidate Java language compliance for whole Engine -> both frontend and backend can use Java 7 (yey!) GWT 2.7 ======= - planned support for *only* Java 8 language syntax like lambdas etc. but *without* emulating new Java 8 APIs like streams etc. (Java 8 API emulation should come in GWT 3.0) Likely, GWT 2.7 will remove GWT deRPC implementation on which we currently rely on. (@Martin, can you please share details?) This means that until we move UI to REST API, we can't upgrade post GWT 2.6, so this will put more pressure to work on oVirtJS project in consequence. GWT 3.0 ======= - ETA early next year? - planned to fully support Java 8 -> both language and APIs - one of key highlights is better integration with JavaScript, which fits the scenario where GWT "application" is one module that's part of bigger application (hybrid approach) Regards, Vojtech
----- Original Message -----
From: "Vojtech Szocs" <vszocs@redhat.com> To: devel@ovirt.org Sent: Friday, October 3, 2014 4:29:15 PM Subject: [ovirt-devel] GWT vs. Java
Hi guys,
I've had a discussion with Roy about GWT vs. Java plans, he asked me to share this information, so here we go.
GWT 2.6 ======= - patch pending merge: http://gerrit.ovirt.org/#/c/32135/ - support for Java 7 language syntax like <> operator etc. - once patch ^^ is merged, we can consolidate Java language compliance for whole Engine -> both frontend and backend can use Java 7 (yey!)
GWT 2.7 ======= - planned support for *only* Java 8 language syntax like lambdas etc. but *without* emulating new Java 8 APIs like streams etc. (Java 8 API emulation should come in GWT 3.0)
Likely, GWT 2.7 will remove GWT deRPC implementation on which we currently rely on. (@Martin, can you please share details?)
This means that until we move UI to REST API, we can't upgrade post GWT 2.6, so this will put more pressure to work on oVirtJS project in consequence.
GWT 3.0 ======= - ETA early next year? - planned to fully support Java 8 -> both language and APIs - one of key highlights is better integration with JavaScript, which fits the scenario where GWT "application" is one module that's part of bigger application (hybrid approach)
Thanks for sharing with us! Can you please elabroate more on this hybrid approach? Cheers, Yair
Regards, Vojtech _______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
----- Original Message -----
From: "Yair Zaslavsky" <yzaslavs@redhat.com> To: "Vojtech Szocs" <vszocs@redhat.com> Cc: devel@ovirt.org Sent: Friday, October 3, 2014 4:37:36 PM Subject: Re: [ovirt-devel] GWT vs. Java
----- Original Message -----
From: "Vojtech Szocs" <vszocs@redhat.com> To: devel@ovirt.org Sent: Friday, October 3, 2014 4:29:15 PM Subject: [ovirt-devel] GWT vs. Java
Hi guys,
I've had a discussion with Roy about GWT vs. Java plans, he asked me to share this information, so here we go.
GWT 2.6 ======= - patch pending merge: http://gerrit.ovirt.org/#/c/32135/ - support for Java 7 language syntax like <> operator etc. - once patch ^^ is merged, we can consolidate Java language compliance for whole Engine -> both frontend and backend can use Java 7 (yey!)
GWT 2.7 ======= - planned support for *only* Java 8 language syntax like lambdas etc. but *without* emulating new Java 8 APIs like streams etc. (Java 8 API emulation should come in GWT 3.0)
Likely, GWT 2.7 will remove GWT deRPC implementation on which we currently rely on. (@Martin, can you please share details?)
This means that until we move UI to REST API, we can't upgrade post GWT 2.6, so this will put more pressure to work on oVirtJS project in consequence.
GWT 3.0 ======= - ETA early next year? - planned to fully support Java 8 -> both language and APIs - one of key highlights is better integration with JavaScript, which fits the scenario where GWT "application" is one module that's part of bigger application (hybrid approach)
Thanks for sharing with us! Can you please elabroate more on this hybrid approach?
With "hybrid approach" I meant a situation where the web application consists of distinct modules, each module providing some functionality. The common base technology for all modules, as well as for the module infra itself, is JavaScript. Each module can export APIs that other modules can consume. The whole complexity of web application is broken by dividing its logical parts into modules. Each module can be built (and packaged too) as a separate project. For a long time, I felt that GWT lived in its "own" world, with vast majority of GWT use cases = GWT to implement the whole web application. GWT 3.0 should provide better JavaScript integration, so GWT can also more easily fill the role of a "module" as opposed to the traditional role of "the whole application".
Cheers, Yair
Regards, Vojtech _______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
On 10/03/2014 06:19 PM, Vojtech Szocs wrote:
----- Original Message -----
From: "Yair Zaslavsky" <yzaslavs@redhat.com> To: "Vojtech Szocs" <vszocs@redhat.com> Cc: devel@ovirt.org Sent: Friday, October 3, 2014 4:37:36 PM Subject: Re: [ovirt-devel] GWT vs. Java
----- Original Message -----
From: "Vojtech Szocs" <vszocs@redhat.com> To: devel@ovirt.org Sent: Friday, October 3, 2014 4:29:15 PM Subject: [ovirt-devel] GWT vs. Java
Hi guys,
I've had a discussion with Roy about GWT vs. Java plans, he asked me to share this information, so here we go.
GWT 2.6 ======= - patch pending merge: http://gerrit.ovirt.org/#/c/32135/ - support for Java 7 language syntax like <> operator etc. - once patch ^^ is merged, we can consolidate Java language compliance for whole Engine -> both frontend and backend can use Java 7 (yey!)
Good news - @amureini prepare the nose of the Animal Sniffer :) @Vojtech keep us posted so we'll bump the language version of common Curious to know, does GWT have a WebSockets module for 2 way communication with the backend and are we planning to use it?
GWT 2.7 ======= - planned support for *only* Java 8 language syntax like lambdas etc. but *without* emulating new Java 8 APIs like streams etc. (Java 8 API emulation should come in GWT 3.0)
Likely, GWT 2.7 will remove GWT deRPC implementation on which we currently rely on. (@Martin, can you please share details?)
This means that until we move UI to REST API, we can't upgrade post GWT 2.6, so this will put more pressure to work on oVirtJS project in consequence.
GWT 3.0 ======= - ETA early next year? - planned to fully support Java 8 -> both language and APIs - one of key highlights is better integration with JavaScript, which fits the scenario where GWT "application" is one module that's part of bigger application (hybrid approach) Thanks for sharing with us! Can you please elabroate more on this hybrid approach? With "hybrid approach" I meant a situation where the web application consists of distinct modules, each module providing some functionality.
The common base technology for all modules, as well as for the module infra itself, is JavaScript. Each module can export APIs that other modules can consume. The whole complexity of web application is broken by dividing its logical parts into modules. Each module can be built (and packaged too) as a separate project.
For a long time, I felt that GWT lived in its "own" world, with vast majority of GWT use cases = GWT to implement the whole web application.
GWT 3.0 should provide better JavaScript integration, so GWT can also more easily fill the role of a "module" as opposed to the traditional role of "the whole application".
Does this mean you're thinking of replacing some of the frontend parts with plain javascript and html and make them play with the GWT modules?
Cheers, Yair
Regards, Vojtech _______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
----- Original Message -----
From: "Roy Golan" <rgolan@redhat.com> To: devel@ovirt.org Sent: Sunday, October 5, 2014 9:16:20 AM Subject: Re: [ovirt-devel] GWT vs. Java
On 10/03/2014 06:19 PM, Vojtech Szocs wrote:
----- Original Message -----
From: "Yair Zaslavsky" <yzaslavs@redhat.com> To: "Vojtech Szocs" <vszocs@redhat.com> Cc: devel@ovirt.org Sent: Friday, October 3, 2014 4:37:36 PM Subject: Re: [ovirt-devel] GWT vs. Java
----- Original Message -----
From: "Vojtech Szocs" <vszocs@redhat.com> To: devel@ovirt.org Sent: Friday, October 3, 2014 4:29:15 PM Subject: [ovirt-devel] GWT vs. Java
Hi guys,
I've had a discussion with Roy about GWT vs. Java plans, he asked me to share this information, so here we go.
GWT 2.6 ======= - patch pending merge: http://gerrit.ovirt.org/#/c/32135/ - support for Java 7 language syntax like <> operator etc. - once patch ^^ is merged, we can consolidate Java language compliance for whole Engine -> both frontend and backend can use Java 7 (yey!)
Good news - @amureini prepare the nose of the Animal Sniffer :)
:D
@Vojtech keep us posted so we'll bump the language version of common
GWT 2.6 upgrade patch will get merged once we do some more GUI tests on IE browser. There was also an issue with bad checksum for one of Maven (POM) artifacts, I'll contact the JBoss guy..
Curious to know, does GWT have a WebSockets module for 2 way communication with the backend and are we planning to use it?
Good question. AFAIK, GWT doesn't have "official" API for websocket but there are 3rd party libs that could be used, for example: https://github.com/sksamuel/gwt-websockets https://github.com/sockjs/sockjs-client But moving GUI to REST API is a big task that's ahead of us now, 2-way client/server communication is something we could do after that (distant future). I'm all for websockets, btw :)
GWT 2.7 ======= - planned support for *only* Java 8 language syntax like lambdas etc. but *without* emulating new Java 8 APIs like streams etc. (Java 8 API emulation should come in GWT 3.0)
Likely, GWT 2.7 will remove GWT deRPC implementation on which we currently rely on. (@Martin, can you please share details?)
This means that until we move UI to REST API, we can't upgrade post GWT 2.6, so this will put more pressure to work on oVirtJS project in consequence.
GWT 3.0 ======= - ETA early next year? - planned to fully support Java 8 -> both language and APIs - one of key highlights is better integration with JavaScript, which fits the scenario where GWT "application" is one module that's part of bigger application (hybrid approach) Thanks for sharing with us! Can you please elabroate more on this hybrid approach? With "hybrid approach" I meant a situation where the web application consists of distinct modules, each module providing some functionality.
The common base technology for all modules, as well as for the module infra itself, is JavaScript. Each module can export APIs that other modules can consume. The whole complexity of web application is broken by dividing its logical parts into modules. Each module can be built (and packaged too) as a separate project.
For a long time, I felt that GWT lived in its "own" world, with vast majority of GWT use cases = GWT to implement the whole web application.
GWT 3.0 should provide better JavaScript integration, so GWT can also more easily fill the role of a "module" as opposed to the traditional role of "the whole application".
Does this mean you're thinking of replacing some of the frontend parts with plain javascript and html and make them play with the GWT modules?
That's my secret plan, now it's not secret anymore :D Exactly as you wrote, I was thinking of modularizing the whole frontend with JavaScript language as the common base between all modules. Some modules could be implemented in JavaScript, some could still use GWT.
Cheers, Yair
Regards, Vojtech _______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
----- Original Message -----
From: "Vojtech Szocs" <vszocs@redhat.com> To: "Roy Golan" <rgolan@redhat.com> Cc: devel@ovirt.org Sent: Monday, October 6, 2014 5:45:55 PM Subject: Re: [ovirt-devel] GWT vs. Java
----- Original Message -----
From: "Roy Golan" <rgolan@redhat.com> To: devel@ovirt.org Sent: Sunday, October 5, 2014 9:16:20 AM Subject: Re: [ovirt-devel] GWT vs. Java
On 10/03/2014 06:19 PM, Vojtech Szocs wrote:
----- Original Message -----
From: "Yair Zaslavsky" <yzaslavs@redhat.com> To: "Vojtech Szocs" <vszocs@redhat.com> Cc: devel@ovirt.org Sent: Friday, October 3, 2014 4:37:36 PM Subject: Re: [ovirt-devel] GWT vs. Java
----- Original Message -----
From: "Vojtech Szocs" <vszocs@redhat.com> To: devel@ovirt.org Sent: Friday, October 3, 2014 4:29:15 PM Subject: [ovirt-devel] GWT vs. Java
Hi guys,
I've had a discussion with Roy about GWT vs. Java plans, he asked me to share this information, so here we go.
GWT 2.6 ======= - patch pending merge: http://gerrit.ovirt.org/#/c/32135/ - support for Java 7 language syntax like <> operator etc. - once patch ^^ is merged, we can consolidate Java language compliance for whole Engine -> both frontend and backend can use Java 7 (yey!)
Good news - @amureini prepare the nose of the Animal Sniffer :)
:D
@Vojtech keep us posted so we'll bump the language version of common
GWT 2.6 upgrade patch will get merged once we do some more GUI tests on IE browser. There was also an issue with bad checksum for one of Maven (POM) artifacts, I'll contact the JBoss guy..
Curious to know, does GWT have a WebSockets module for 2 way communication with the backend and are we planning to use it?
Good question. AFAIK, GWT doesn't have "official" API for websocket but there are 3rd party libs that could be used, for example:
https://github.com/sksamuel/gwt-websockets https://github.com/sockjs/sockjs-client
But moving GUI to REST API is a big task that's ahead of us now, 2-way client/server communication is something we could do after that (distant future). I'm all for websockets, btw :)
GWT 2.7 ======= - planned support for *only* Java 8 language syntax like lambdas etc. but *without* emulating new Java 8 APIs like streams etc. (Java 8 API emulation should come in GWT 3.0)
Likely, GWT 2.7 will remove GWT deRPC implementation on which we currently rely on. (@Martin, can you please share details?)
This means that until we move UI to REST API, we can't upgrade post GWT 2.6, so this will put more pressure to work on oVirtJS project in consequence.
GWT 3.0 ======= - ETA early next year? - planned to fully support Java 8 -> both language and APIs - one of key highlights is better integration with JavaScript, which fits the scenario where GWT "application" is one module that's part of bigger application (hybrid approach) Thanks for sharing with us! Can you please elabroate more on this hybrid approach? With "hybrid approach" I meant a situation where the web application consists of distinct modules, each module providing some functionality.
The common base technology for all modules, as well as for the module infra itself, is JavaScript. Each module can export APIs that other modules can consume. The whole complexity of web application is broken by dividing its logical parts into modules. Each module can be built (and packaged too) as a separate project.
For a long time, I felt that GWT lived in its "own" world, with vast majority of GWT use cases = GWT to implement the whole web application.
GWT 3.0 should provide better JavaScript integration, so GWT can also more easily fill the role of a "module" as opposed to the traditional role of "the whole application".
Does this mean you're thinking of replacing some of the frontend parts with plain javascript and html and make them play with the GWT modules?
That's my secret plan, now it's not secret anymore :D
Exactly as you wrote, I was thinking of modularizing the whole frontend with JavaScript language as the common base between all modules. Some modules could be implemented in JavaScript, some could still use GWT.
Awesome! Correct me if I'm wrong but currently JS frameworks (Angular and such) are more supported than GWT and have wider community.
Cheers, Yair
Regards, Vojtech _______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
----- Original Message -----
From: "Yair Zaslavsky" <yzaslavs@redhat.com> To: "Vojtech Szocs" <vszocs@redhat.com> Cc: "Roy Golan" <rgolan@redhat.com>, devel@ovirt.org Sent: Tuesday, October 7, 2014 2:01:13 AM Subject: Re: [ovirt-devel] GWT vs. Java
----- Original Message -----
From: "Vojtech Szocs" <vszocs@redhat.com> To: "Roy Golan" <rgolan@redhat.com> Cc: devel@ovirt.org Sent: Monday, October 6, 2014 5:45:55 PM Subject: Re: [ovirt-devel] GWT vs. Java
----- Original Message -----
From: "Roy Golan" <rgolan@redhat.com> To: devel@ovirt.org Sent: Sunday, October 5, 2014 9:16:20 AM Subject: Re: [ovirt-devel] GWT vs. Java
On 10/03/2014 06:19 PM, Vojtech Szocs wrote:
----- Original Message -----
From: "Yair Zaslavsky" <yzaslavs@redhat.com> To: "Vojtech Szocs" <vszocs@redhat.com> Cc: devel@ovirt.org Sent: Friday, October 3, 2014 4:37:36 PM Subject: Re: [ovirt-devel] GWT vs. Java
----- Original Message -----
From: "Vojtech Szocs" <vszocs@redhat.com> To: devel@ovirt.org Sent: Friday, October 3, 2014 4:29:15 PM Subject: [ovirt-devel] GWT vs. Java
Hi guys,
I've had a discussion with Roy about GWT vs. Java plans, he asked me to share this information, so here we go.
GWT 2.6 ======= - patch pending merge: http://gerrit.ovirt.org/#/c/32135/ - support for Java 7 language syntax like <> operator etc. - once patch ^^ is merged, we can consolidate Java language compliance for whole Engine -> both frontend and backend can use Java 7 (yey!)
Good news - @amureini prepare the nose of the Animal Sniffer :)
:D
@Vojtech keep us posted so we'll bump the language version of common
GWT 2.6 upgrade patch will get merged once we do some more GUI tests on IE browser. There was also an issue with bad checksum for one of Maven (POM) artifacts, I'll contact the JBoss guy..
Curious to know, does GWT have a WebSockets module for 2 way communication with the backend and are we planning to use it?
Good question. AFAIK, GWT doesn't have "official" API for websocket but there are 3rd party libs that could be used, for example:
https://github.com/sksamuel/gwt-websockets https://github.com/sockjs/sockjs-client
But moving GUI to REST API is a big task that's ahead of us now, 2-way client/server communication is something we could do after that (distant future). I'm all for websockets, btw :)
GWT 2.7 ======= - planned support for *only* Java 8 language syntax like lambdas etc. but *without* emulating new Java 8 APIs like streams etc. (Java 8 API emulation should come in GWT 3.0)
Likely, GWT 2.7 will remove GWT deRPC implementation on which we currently rely on. (@Martin, can you please share details?)
This means that until we move UI to REST API, we can't upgrade post GWT 2.6, so this will put more pressure to work on oVirtJS project in consequence.
GWT 3.0 ======= - ETA early next year? - planned to fully support Java 8 -> both language and APIs - one of key highlights is better integration with JavaScript, which fits the scenario where GWT "application" is one module that's part of bigger application (hybrid approach) Thanks for sharing with us! Can you please elabroate more on this hybrid approach? With "hybrid approach" I meant a situation where the web application consists of distinct modules, each module providing some functionality.
The common base technology for all modules, as well as for the module infra itself, is JavaScript. Each module can export APIs that other modules can consume. The whole complexity of web application is broken by dividing its logical parts into modules. Each module can be built (and packaged too) as a separate project.
For a long time, I felt that GWT lived in its "own" world, with vast majority of GWT use cases = GWT to implement the whole web application.
GWT 3.0 should provide better JavaScript integration, so GWT can also more easily fill the role of a "module" as opposed to the traditional role of "the whole application".
Does this mean you're thinking of replacing some of the frontend parts with plain javascript and html and make them play with the GWT modules?
That's my secret plan, now it's not secret anymore :D
Exactly as you wrote, I was thinking of modularizing the whole frontend with JavaScript language as the common base between all modules. Some modules could be implemented in JavaScript, some could still use GWT.
Awesome! Correct me if I'm wrong but currently JS frameworks (Angular and such) are more supported than GWT and have wider community.
Well, GWT was born around 2006 and is now long past its "hype" period, but it's definitely not dead (as many people think). For those of you curious about GWT future, see [1]. [1] https://www.youtube.com/watch?v=-uJjh4DDW2s&index=2&list=PL1yReUCGwGvoJimc2mUBDQCsdvV8gTwP5 With JavaScript language getting vast improvements (ES6 Harmony spec) in near future, it's clear that JavaScript is here to stay as dominant frontend language, alongside other standards like HTML and CSS. Take a look at [2], if you're interested in learning about new ES6 language features. [2] https://github.com/lukehoban/es6features The idea of modularizing oVirt UI codebase doesn't imply technology switch, it just implies breaking monolithic structure into smaller pieces with well-defined API to orchestrate them. This should bring many positive side effects, such as easier maintenance (of smaller pieces rather than whole structure), better tech-switch potential (one piece at time rather than whole structure) and also for those wanting to extend GUI with whole new features, remove "must know GWT" barrier. Anyway, this is idea for the long term :)
Cheers, Yair
Regards, Vojtech _______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
----- Original Message -----
From: "Vojtech Szocs" <vszocs@redhat.com> To: devel@ovirt.org Cc: "Einav Cohen" <ecohen@redhat.com>, "Roy Golan" <rgolan@redhat.com>, "Martin Betak" <mbetak@redhat.com> Sent: Friday, October 3, 2014 3:29:15 PM Subject: GWT vs. Java
Hi guys,
I've had a discussion with Roy about GWT vs. Java plans, he asked me to share this information, so here we go.
GWT 2.6 ======= - patch pending merge: http://gerrit.ovirt.org/#/c/32135/ - support for Java 7 language syntax like <> operator etc. - once patch ^^ is merged, we can consolidate Java language compliance for whole Engine -> both frontend and backend can use Java 7 (yey!)
GWT 2.7 ======= - planned support for *only* Java 8 language syntax like lambdas etc. but *without* emulating new Java 8 APIs like streams etc. (Java 8 API emulation should come in GWT 3.0)
Likely, GWT 2.7 will remove GWT deRPC implementation on which we currently rely on. (@Martin, can you please share details?)
Following the GWT source code, the support for deprecated deRPC was removed in commit f18e4e23898d3e090e0fae1fed2abd97e78b62e7 on master branch which will be almost certainly included in the 2.7 release.
This means that until we move UI to REST API, we can't upgrade post GWT 2.6, so this will put more pressure to work on oVirtJS project in consequence.
GWT 3.0 ======= - ETA early next year? - planned to fully support Java 8 -> both language and APIs - one of key highlights is better integration with JavaScript, which fits the scenario where GWT "application" is one module that's part of bigger application (hybrid approach)
Regards, Vojtech
----- Original Message -----
From: "Martin Betak" <mbetak@redhat.com> To: "Vojtech Szocs" <vszocs@redhat.com> Cc: devel@ovirt.org, "Einav Cohen" <ecohen@redhat.com>, "Roy Golan" <rgolan@redhat.com> Sent: Monday, October 6, 2014 11:36:14 AM Subject: Re: GWT vs. Java
----- Original Message -----
From: "Vojtech Szocs" <vszocs@redhat.com> To: devel@ovirt.org Cc: "Einav Cohen" <ecohen@redhat.com>, "Roy Golan" <rgolan@redhat.com>, "Martin Betak" <mbetak@redhat.com> Sent: Friday, October 3, 2014 3:29:15 PM Subject: GWT vs. Java
Hi guys,
I've had a discussion with Roy about GWT vs. Java plans, he asked me to share this information, so here we go.
GWT 2.6 ======= - patch pending merge: http://gerrit.ovirt.org/#/c/32135/ - support for Java 7 language syntax like <> operator etc. - once patch ^^ is merged, we can consolidate Java language compliance for whole Engine -> both frontend and backend can use Java 7 (yey!)
GWT 2.7 ======= - planned support for *only* Java 8 language syntax like lambdas etc. but *without* emulating new Java 8 APIs like streams etc. (Java 8 API emulation should come in GWT 3.0)
Likely, GWT 2.7 will remove GWT deRPC implementation on which we currently rely on. (@Martin, can you please share details?)
Following the GWT source code, the support for deprecated deRPC was removed in commit f18e4e23898d3e090e0fae1fed2abd97e78b62e7 on master branch which will be almost certainly included in the 2.7 release.
Indeed, direct-eval RPC aka deRPC was removed from GWT 2.7-SNAPSHOT: https://gwt.googlesource.com/gwt/+/f18e4e23898d3e090e0fae1fed2abd97e78b62e7 We'll stick with GWT 2.6 until we move UI to REST API.
This means that until we move UI to REST API, we can't upgrade post GWT 2.6, so this will put more pressure to work on oVirtJS project in consequence.
GWT 3.0 ======= - ETA early next year? - planned to fully support Java 8 -> both language and APIs - one of key highlights is better integration with JavaScript, which fits the scenario where GWT "application" is one module that's part of bigger application (hybrid approach)
Regards, Vojtech
participants (4)
-
Martin Betak -
Roy Golan -
Vojtech Szocs -
Yair Zaslavsky