search

konsoletyper / teavm

Compiles Java bytecode to JavaScript, WebAssembly and C
https://teavm.org
Apache License 2.0
2.55k stars 260 forks source link

JSO: make global objects available in WebWorker contexts #888

Closed tryone144 closed 4 months ago

tryone144 commented 4 months ago

This removes the hardcoded window access in some globally available objects/function if they are also available in the WebWorker context (which has no window but self).

What do you think about changing these methods to instance-methods of Window? This would need a way to check between browser and worker context to select the proper function. Alternatively, we could introduce a teavm_globals prefix to access the global scope in the @JSBody annotations if needed (like the runtime templates utilize).

konsoletyper commented 4 months ago

What do you think about changing these methods to instance-methods of Window? This would need a way to check between browser and worker context to select the proper function.

I don't think there's any difference between atob and btoa functions in different scopes.

konsoletyper commented 4 months ago

Alternatively, we could introduce a teavm_globals prefix to access the global scope in the @JSBody annotations if needed

No, I don't see any need in this. TeaVM runtime has two distinct cases of accessing "global" scope: top-level runtime declarations and global declarations. @JSBody is not meant to access any of runtime functions (though there's a hack with hard-coded name prefix to do this, but it's a non-documented feature and a subject of change), so there's no need to introduce similar special. I think these window. prefixes were introduced here long ago, when TeaVM could not handle such cases properly.

tryone144 commented 4 months ago

I don't think there's any difference between atob and btoa functions in different scopes.

As far as I am aware, these are identical. The differentiation would only be needed if we were to access these as instance methods of a Window object retrieved via current() or worker(). Judging by the other global methods, keeping these static is consistent.

I think these window. prefixes were introduced here long ago, when TeaVM could not handle such cases properly.

If the identifiers in @JSBody are not subject to name mangling, this should be fine.