New Feature: limiting shared code

[hohwille]

A cool feature of GWT was that I could "emulate" shared code that was written for the server in the client with a "limited" implementation. The actual way to do this in GWT via super-sourcing was maybe a little odd but I wanted to make my code work in teavm und stubled over this problem. First of all I am impressed what is already working and at which speed - so thanks for all your hard work.
When using by Bean class in TeaVM, I got this error:

Class java.util.concurrent.ConcurrentHashMap was not found
    at io.github.mmm.bean.AbstractBean.<init>(AbstractBean.java:54)
    at io.github.mmm.bean.Bean.<init>(Bean.java:31)
    at com.demo.Client$MyBean.<init>(Client.java:41)
    at com.demo.Client$MyBean.<init>(Client.java:37)
    at com.demo.Client.<init>(Client.java:14)
    at com.demo.Client.main(Client.java:19)

Code is open-source, so you can find it here:
https://github.com/m-m-m/bean/blob/master/core/src/main/java/io/github/mmm/bean/AbstractBean.java#L54

Of course, I can try to rewrite my code and change the design so that I use a protected method providing the map implementation that gets overridden for the backend. However, I am sure this is not the last time I hit some problem like this. Also the problem could occur with external code that can not be tweaked.

Is there a solution in TeaVM for this problem available or planned?

Sidenote: Also I am thinking about the approach of candies in https://dragome.com where one can provide a complete JavaScript version for a library (JAR). Allowing to implement an optimized JavaScript/WASM would also be a killer feature to emulate the beans and properties I created in my OSS project natively in the browser to even more boost performance as JavaScript already has properties with value change listeners and this does not need to be emulated via Java compiled with teavm.

[konsoletyper]

You can create org.teavm.classlib.java.util.concurrent.TConcurrentHashMap in your project. See how Java class library emulated in classlib module

[hohwille]

Aha, cool. So it seems you already have some kind of GWT super-sourcing equivalent in TeaVM.
https://github.com/konsoletyper/teavm/tree/master/classlib/src/main/java/org/teavm/classlib/java
So maybe I could provide a documentation snipplet as PR and this issue can already be closed as the feature is already there. I assume the 'T' prefix is just a kind of design decision to avoid code completion pollution and stands for TeaVM.
Also if I would actually write such TConcurrentHashMap class and make it work, I could provide this as PR so #445 could be closed.

[hohwille]

Is the same approach also working to provide client implementations for non JDK internal code?
I assume so. In other words when I add org.teavm.classlib.«mypackage».T«MyClass» it will replace «mypackage».«MyClass» in the client code?

[konsoletyper]

Is the same approach also working to provide client implementations for non JDK internal code?
I assume so. In other words when I add org.teavm.classlib.«mypackage».T«MyClass» it will replace «mypackage».«MyClass» in the client code?

No, things are little bit complex. The rules are provided here, you can add you own teavm.properties file with you own rules

[hohwille]

Does that mean if I add such teavm.properties for my package namespace I then have to write emulation code T* types for my entire codebase? It would be awesome to have the option to override only single types that need reduced functionality in the browser (e.g. as they are using java.util.concurrent.* in the backend).

[konsoletyper]

Does that mean if I add such teavm.properties for my package namespace I then have to write emulation code T* types for my entire codebase?

What do you mean?

It would be awesome to have the option to override only single types that need reduced functionality in the browser (e.g. as they are using java.util.concurrent.* in the backend).

Which types you want to override?

[hohwille]

Ok let me give an example:
I have a huge library in package org.example.lib with 100 classes Class00,...,Class99.
Let us assume that Class99 is containing something that is not supported by TeaVM (complex code based on java.util.concurrent.locks.Lock) but it is used by all the other classes.
I would be able to provide a simple replacement for Class99 for TeaVM but I cannot or do not want to change Class99 for regular JVM usage.
How can I tell TeaVM to replace Class99 with my custom TClass99 but without duplicating the entire code of the other 99 classes?

[konsoletyper]

I see. You can change your code to not instantiate/access Class99 directly, but introduce Interface99, with two implementations: Class99JVM and Class99TeaVM, both in different modules. To instantiate Interface99 you should use ServiceLoader, and corresponding JVM-specific and TeaVM-specific module should contain correspoinding META-INF/services/Interface99 files. Another option is to use @PlatformMarker annotation; there's no documentation, but you can find usages of this annotation somewhere in TeaVM code repository.