3 ms·

It won't change anything for you most likely. The module system is taking the place of whatever you were previously using to order your dependencies on the cla

It won't change anything for you most likely. The module system is taking the place of whatever you were previously using to order your dependencies on the classpath. Now, instead, the module files list the dependencies of a module and, Java does a resolution of all of them to determine the dependency graph. So the order of modules on the module path doesn't matter, unlike the classpath. The only advantage I know of is that the standard lib has been split in over 92 modules. So if you don't use everything, your resulting Jar will be smaller. Basically, making Java more modular in the sense that packages are now grouped into smaller Jars. 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. This is the biggest issue people have with Java 9 modules, because it will not be backwards compatible, and certain code can't even be ported, since no public APIs exist for certain things. Finally, most programmer at the cast, like me and you, we're hoping that modules would be version aware, and allow multiple versions of the same module to coexist, but they didn't do that unfortunately.

zokier 9y ago
> So if you don't use everything, your resulting Jar will be smaller I'll admit that I'm not super well-versed in Java packaging, but I kinda assume that typical jars do not include any bits from standard library, so modularizing standard library wouldn't have any impact on jar size. I'd imagine that the effect would be instead visible for self-contained distributions, like e.g. docker containers.
- needusername 9y ago
  > but I kinda assume that typical jars do not include any bits from standard library, so modularizing standard library wouldn't have any impact on jar size. That is correct. > I'd imagine that the effect would be instead visible for self-contained distributions, like e.g. docker containers. In theory. In practice you need to build a JDK contains only the bits you need. Sounds great in theory, you can get rid of the CORBA and GUI modules, that should save you a lot of disk space. In practice the CORBA module is only 2.7 MB and the desktop module is 14 MB and almost every framework indirectly requires the desktop module because Java Beans are in there.
- concede_pluto 9y ago
  One of the worst things about the Docker fad is that people are wasting effort minifying things like the JRE and libc so that having many copies on the same machine isn't quite so blatantly foolish. They could be accomplishing something but instead they're wallowing in a problem that was solved decades ago.
mbfg 9y ago
Yeah this modularization will do nothing for your own jar's size. Basically, if you the developer weren't using OSGI before, and planning to switch to java modules, then likely the only effects you will see are negative ones. This is really for the benefit of the jdk itself, and tiny-platform installations. The threat of java 10, and onward -- breaking stuff is the real thing to watch out for.
needusername 9y ago
> The only advantage I know of is that the standard lib has been split in over 92 modules. Most of these are proprietary modules. > $ls $JAVA_HOME/jmods/ | grep java | grep -v javafx | wc -l Return 30 on my machine (build 175). Most of the 94 modules listed in my installation are internal JDK modules.
dkersten 9y ago
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.

zokier 9y ago

> So if you don't use everything, your resulting Jar will be smaller I'll admit that I'm not super well-versed in Java packaging, but I kinda assume that typical jars do not include any bits from standard library, so modularizing standard library wouldn't have any impact on jar size. I'd imagine that the effect would be instead visible for self-contained distributions, like e.g. docker containers.

needusername 9y ago
> but I kinda assume that typical jars do not include any bits from standard library, so modularizing standard library wouldn't have any impact on jar size. That is correct. > I'd imagine that the effect would be instead visible for self-contained distributions, like e.g. docker containers. In theory. In practice you need to build a JDK contains only the bits you need. Sounds great in theory, you can get rid of the CORBA and GUI modules, that should save you a lot of disk space. In practice the CORBA module is only 2.7 MB and the desktop module is 14 MB and almost every framework indirectly requires the desktop module because Java Beans are in there.
concede_pluto 9y ago
One of the worst things about the Docker fad is that people are wasting effort minifying things like the JRE and libc so that having many copies on the same machine isn't quite so blatantly foolish. They could be accomplishing something but instead they're wallowing in a problem that was solved decades ago.

mbfg 9y ago

Yeah this modularization will do nothing for your own jar's size. Basically, if you the developer weren't using OSGI before, and planning to switch to java modules, then likely the only effects you will see are negative ones. This is really for the benefit of the jdk itself, and tiny-platform installations. The threat of java 10, and onward -- breaking stuff is the real thing to watch out for.

needusername 9y ago

> The only advantage I know of is that the standard lib has been split in over 92 modules. Most of these are proprietary modules. > $ls $JAVA_HOME/jmods/ | grep java | grep -v javafx | wc -l Return 30 on my machine (build 175). Most of the 94 modules listed in my installation are internal JDK modules.

dkersten 9y ago

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.