3 ms·

Now Java 9 has some other features, one of them is to prevent reflection access of non public methods. This was made optional for Java 9. But might be made defa

Now Java 9 has some other features, one of them is to prevent reflection access of non public methods. This was made optional for Java 9. But might be made default in 10 and mandatory in 11. Really? Well, that sucks. In a large and complex project I'm currently working on, we've embedded a clojure REPL and we use reflection to poke at private data/methods of internal objects. Its been extremely useful for debugging and monitoring the state of the system. If we lose the ability of poking at private stuff, then we won't be able to do this anymore (unless we make everything public or add accessors for everything).

didibus 9y ago
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.

didibus 9y ago

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.