JavaOne – Apache Maven and its Impact on Java 9

“Apache Maven and its Impact on Java 9”

Speaker: Robert Scholte

For more blog posts from JavaOne, see the table of contents


Up until Java 8, Maven goes fine on top of Java. In Java 9, there is overlap.

Review of Maven

  • Dependency management
  • All about pom.xml
  • All about classpaths
  • Generate project information

Module path mismatch

  • Classpath accepts – output dirs, jar files and zip files (Maven doesn’t support zip files)
  • Module path accepts output directories, module output directories and directories with jars [and jars; keep reading]
  • Options included pointing to diretory containing the jar (but contains other things to), symlins (windows unhappy), create lib directory and copy files (a lot of IO)
  • Java 9 team added specifying direct jar files per Maven’s request

Module names

  • Like problem with group id/artifact id
  • Need to be unique
  • Learned over 30K artifact ids end with a number. This was a problem for automatic module names because many woul have same name creating collision. ex: commons-lang2 and commons-lang3
  • Also, many artifact ids are naming conflicts if ignore group id. Which is problematic for automatic module names when use two jars that collide
  • Made difference between library builders and app builders. Standard that library builders should never refer to automatic modules. If no exports, can assume it is an application. And apps have control of what gets used.
  • Maven gives warning if library refers to automatic module usage. (use Maven 3.+ so warning shows up in color

Dependencies not yet modular

  • If you are dependent on open source library and it is dependent on one that isn’t modular (or the depenency changed the module name), the direct dependency can’t migrate to modules yet
  • Solution: use Automatic-Module-Name to manifest of libraries so not using algorithm. A good bridge

Tips

  • Point of no return – each time you refer to a dependency that is a module, you can’t go back to a previous version that does not
  • Don’t have split packages if can (Maven itself has a split package issue for old compatibility classes)
  • Don’t have classs in the root package
  • Provide your future module name in the manifest
  • Use a unique module name
  • Don’t change folder structure to add module name
  • plexus-java can help plugins build path
  • Classpath isn’t going away. The older the project, the harder it will likely be to migrate to modules

release tag
In addition to source/target 1.9, you can specify <release> to indicate compatiblity
Can use animal-sniffer to determine if code compiled on a newer version of Java in an older JDK mode will ctually run.

Module file
Maven doesn’t generate. Requires human input. Not all modules are dependencies. jdeps can do it because has access to binary files. But need before compile at build time so not compiling twice

My take: Interesting problems and solutions. I feel like he takeaway is “don’t upgrade to Java 9 yet”. The font was small on the screen. Even when there aren’t a lot of words on the screen

Leave a Reply

Your email address will not be published. Required fields are marked *