In Java, private/protected functions/fields are mostly only a compile time check. Your code will not compile with if they shouldn't be able to see the function/field. But java also has a runtime inspection framework that allows you to view and call these scope hidden functions/fields in contexts that should not be allowed. You do have to ask nicely though with an extra call to request access. This is heavily used in things like Json/XML parsers and ORM tools. Really anyplace you need to blindly reconstruct an object programmatically.
> In Java, private/protected functions/fields are mostly only a compile time check.
Indeed, with reflection you can mutate member properties... I taught myself [this trick](https://stackoverflow.com/questions/10638826/java-reflection...) right away. You can also disable reflection via security policy, which would forbid that access with an exception.
Spring, Jackson, and other libraries that perform various "magical" feats around DI and serialization make heavy use of reflection to inspect private fields. Generally though they don't require write access to those fields (Spring possibly being the exception), but do generally require at least read access. Would be nice if there was a system to flag certain classes or jars as OK to violate access restrictions while still preventing others.
If the classes that Spring, Jackson, etc want to access are in the classpath, it works by default in 9 (will not in 10, you will have to use the --add-opens on the command line).
If the classes are enclosed inside a module, it's simpler, either you declare the package as open or the whole module as open.
(when you declare a package open you also can specify the module for which it will be 'open', by example, open com.foo.mylib to org.jackson.core)
> If the classes that Spring, Jackson, etc want to access are in the classpath, it works by default in 9 (will not in 10, you will have to use the --add-opens on the command line).
AFAIK "classpath-mode" is not affected by Jigsaw. All of classpath is one big module so "anything goes". As long as all of your code is on the classpath or a custom class loader created from the classpath anything should continue to work with 9 and even in 10. Things only start to break if you:
- reflect on JDK internals
- you put your code or frameworks or libraries in the modulepath
Having not really looked into the Java 9 features much yet can you expand on that last point? It sounds like that's more or less what I'm looking for though. Is it possible to declare a package to be open to multiple modules? I.E. could I do something like:
open com.foo.mylib to com.fasterxml.jackson.core
open com.foo.mylib to org.springframework.core