4 ms·

Yes, it was the most controversial change to Java 9. Currently, the compromise was that there's a jvm arg you can set to re-allow reflection access. But the ide

Yes, it was the most controversial change to Java 9. Currently, the compromise was that there's a jvm arg you can set to re-allow reflection access. But the idea is that it will eventually be taken away, so it's a stop gap. I'm not sure if it will impact the Clojure REPL. I know Clojure is aware of the Java 9 changes, and I think they have some ideas how to keep things working somehow. There's also going to be a Java Repl now, called jshell. ButI don't it will be given special permissions such as that.

dkersten 9y ago
Its not that it will impact the Clojure or the Clojure REPL, but rather that it will affect the utility functions that we wrote to inspect our running system. For example, we have a function 'inspect' that takes an object and series of Clojure keywords - it converts the object into a clojure map where the keys are keywordized member variable names and the values are its value. It then acts recursively consuming the series of keywords to look of the fields. This makes it trivial to look into deeply nested object graphs. (It also does some other things like pretty printing the results, accessing containers by index etc) BUT this is only useful because 'inspect' sees all fields: public and private. It does this by using the reflection API to access private fields. (inspect rootobject :someField 0 :privateField :foo) would be the same as the following java (were java to ignore visibility modifiers): rootobject.someField[0].privateField.foo or (depending on the type of someField): rootobject.someField.get(0).privateField.foo or if, for example, privateField is a map: rootobject.someField.get(0).privateField.get("foo") ...etc We don't want to have to make things public that shouldn't be semantically public and we similarly don't want to provide accessors when they are not required, just for the sake of being able to poke at them with our debugging/monitoring tools.

dkersten 9y ago

Its not that it will impact the Clojure or the Clojure REPL, but rather that it will affect the utility functions that we wrote to inspect our running system. For example, we have a function 'inspect' that takes an object and series of Clojure keywords - it converts the object into a clojure map where the keys are keywordized member variable names and the values are its value. It then acts recursively consuming the series of keywords to look of the fields. This makes it trivial to look into deeply nested object graphs. (It also does some other things like pretty printing the results, accessing containers by index etc) BUT this is only useful because 'inspect' sees all fields: public and private. It does this by using the reflection API to access private fields. (inspect rootobject :someField 0 :privateField :foo) would be the same as the following java (were java to ignore visibility modifiers): rootobject.someField[0].privateField.foo or (depending on the type of someField): rootobject.someField.get(0).privateField.foo or if, for example, privateField is a map: rootobject.someField.get(0).privateField.get("foo") ...etc We don't want to have to make things public that shouldn't be semantically public and we similarly don't want to provide accessors when they are not required, just for the sake of being able to poke at them with our debugging/monitoring tools.