Fork me on GitHub
#graalvm
<
2020-03-04
>
borkdude08:03:43

> MethodHandles are currently not supported in native-image. This has been documented in https://github.com/oracle/graal/blob/master/substratevm/LIMITATIONS.md#invokedynamic-bytecode-and-method-handles. We are however looking to address this issue in the future From https://github.com/oracle/graal/issues/2214

ghadi19:03:43

@borkdude it can't see through the isJava8() predicate and determine which MH is chosen in Reflector.java

ghadi19:03:39

I'm no longer convinced that code in Reflector is accurate enough. There are some warnings it fails to catch.

ghadi19:03:55

(the canAccess() logic)

borkdude19:03:19

do we really care about the module system from a clojure perspective?

ghadi19:03:39

it's not about caring about module system

ghadi19:03:48

it's about the module system changed visibility rules

ghadi19:03:07

and we have to be sensitive to them -- otherwise IllegalAccess

borkdude19:03:30

why is catching it in Reflector.java better than IllegalAccess?

ghadi19:03:44

public class in the module system is only public if its package is exported by the module

ghadi19:03:02

whereas on java8 public class is... public

ghadi19:03:56

the Reflector shouldn't select/link methods it cannot call

borkdude19:03:38

Java / JVM itself will give an error about this. Why not let it crash there?

ghadi19:03:01

because there often is a public method you can call

ghadi19:03:03

scenario: public class Impl in a non-exported package, with a method foo() that it implements from public exported interface IFoo

ghadi19:03:48

if the Reflector selects Impl.foo() it is wrong, it needs to walk up the class hierarchy to find the IFoo.foo() method

ghadi19:03:22

groovy does this:

ghadi19:03:04

which is more correct IMHO, but they also dynamically load the class containing that method

borkdude19:03:11

For sci I've made a slight variation of clojure.lang.Reflector packaged as a library (for internal use). I've made two releases of this library: one for jdk8 and one for jdk11 so they can both work with GraalVM. That could be one approach of dealing with JVM-specific things.

borkdude19:03:56

I'm not sure how the rest of the Java world deals with these problems

borkdude19:03:26

thanks for sharing the Groovy example

borkdude19:03:49

@ghadi How does Groovy deal with Java8/Java11 compatibility?

ghadi19:03:05

¯\(ツ)

ghadi19:03:34

if i were to make something up, I'd guess that they do Java8 baseline and don't depend on anything above that

ghadi19:03:03

that class above ^ is in a directory called "vmplugin/v9" which appears to be conditionally loaded

borkdude19:03:08

( btw thanks for the latest Cognicast, enjoyed listening to it today )

4
ghadi19:03:06

cool thanks! lvh is a hoot