Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Colin Alworth
    @niloc132
    (same polyfill in j2cl and gwt2 iirc? its been a while)
    assuming so, best guess is that we broke the output language flag somehow
    Colin Alworth
    @niloc132
    had a few minutes tonight and confirmed on latest that the test builds ... but manually it fails because i typoed the path Vertispan/j2clmavenplugin#203
    the test cant be automatically run at this time because neither es6 classes nor web components work in htmlunit
    Colin Alworth
    @niloc132
    @lofidewanto_twitter debugging this now at https://www.twitch.tv/vertispan
    Colin Alworth
    @niloc132
    yep, can't reproduce - ping me here or in twitch if you want to jump on a call and figure this out - i'm using your latest head, plus a fix to make it not try to use java 5
    Dmitrii Tikhomirov
    @treblereel
    correct me if i missed something, Vaadin is semi-opensource. We can use it for free, only if we do opensouce projects, right ? They dropped gwt and now they use their own compiler.
    Ahmad K. Bawaneh
    @vegegoku
    Last time I checked they were still using gwt intetnally and they still use a very old version of gwt elemental.
    Colin Alworth
    @niloc132
    i thought they were all apache licensed, but at a glance now even core doesn't seem to be open source?
    Colin Alworth
    @niloc132
    @treblereel google/closure-compiler#4006 - check out those performance improvements
    i also got es6 modules working, turns out to be a bad assumption on my part
    but this should spell 2-3x improvements for our bundled_js, without even making anything incremental (based only on the results from closure-library)
    Colin Alworth
    @niloc132
    going to sit on the actual patch for a day or two before pushing to our closure-compiler fork, to see if it might get reviewed/landed upstream, rather than discover later there is a terrible downside of this approach
    Dmitrii Tikhomirov
    @treblereel
    wha ? 2x to 3x ? are you for real ?
    Colin Alworth
    @niloc132:delightfullyoffto.pics
    [m]
    Yeah - not a “real life” example, but closure library is a pretty decent case to try
    Es6 modules will add extra cost to transform them, but assuming your project isn’t all es6 it won’t cost much (and as ever, keep them in separate modules to avoid paying it each time)
    And we should be able to be incremental on top of this, but diminishing returns
    It’s a tiny patch too, and while I think it might possibly add a small bug in certain cases, it should get fixed anyway, separately
    Dmitrii Tikhomirov
    @treblereel
    can’t wait to test it with kogito … closure compiler is the main bottleneck, so i am very happy to see your results. I mean, i used to see something was speeded up to 10%, and it’s a good result, but 2X ….
    Colin Alworth
    @niloc132
    the one snippet i found in logs here showed that for j2cl:watch it was only 1s, so maybe lots of little bundles?
    this will not help optimized js at all, that needs a proper parse
    mdproctor
    @mdproctor
    @niloc132 for dev draft mode, I don't think we are expecting any optimization anyway.
    I could imagine two difference "refreshes". One that has no optimization and is quick fast. Then I hold down a key and the refresh takes longer with more js optimizations.
    Colin Alworth
    @niloc132:delightfullyoffto.pics
    [m]
    Yeah that’s pretty far into the weeds, but totally possible. Probably easier to just ask for the optimized build though while watch is running, since it would only run closure, the rest was already built
    Anyway, one way or another I’ll land it soon on our fork and we’ll see what it looks like on a real life project
    mdproctor
    @mdproctor
    yeah, I'm really not worried about optimized js at the moment.
    Colin Alworth
    @niloc132

    all closure tests and all j2cl-m-p tests pass with this set of changes, so i'm going to (as time permits, hopefully start tonight):

    • release a forked vers of closure-compiler
    • set the min version of j2cl-m-p to java 11
    • update j2cl-m-p to the new forked closure compiler release
    • make turbine enabled by default

    look for a j2cl-m-p 0.21-snapshot release soon to have this and other updates soon

    the new maven central search is way faster to be updated after a release it seems?
    Colin Alworth
    @niloc132
    and merged, j2cl 0.21-SNAPSHOT now includes this faster closure BUNDLE Vertispan/j2clmavenplugin#207
    mdproctor
    @mdproctor
    @niloc132 good news, thank you.
    ringoz
    @ringoz:matrix.org
    [m]

    Trying to migrate from Bazel, but getting this error: "variables in try-with-resources are not supported in -source 8 (use -source 9 or higher to enable variables in try-with-resources)"

    Found issue "Java9+ lang level features should work" Vertispan/j2clmavenplugin#48

    Any workarounds?

    Colin Alworth
    @niloc132:delightfullyoffto.pics
    [m]
    Yep we are limited to java 8 for now - it isn’t a j2cl problem per se but a general build issue, we need to be able to handle the “java.base” image building so that users can define their own jre classes
    Not hard to solve, we have the info we need, just isn’t our focus right now - we’re working on a few performance issues that affect big projects
    Colin Alworth
    @niloc132
    @ringoz:matrix.org i did some investigation today on livestream, and while i am basically certain we can switch to allowing java11 (and higher?), it will for now be at the cost of allowing adding custom emulation beyond what j2cl's jre already provides. the "good" news is that as far as i can tell, this is the same support that bazel offers, it doesn't seem possible to add new jre classes without actually forking j2cl and adding it there
    i'll see about supporting that, with these caveats, i'd love to get any other feedback you can offer
    orielmaute
    @orielmaute

    Hello together,

    i'm successfully using J2CL with vertispan-j2cl-maven-plugin in two advanced scenarios - React Native and GatsbyJS.

    I have a large code base written in Java/J2CL that uses a lot of external javascript libraries (e.g. React/MUI for GatsbyJS and React Native Paper for React Native). Neither React Native nor GatsbyJS has the possibility to add extern javascript via script-tag (in both cases there is no HTML document); and i cannot add the external code to closure compiler because i use ADVANCED_OPTIMIZATION and the external code does not support this.

    So in my scenario i compile the java code to js (with j2cl-maven-plugin) the result is used as source in a webpack project. In the java code itself i have defined a native require-Method to import third-party javascript modules via CommonJS module system. Closure Compiler does not understand the semantic of the "require" call, so it generates this call 1:1 - as expected. The webpack compiler uses the j2cl generated js source and knows the semantic of the "require"-call and includes/expands the module.

    But i had to patch vertispan-j2cl-maven-plugin to make both scenarios work. The plugin sets in class Closure.java hard-coded the Closure output_wrapper
    --output_wrapper (function(){%output%}).call(this);
    With this, the described scenario is not working, so i patched it. E.g. for my code using GatsbyJS i patched it to:
    --output_wrapper (function(){%output%}).call(globalThis);module.exports=globalThis;

    I had to use globalThis - because when i import my j2cl code via require - "this" is not window/self/globalThis.
    If have used globalThis so that goog.global is as expected the global context (window/self/globalThis).
    The second change is to make the created j2cl code a valid common-js module.

    The following code shows the javascript code using the generated java code.

    import * as React from 'react';
    const J2CL = require("../j2cl/j2cl.js");
    let Fc = J2CL.com.xoricon.Lib.getPage1();
    const Page = () => (
        <>
            <Fc />        
        </>
    );
    export default Page;

    Is there a better way to do for my scenario? If not, it would be great to make "output_wrapper" in j2cl-maven-plugin configurable.

    Colin Alworth
    @niloc132

    @orielmaute very cool - i'd love to hear more if you have time.

    I know that closure-compiler has support for emitting an ES6 module rather than a commonjs module (with require() and module.export so on), which webpack might be even happier to see, but i confess I don't know how to do it (yet! i have a project that requires it, but it hasnt been high on the priority list). I do know how to do it for GWT2 though, @vegegoku and i built a gwt2 linker that effectively is just its equiv of output_wrapper, and emits the required export line at the end (though only one, instead of one per type, so not terribly idiomatic).

    I definitely intended --output_wrapper to be something that could be controlled by the user if so desired, but there are a few considerations. First, when the tooling supports "chunks" (the moral equiv of GWT2's split points), there will also need to be a wrapper for the chunks, and likely the main chunk's wrapper, as i understand it, will need to coordinate as well. Second, wrapping in an IIFE like that for non-es6 modules permits the compiler to make certain optimizations it otherwise cannot do (by virtue of creating a new scope). Between those (and other things I'm sure I can't think of), it might make sense for this feature to have only built-in output wrapper values (or found via service loader, so a new one can be distributed outside the plugin). The other easy option would be to put the JS directly into a configuration property, but i think i'd tend to lean towards making a file in the project that contains the JS, and the config property points to the file

    are you already using goog.exportSymbol/exportProperty to emit that JS in a readable way, or do you have some other way to do that?
    sblommers
    @sblommers
    @orielmaute thanks for your message it triggered a solution for my corner case also. I'm currently trying to render d.ts files to use in typescript but did not manage to get acceptable modules working.
    Colin Alworth
    @niloc132
    @sblommers as it happens, ahmad is also working on jsinterop (plus a few custom annotations) to generate nice .d.ts files
    it does mean using the ts namespace keyword, which is not terribly idiomatic either...
    sblommers
    @sblommers
    @niloc132 oh that is incredible good news. Thank you for j2cl maven plugin and gwt3 processors and this chat. It's extremely helpful.
    Colin Alworth
    @niloc132
    i have a video around here somewhere to give an intro, one sec
    sblommers
    @sblommers
    Exciting i'll watch it thanks!
    sblommers
    @sblommers
    Awesome work and video(s). I was so happy with the output of j2cl and now this. Like a kid in the candy store. Curious how typescript is going to handle things. Having .d.ts files will make things a lot smoother. Nice work @niloc132 @vegegoku vertispan ftw. I'll be biting my nails until samenhang gets public. High file
    Colin Alworth
    @niloc132
    at the latest i can promise it will be end of q1 2023 (customer release deadline), but hopefully it will be soon, depending on when we can prioritize the last stuff we need for it, and all the publishing junk
    making it behave in j2cl will also require the export work discussed above, we're targetting gwt2 first