The elusive J2CL

[Ivan Markov]

This time I'll bite...

J2CL has been - what? - two to three years in the making - yet, there is nothing released to the public yet (aside from a preview to a few blessed individuals).

Before someone follows up again with the usual matra that "it is not production ready yet and it will do more harm than good" or "somebody is porting the GWT widgets to J2CL as without these J2CL would be unusable" let's ask ourselves: are these statements holding any ground anymore?

Here's a situation which is very likely not typical to just us: 

We have to - like NOW - start replacing - in our app - all the dying GWT widget-set/RPC legacy with a maintained and more contemporary toolkit (React, Angular2, whatever).

(And please let's not argue over whether the GWT widget-set is still an option for any new development. For us it is not. Also let's not argue if coding against JavaScript libs with the existing GWT compiler toolchain is a viable option in the long term - it is obviously not.)

The question: shall we scrap GWT altogether and rewrite in JS/TS? Or shall we continue with Java/JSInterop?

Now, please enlighten me how we can defend the option of continuing in Java/JSInterop - even in front of ourselves - given that 3 years from the initial announcement - J2CL is still just smoke and mirrors for almost all Google outsiders?  We can't play with it to gain some confidence that it will work for us.. Also what happens if Google changes their mind and decides not to release it - say - due to legal issues? We would be stuck with an all-new Java/JSInterop code still bound to the dying compiler toolchain of GWT. Not a situation anybody wants to end up with, I guess...

[Marko Pesic]

I agree 100% with Ivan, every word he said is true. 

You can also rewrite your UI code to work with Vaadin (8 or 10 soon) and all the rest of your code (business logic, persistence, services) can stay (almost) the same as it is now in your GWT. Vaadin 10 (Flow) will be ready soon, it does not use GWT and it works with webcomponents (written in Polymer) that are the future anyway. One day when/if J2CL is ready you will most probably have ability to compile (parts or all) your Flow UI code to JS. That would probably be possible, but we will see what will happen. With Vaadin Flow you have a lot of options how to write you application e.g. you have an option to write all your UI code in Polymer if you like.

If you believe in Angular, React or TS future go with that instead. I believe that they will all change so much in the future that you will also have the same problem you are facing in this moment with GWT.

[Marko Pesic]

While waiting for our moderator (probably from USA) to wake up, here is a link with today's news about Vaadin 10: https://vaadin.com/blog/vaadin-10-beta

It explains what it is so you can decide if this is something that could be interesting for you.

Regards,

Marko

[Tony BenBrahim]

I am perfectly happy with Java/JsInterop in its current state. Sure there are some things that could be improved, but what couldn't. BTW, I have never used the GWT widgets, so my case may be different. I tried TS, Angular, etc..., and have come back to GWT with JsInterop to deal with large projects. Porting a largish Angular/Typescript project back to GWT with JsInterop, I found several bugs, because Typescript gives the illusion of types and "type checking", while GWT does real type checking.

Put me in the camp that does not care if J2CL ever comes out. I want fast compiles, especially in dev mode, anything that threatens that with a 2 step compile is of no interest to me. I am also not interested in anything that would compile differently in dev mode than in production mode in the interest of fast compiles, we have been down that road before with the legacy development mode, and when something worked in dev mode but not in prod mode, it was not fun to fix.

Anyways, I am quite sure this does not belong in this group, so let's continue the discussion in the main GWT group

--
You received this message because you are subscribed to the Google Groups "GWT Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/b99a4589-68f8-47f0-a414-80468bb90d5a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Ivan Markov]

I posted my message (OK. My rant!) here, because I wanted to get the attention of Goktug, Daniel & the rest of  the Google crew. It is a plea to change something ASAP, and if someone could, it is them.

As for the rest of your comments... don't know where to start. Most important is, you seem to imply that using J2CL will resurrect something similar to the old legacy development mode. That couldn't be farther from the truth - I suggest you check the available (scarce) info on J2CL. Also: with the new compiler toolchain we (should) have even faster compiles. "We should" because it is not available anywhere, so we can't play with it. We are currently in the 5 to 10 seconds of recompile time with GWT, and I want this down to 2 seconds. I want Webpack all the way down, also for my Java code. With HMR. With HMR + react-hot-loader. Maybe that's possible with the GWT toolchain, but I'm not holding my breath...

[Goktug Gokdogan]

The main blocker for releasing J2CL for wider audience is even basic missing functionalities around building it in open-source and seeing at least some output for your compilations. That is blocked on missing functionalities in bazel. After that we can probably finished in more timely manner.

There is still tone of work to do for a polished open source experience but at least we can give access to more people who is really interested.

--
You received this message because you are subscribed to the Google Groups "GWT Contributors" group.

To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-co...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/d9a326c6-ae1b-4577-8dd4-71d765ff547f%40googlegroups.com.

[Ivan Markov]

Goktug,

We don't want a polished experience. We want *some* experience. :)

Is there anything we can help with? BTW, I thought Bazel is already open sourced and you are already building with it? What's the roadblock there?

BTW 2: Releasing a J2CL binary would also help, as long as that's somehow legally possible.

To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscribe@googlegroups.com.

[Nándor Előd Fekete]

I am really interested. Can you sign me up?

[Alberto Mancini]

Hello, 

yes, definitely I would like to be in. 

I am really interested.

Cheers,

   Alberto. 

--

You received this message because you are subscribed to the Google Groups "GWT Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-co...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/8de62b64-4bc8-4158-80d4-b15ef688f523%40googlegroups.com.

[Goktug Gokdogan]

> There is still tone of work to do for a polished open source experience but at least we can give access to more people who is really interested.

What I meant here; is giving access *after* basic bazel stuff is finished so there will be something to play with. We don't want to give access to a broader group for something that is dead on arrival.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAGv30V%3DfWDpwQ45u9mPVuXY%3D62PJZ%2B9uxearZk5Lq_a0j2yjaA%40mail.gmail.com.

[Ivan Markov]

Goktug, sorry for being a but stubborn here, but we need a tad more visibility:

{quote}

The main blocker for releasing J2CL for wider audience is even basic missing functionalities around building it in open-source and seeing at least some output for your compilations.

{quote}

"even basic missing functionalities" sounds quite worrysome. What is the ETA for implementing these and releasing a preview? If e.g. two months, fine. If we are talking Q4/2018 or 2019, then that's a different proposition altogether. I guess, not just for us. Please don't answer with the "it's done when it is done" slogan. :) That's one of the major pains for this community imo.

Final Q: are all the legal issues for releasing in the open resolved by now? From personal experience, these might take forever to resolve.

On Thursday, March 8, 2018 at 10:51:21 PM UTC+2, Goktug Gokdogan wrote:

> There is still tone of work to do for a polished open source experience but at least we can give access to more people who is really interested.

What I meant here; is giving access *after* basic bazel stuff is finished so there will be something to play with. We don't want to give access to a broader group for something that is dead on arrival.

On Thu, Mar 8, 2018 at 5:31 AM Alberto Mancini <ab.ma...@gmail.com> wrote:

Hello, 

yes, definitely I would like to be in. 

I am really interested.

Cheers,

   Alberto. 

On Thu, Mar 8, 2018 at 2:21 PM Nándor Előd Fekete <nandor...@gmail.com> wrote:

I am really interested. Can you sign me up?

On Thursday, March 8, 2018 at 9:13:01 AM UTC+1, Goktug Gokdogan wrote:

The main blocker for releasing J2CL for wider audience is even basic missing functionalities around building it in open-source and seeing at least some output for your compilations. That is blocked on missing functionalities in bazel. After that we can probably finished in more timely manner.

There is still tone of work to do for a polished open source experience but at least we can give access to more people who is really interested.

--
You received this message because you are subscribed to the Google Groups "GWT Contributors" group.

To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/8de62b64-4bc8-4158-80d4-b15ef688f523%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "GWT Contributors" group.

To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscribe@googlegroups.com.

[Slava Pankov]

Yes, I agree "even basic missing functionalities" sounds scary. And why bazel? It's not even close in popularity with Maven and Gradle.

[Goktug Gokdogan]

A basic functionality missing in open-source build doesn't mean it is far away. We were trying to get it ready by this quarter but it didn't work out as I explained earlier.

For 'pure' J2CL experience, we have chosen bazel. Bazel works/scales pretty well and same as our internal setup which makes it much easier to maintain as well. Keep in mind J2CL != GWT 3. A bunch of contributors are already working on GWT/Maven/Gradle support on top of that so you are not be forced to use bazel.

To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-co...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/8de62b64-4bc8-4158-80d4-b15ef688f523%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "GWT Contributors" group.

To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-co...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAGv30V%3DfWDpwQ45u9mPVuXY%3D62PJZ%2B9uxearZk5Lq_a0j2yjaA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--

You received this message because you are subscribed to the Google Groups "GWT Contributors" group.

To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-co...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/5e3a16fb-2eda-40b0-a59a-6525b87a17d6%40googlegroups.com.

[Norbert Sándor]

I have been an  enthusiastic user of GWT for many years but I don't use it anymore and I recommend for everyone not to use it for new projects.

(Additionally I think that Google killed GWT like it did with other interesting and useful projects.)

Use Javascript, Kotlin or even Doppio (https://plasma-umass.org/doppio-demo/) - but in today's rapidly changing IT world it is not acceptable for a project to be postponed for years...

--

Norbi

[Relja Pcela]

I would recommend Vaadin instead (of GWT or any JavaScript). If you like you can use Kotlin or Scala with it as well.

[Ignacio Baca Moreno-Torres]

Being slow but mature is a pretty good thing sometimes. As you said, "today's rapidly changing IT" is crazy rapidly, you start a project in a technology that when the project is production ready it might be that technology considered deprecated already. Java and GWT are all about maturity and useful for kind of classic stable long project development. Some of your arguments can apply to Java itself. But yep, I personally love Kotlin, and other modern cool features. But never confuse those modern tools with the quality or productivity of your project, this is all about your project, management and developers. Java + GWT is more than enough to be able to develop competitive projects that share Java source code between servers and clients. Curious note that said something like "java is about maturity and not about cutting-edge features": https://youtu.be/Zzs4zEkGbiE?t=39m11s

--
You received this message because you are subscribed to the Google Groups "GWT Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-co...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/3700b8a3-57dd-43fb-bcf3-d06603a2b2cb%40googlegroups.com.

[Learner Evermore]

I no longer work for the company where this still is an issue. I now work for another where they are trying to get rid of the little GWT 1.x they have and move on.

I love the basic premise of GWT - it is after all what I personally wanted to develop but didn't have the time/resources to do back in 2002 ... 

The point in using a language (any language) for some work is because it offers more advantages than disadvantages for the specific use case. We all know what advantage Java as a language has over JavaScript, no need to go there. That is highly, but far from enough to outweigh trouble of still having to know JavaScript details and how to interoperate with libraries NOT built with Java/GWT in mind 

For me, the greatest benefit is the ability to share code with a properly written server (and, no, I don't consider node.js a contender - it is a runaway joke for merely dynamic web sites needing good SEO). Beyond just sharing the code it is also about the ability to communicate smart objects with the server and not have to deal with marshalling/unmarshalling dumb DTOs that themselves then need extra plumbing code to be copied to/from the "actually useful" objects. DTOs are a menace (unfortunately often needed due to how the rest of the system is designed) and impede on / break OOP and/or proper componentization.

GWT addressed all these. However, it is not evolving in a "mature" slow fashion. The problems are:

1. The backing company backed off but kept the crucial new piece secret - J2CL.
2. The past and current stated direction devolves the product, does not evolve it. Good, differentiating features aren't enhanced or even replaced but just plain eliminated under the premise that select few NOW (but not all) think they are bad but are really only hard to do, which is what makes them useful (say GWT RPC, debugging, widgets). I could have helped with that. No more, though.
3. The surrounding ecosystem has crumbled. One big example: Sencha GXT. 
4. Inability to plan proper migration to 3.x - "just don't use anything useful from previous versions" obviously doesn't cut it.
5. Constant delays, broken promises all  scream "dead priduct, stay away"

I am now left feeling that GWT 2.x is still the best AVAILABLE thing out there but it is dead and dangerous to start anything with as things will evolve away from it. The same goes for other Google "children" as they too have been broken horribly over time. I hate the idea of a large JS/TS application but I am cornered into having to, as GWT does not really exist as an option. The only sort of interesting alternative is TeaVM but it is in very early and risky stages, with one guy developing it only 

If and when it comes back, it will be a totally new contender (not compatible with anything there ever was as is) to reevaluate, with a huge stain in its history. 

Sad,

Learner Evermore

To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CABVWDC6qnKenQZLKDry0xqkH7pDuEy2FuOiyv5U5RzjY6CHW0Q%40mail.gmail.com.

[Jens]

1. The backing company backed off but kept the crucial new piece secret - J2CL.

These days it is already available to a few people who take their spare time to make it useable by the general public. 

1. The past and current stated direction devolves the product, does not evolve it. Good, differentiating features aren't enhanced or even replaced but just plain eliminated under the premise that select few NOW (but not all) think they are bad but are really only hard to do, which is what makes them useful (say GWT RPC, debugging, widgets). I could have helped with that. No more, though.

GWT 3 compatible UiBinder already exists, GWT 3 compatible GWT RPC is being worked on, Widgets will be GWT 3 compatible, other code is already GWT 3 compatible or is being worked on. There are quite some new people who never really contributed to GWT itself before who now step up and invest time in migrating existing GWT SDK code to JsInterop / APT. So you can still help if you want to.

See:

https://docs.google.com/spreadsheets/d/1b1D9fEqRh5lZ8cqMJtYoc_25rfTRvsuJkTtS2vjgi3o/edit#gid=0

https://ci.vertispan.com

   

1. Inability to plan proper migration to 3.x - "just don't use anything useful from previous versions" obviously doesn't cut it.

People were a bit too scary I think. Obviously a migration plan must be planned and can only be planned if you have the tools like JsInterop, elemental2, J2CL to do so. As you see above it does not look that scary anymore. A bunch of people are working on migrating GWT code, even the tough ones like GWT-RPC / UiBinder (though they require some changes in apps because of APT).

 

Current plan is that you must get rid of any deprecated GWT APIs in your app as these will finally be deleted. Then you pull in the new libraries and update your imports. Finally you have to apply (hopefully small) code changes in your app to meet the "no GWT.create(), no JSNI" requirement.

 

If and when it comes back, it will be a totally new contender (not compatible with anything there ever was as is) to reevaluate, with a huge stain in its history. 

A pretty appealing contender. 

-- J.

[Frank Hossfeld]

That's not really true. There are a lot of people working on the GWT module, getting them out of GWT and moving them to standalone artifacts. Doing that, they replace JSNI with JsInterop, replace generators, etc. This is all done, to get GWT 2 ready for GWT 3. And if you want to see something existing in GWT 3, you can ask vertispan to do the job. 

With the knowledge about the things, that will change with GWT 3 / J2CL, I was able to make mvp4g ready for GWT 3 / J2CL. I replaced the generator with APT and remove the dependency to any GWT classes. I created a sample application based on the new version (mvp4g2) and Elemental 2. And yes, it works with J2CL. 

And, keep in mind, applications written in GWT in 2010 still work. What was the favorite JS framework at that time? I don't remember.

[Ivan Markov]

Don't you think there could've been 2x or even 3x as much people working on porting GWT2 stuff over to J2CL if J2CL was released in the first place? For one, releasing J2CL could've made me reconsider how much time I invest in my own SDBG pet project. Which - at the current situation is exactly zero. Or whether to invest time in the abandoned typescript2java effort, which would bring seamless JSInterop with gazillions of .d.ts'd JS libraries without the need to manually code JSInterop bindings...

Say what you want, but 3 months since my original rant that at the top of this thread, the "basic Bazel building issues" of Goktug seem still to be a roadblock and J2CL is still nowhere to be seen.

... and then we had Daniel planning to write a book on J2CL end of 2016, remember? Come on guys, it is Q3 2018 now... I might now agree with Learner Evermore on his points 2) to 5), but with point 1) he nailed it:

"1. The backing company backed off but kept the crucial new piece secret - J2CL."

[Goktug Gokdogan]

Hi all.

Sorry for the delays in getting J2CL work for opensource. Some of the delays were out of our control but this is something we actively working on in the last few months and having progress. In the meantime plenty of active GWT contributors already has access to it for a long time and working on getting GWT 3 ready. Also a while back, I said "if there are more people who needs access to J2CL for GWT 3 porting, we can give them access" but it is not usable for average developer.

If you think you need earlier access to J2CL in as-is state (which partially builds with plenty of workarounds), pls send a message to j2cl-e...@googlegroups.com; and pls make your case (e.g. porting X from GWT 2 SDK to GWT 3) and we will give access. However we cannot help you a lot at the moment when you hit problems (you will) so pls set your expectations accordingly.

--

You received this message because you are subscribed to the Google Groups "GWT Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-co...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/03d79d23-11e5-423b-9009-d439a569c512%40googlegroups.com.

[Alberto Mancini]

Hello Goktug,

thanks a lot for the opportunity. 

Actually seems that the address j2cl-e...@googlegroups.com does not exist.

---- mailer...@google.com ---- 

We're writing to let you know that the group you tried to contact (j2cl-external) may not exist, or you may not have permission to post messages to the group. A few more details on why you weren't able to post:

 * You might have spelled or formatted the group name incorrectly.
 * The owner of the group may have removed this group.
 * You may need to join the group before receiving permission to post.
 * This group may not be open to posting.

----- ----- 

It is just me, I'm not autrorized or actually the address is spelled incorrectly?

Thanks,

   Alberto. 

To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAN%3DyUA2Z333EfYXk-RAD_%3DPJkrXV62JkfWHJFrwTdUsj%3DZ_StA%40mail.gmail.com.

[Julien Dramaix]

I changed the permission settings. You should now be able to apply for membership at https://groups.google.com/forum/#!forum/j2cl-external

-Julien

To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAGv30VkKJ3gLvv2NupBDKXNXqTY0trxCYsQ%2BM6NoNRh92mtfUQ%40mail.gmail.com.

[Goktug Gokdogan]

Please send your member requests with some background information on why you need early access.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CABb_3%3D6%2BJ3Bk2bN1-aHMp1z4Sh%3Dv9-pxa21L%3D9AT_gSMj24z5Q%40mail.gmail.com.

[Ming-Yee Iu]

Wow! It's great to see all that progress being made on GWT 3. That's a lot more backwards compatibility than I was expecting.

Still, it would be nice to have J2CL released separately as soon as it is ready to do so because

1. Based on past experience, it will take 1-2 years or more before GWT 3 is released
   
2. J2CL is useful independent of GWT 3. Just recently, I wanted to package up some Java code as node.js NPM packages for others to use, but doing that really requires something like J2CL instead of GWT
   
3. It's good to have some time for people to develop best practices for how J2CL code can be mixed with JS. Google's JS code style is very clean, well-typed, and Java-like, so it will naturally work well with J2CL. Much real-world JS code is ugly and makes use of horrible JS corner cases and hacks, so it might take a while to figure out best practices for how to deal with those.
   

[Norbert Sándor]

> it would be nice to have J2CL released separately as soon as it is ready

I still don't get why the development of J2CL / GWT 3 cannot be done openly like any other open source project.

Why this secrecy is necessary.

This kind of project management type is very unusual in case of open source projects

It will make many people to stay away from the project and to switch to (even worse) alternatives :(

--

Norbi

[Goktug Gokdogan]

J2CL is yet-to-be open-sourced Google product, I'll post a separate update on the state but that's why it wasn't developed openly.

GWT, which is community owned; there is nothing done in secrecy and people in the community actively working on GWT 3.

--

You received this message because you are subscribed to the Google Groups "GWT Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-co...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/9516f69a-62cc-4eb9-86e6-aaeec3a09366%40googlegroups.com.

[Slava Pankov]

@Ivan Markov Please invest some time to SDBG, it's great tool, very convenient. Despite of Chrome dev.tools, I still prefer SDBG as more natural for java developer.

[Slava Pankov]

@Ivan Markov For some reason I cannot edit my previous message :-( Just want to clarify that I'm extremely grateful for your SDBG tool, it's beautiful software, and it's really sad to hear that you have some doubts about it.