Partial super source? Possible?

[Bruno Salmon]

hi,

If GWT emulates a Java class but not all methods, is it possible to provide a complement as a super source?

For example, can I provide a super source for String.format() while keeping other String methods emulated by GWT?

Thanks

[Thomas Broyer]

GWT standard emulation is "just" super-source itself. You cannot "augment" it, but you can "shadow" it by providing your own super-source version of java.lang.String (copy from GWT and patch; and make sure it appears before GWT's emulation in the source path – i.e. IIRC make sure the <super-source> comes before any <include> that would bring com.google.gwt.emul.Emulation). This means you'll have to update your version whenever GWT updates its own.

But only ever do this for an application, never for a library!

[Colin Alworth]

I don't use String.format() a lot, even in the normal JVM, but based on the Javadoc it looks like we could add the format method, and delegate to a java.util.Formatter, but then leave that unimplemented by default. Then, downstream applications could more easily add that, without having to worry about keeping the rest of String.java up to date?

Note also when trying to do anything beyond simple %s replacement, the java.util.Locale type exists in GWT emulation, but offers no instance methods outside of toString.

https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/String.html#format(java.lang.String,java.lang.Object...)

https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/util/Formatter.html

https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/util/Locale.html

[Bruno Salmon]

The shadow super-source should work in my case, thank you.

 If later I want to move from GWT to J2CL, will I have a similar feature (ex: providing my own implementation of String.format() if not emulated) ?

[Thomas Broyer]

On Tuesday, July 25, 2023 at 2:26:14 PM UTC+2 Bruno Salmon wrote:

The shadow super-source should work in my case, thank you.

 If later I want to move from GWT to J2CL, will I have a similar feature (ex: providing my own implementation of String.format() if not emulated) ?

IIRC, no: each source file must only appear once, so you cannot use shadowing.

[Bruno Salmon]

Thanks Thomas. By "shadow" I was actually quoting you when you said: 

you cannot "augment" it, but you can "shadow" it by providing your own super-source version of java.lang.String

In my previous reply, I was saying that I'm happy with this solution for my GWT app (whatever you call this method "shadow" or something else).

But my concern is now with J2CL (as I plan to move my GWT app to J2CL in the future).

I would like to know if this solution will also work with J2CL.

i.e. will I be able to provide my own implementation of String.format() if not emulated by J2CL?

[Thomas Broyer]

I was specifically answering the J2CL part: you cannot use shadowing with J2CL, only with GWT.

More accurately, J2CL itself is rather low-level and will translate any file you give it; the "issue" here is rather the Closure Compiler (IIRC), that will error if it finds more than one file declaring the same Closure module (each Java class is translated to a Closure module).

You should however (IIRC and IIUC) be able to patch the Java Runtime Emulation (JRE) used by J2CL, similar to how you could patch it in GWT by using your own "fork" of the gwt-user.jar.

TL;DR: try hard to avoid using any class or method that's not part of the "built-in" emulation library. Refactor code to use an intermediate class (e.g. MyStringFormatter.format()) that you can then super-source. If compiling a third-party library, it might not be that bad of an idea to patch it (fork it) with that kind of refactoring.

I'll let Colin confirm though, as I've been away from J2CL for some time now.