search

konsoletyper / teavm

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

Why are the HTML elements abstract classes in v0.10.0? #942

Closed skerit closed 3 months ago

skerit commented 3 months ago

I was using the pre v0.10.0 system to create a basic server-side implementation of the DOM api, which worked great for my usecase.

But now that all the actual elements (HTMLElement, HTMLAnchorElement, ...) are abstract classes, what was a pretty straightforward implementation now requires me to duplicate a ton of code because I have to extend each element class individually.

konsoletyper commented 3 months ago

The reason for this transition is that initially JSO did not give any difference between interfaces and (abstract) classes. Since 0.10.0 JSO treats classes as concrete classes, can check them with instanceof and even instantiate them. I thought it may be useful in some cases to have the ability to make instanceof against elements without the need to write additional @JSBody methods.

what was a pretty straightforward implementation now requires me to duplicate a ton of code because I have to extend each element class individually.

JSO interfaces for DOM were never supposed to be implemented by user code, so you shouldn't have used them that way. I strongly suggest to stop doing this and write your own abstractions (which are implemented over some DOM parser on server side and over JSO DOM wrappers on client side). Anyway, if you don't want to do it, you can use Javassist ProxyFactory to create proxies for abstract classes.

skerit commented 3 months ago

@konsoletyper Hmm, writing another implementation wrapper over the JSO DOM & whatever server-side DOM doesn't seem appealing to me. It's one thing to do this on the server, but I for sure don't want to include a lot of this boilerplate code in the compiled JavaScript file. That seems like a huge step back to how I've currently got it working.

Is it never allowed to interact with/extend the JSO DOM classes then? Because that is kind of a requirement to making custom elements work: Custom elements extend HTMLElement in JavaScript too. This actually already works perfectly well with TeaVM.

I will take a look at the ProxyFactory idea though.