Feeback required for upcoming release 0.10.0

[Alexey Andreev]

Hi!

I'm glad to announce that release 0.10.0 is to come soon. I implemented all the features I planned and now I only need your feedback. So if it's possible, please, try latest developer preview (0.10.0-dev-12) and tell if you had some issues.

The most notable features of upcoming release are:

• Strings are represented by thin wrappers around JavaScript strings, which allows to improve performance in several operations and in interoperability between Java and JS
• JS backend was refactored to improve code generation, which allows to decrease generated code size
• JS backend produces ES6 code
• Gradle supports dev server (see new tasks javaScriptDevServer and stopJavaScriptDevServer
• Allow to generate JS modules (see documentation)
• JSO classes can now be represented by non-abstract classes. In this case additional @JSClass annotation required on class. To represent member methods, native methods can be used instead of abstract. This allows to map JS to Java constructors and JS static methods. @JSModule annotation can be specified for class to indicate that class should be imported from given module, not taken from global context.
• Vararg methods are supported in JSO
• instanceof now works properly for JSO classes, as well as casts. This only works for classes, not for interfaces. To turn off instanceof for particular class, add @JSClass(transparent = true)
• @JSPrimitiveType can be used to map Java class to JS primitive (this affects instanceof and casts)
• @JSTopLevel annotation can be applied to static methods to indicate that they aren't mapped to JS static methods, but rather to global scope. @JSTopLevel can be combined with @JSModule to import functions from modules.
• Changes in built-in JSO declarations according to improvements in JSO

[Stik Dragon]

Love the thin wrappers around strings, that's going to make debugging stuff in the browser so much easier, thanks.

Having updated our main app to 0.10-dev-12 i'm now getting this error all over the place:
```
classes.js:983: ReferenceError: ColDef is not defined
```

This particular example comes from here:

```js
ceppuga_AGGridColDefUtils_createDefaultColDef = () => {
    let var$1, $d, var$3;
    ceppuga_AGGridColDefUtils_$callClinit();
    var$1 = otjc_JSObjects_create$js_body$_4();
    $d = $rt_throwCCEIfFalse($rt_instanceOfOrNull(var$1, ColDef), var$1);
    var$1 = !!1;
    $d.resizable = var$1;
    var$1 = !!1;
    $d.wrapHeaderText = var$1;
    // ...
}
```
which is generated by this:
```java
public static ColDef createDefaultColDef() {
ColDef d = JSObjects.create();
d.setResizable(true);
d.setWrapHeaderText(true);
    // ...
}
```

`ColDef` doesn't seem to be declared anywhere.  I see lots of references to this `instanceOfOrNull` function that's often called with things like `HTMLElement` as the second argument.  They're all declared in the global window scope, but looks like none of our own `JSObject` implementations are.  Here's `ColDef` for example:

```java
public abstract class ColDef implements JSObject {
@JSProperty
public abstract JSString getField();

@JSProperty
    public abstract void setAggFunc(String aggFunc);

@JSProperty
    public abstract void setAggFuncParams(JSObject aggFuncParams);
    // ...
}
```
Any thoughts?  This is code that's been working fine in previous versions. 

[Alexey Andreev]

You should add `@JSClass(transparent = true)` to ColDev declaration or turn it into interface

четверг, 18 апреля 2024 г. в 16:23:42 UTC+2, Stik Dragon:

[Stik Dragon]

Ah brilliant, that's resolved it (although there were about 60 classes to add it to, very tedious and i think i spent longer crafting the Ultimate Regex™ than it would have taken to simply do them by hand)

So is this a general rule now, that abstract classes must be marked as transparent?

[Alexey Andreev]

No, it depends on the purpose of abstract class. If it describes some real class that exists somewhere in global scope, then you don't need it.

четверг, 18 апреля 2024 г. в 16:52:24 UTC+2, Stik Dragon:

[Ihromant]

I observed performance improvement with strings. Still, it didn't help me to fully get rid of performance issues, but now it's my problem. :D

Didn't use most of new features, but no regression spotted in 0.10.0-dev-12. Migrated JSO api to constructors, working smoothly. New release just after half year after previous, nicely done.

I suppose that next release new 22+ Java features could be implemented. Anyway, no urgent need for them until next LTS Java 25 is out.

String templates, Stream Gatherers are challenging to implement I suppose.

Good job!

середу, 17 квітня 2024 р. о 21:52:59 UTC+3 konsol...@gmail.com пише:

[Peter Taylor]

Seems to be a breaking change - which is easy to adapter to:

Upgrade notes:

When moving to 0.10.0 existing JSO classes may need to be annotated @JSClass(name = "XXX") otherwise generated javascript code may fail:

$rt_instanceOfOrNull(var$1, XXX),

Thanks!
Peter T

[vic-cw]

Is there a reason for producing ES6 code? Or can it be turned off with a flag? I feel like if one can avoid some browser incompatibilities, it's better to output the oldest possible JavaScript, isn't it?

[Alexey Andreev]

> Is there a reason for producing ES6 code? Or can it be turned off with
> a flag? I feel like if one can avoid some browser incompatibilities,
> it's better to output the oldest possible JavaScript, isn't it?

At least to support ES6 modules. Also, to reduce size of generated code
by using arrow functions instead of `function` keyword.

Is there any environment that's still limited with ES5? Even Rhino
supports ES6 partially (and TeaVM uses only ES6 features, implemented in
Rhino).

No, there's no flag to turn off ES6