[eeperson]

> There are attempts to fix this with e.g. Graal, which effectively does the expensive initialization and reflection at compile time, but there are so many downsides and pitfalls right now with Graal that I don't consider it a serious solution to the problem. It's basically creating a new ecosystem, which means one primary motivation--to take advantage of the Java ecosystem--is much less compelling.

I'm not sure I understand what the downsides are for Graal and FAAS. There are some pitfalls around reflection but even those don't seem to hard to avoid. Is that what you are referring to?

[cle]

Graal has incomplete support for Java. Last time I tried a few months ago, ObjectOutputStream was not supported (I think it is now?), which was a critical part of a library I was using, forcing me to abandon Graal.

Dealing with reflection is pretty awful, you have to comb through your entire dependency graph.

Targeting the compiler for a different OS/architecture than the host is difficult, to say the least.

There are so many great languages and runtimes to pick from these days...I can't imagine why anyone would willingly choose a technology like that.

(Don't get me wrong, Graal is a fascinating technology, and I hope that one day it is able to seamlessly compile Java code to native executables...but it's not there yet.)

[alserio]

Not gp but avoiding the reflection pitfalls is not so straightforward at all, you have to chase what your dependencies are doing to satisfy the "closed world" hypothesis. I still like java more than javascript, but writing performant serverless functions using js is way more easy right now

[eeperson]

You don't have to chase your dependencies. You just need an adequate suite of tests and then run them with the Graal Tracing Agent enabled [1].

[1] - https://medium.com/graalvm/introducing-the-tracing-agent-sim...

[cle]

Your tests would need to exercise all your transitive dependencies' code paths that are used in production. I very rarely see tests written that way.