[geokon]

1 -

I just do some Clojure programming, and I'm not deep into JVM things - but why does Android not even make a mention? Isn't it the most widely used JVM platform..?

2 -

> This does come with some restrictions and caveats; for example, it's not as straightforward to use Reflection in your Java code.

Is GraalVM going to push Reflections out of Java/JVM?

I guess my angle is I'd like to use the JVM to make (desktop) apps. Last I did, using cljfx/JavaFX reflections were a huge sore point. Ever dependency would drag in the whole kitchen sink - and reflections are an ugly wart that prevent unused classes/namespaces from being pruned.

I know technically there is Proguard.. but it's clunky and ugly I've never gotten it to work with Clojure. Graal native looked like a sort of light at the end of the tunnel.

3-

Whats the story with WASM and the JVM? Both designs seem eerily similar - but I don't know if the gap between the two is too large to bridge

[native_samples]

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.

[geokon]

Right, you can trim the JDK - that's true but I think the "problem" is a bit more general. I'll give you a more concrete example. I have some small application and it needed to do some basic image manipulation. So I bring in BoofCV and do the manipulation. However I then see that BoofCV drags in all sorts of crazy stuff to do with machine learning and whatnot - along with a sea of irrelevant dependencies

- 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 :)

[native_samples]

Right. If you're very sensitive to download time then you want to trim unused code as much as possible, or dynamically page it in.

[AmpsterMan]

Afaik, android has its own VM. It compiles Java the language into bytecode for that VM. Android didn't even include the standard Java library, instead providing its own.

[karussell]

Android is not a JVM platform. Android uses Dalvik as VM.

[SubjectToChange]

Dalvik was replaced by ART nearly seven years ago.

[karussell]

Sorry, just wanted to make the point that it is not JVM. Wasn't in Android dev since some years it seems ;)