|
|
|
|
|
by native_samples
1736 days ago
|
|
Well, dynamic languages like Clojure and static analysis like ProGuard will never mix that well. The module system helps though. You can get rid of the parts of the JDK you don't need. I very much doubt reflection is going anywhere. For one, GraalVM native images support reflection, you just have to state ahead of time what you plan to reflect over. WASM+JVM works. You can run WASM on top of the JVM. There's a Truffle interpreter for it, which means WASM code gets JITCd by the JVM itself and you can interop in and out. Check out GraalWASM. |
|
- I can keep around the bloat
- I can try to find an 3rd tier library with less eyeballs that's smaller and does less (If I later want to do more image manipulation I might find myself in a bind)
- I can try to manually go in and trim out the stuff I think I'm not using (not that I really understand the BoofCV internals..)
So the ecosystem is actively discourages me from using large mature libraries :( (I ended up using option 3 with trial and error)
Graal maybe sidesteps the issue. Yeah it has reflections, but as you say you need to be explicit about them. So the rest can be trimmed.
I guess my original loaded question was implying that maybe this will make library developers more keen on dropping reflections internally (it's honestly almost never a good design choice anyway)
That all being said.. I think 90% of people are writing some server-side web stuff and none of this matters to them :)
> GraalWASM
I'm kinda curious about the other way around. Running JVM byte code on WASM. Not in any serious way.. but it'd be cool you could run an uberjar in the browser. A quick search brings up a few ongoing projects :)