“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
- 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
- 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
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.
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
Migrating Speedment to Java 9
Speaker: Dan Lawesson @dan_lawesson
See the list of all blog posts from the conference
Cute – Spire their mascot on github has two years experience in that role
Since a library, want to be running with Java 9 as soon as it is released.
- Streams API ORM – customer.stream().filter(field.equal(value)).count();
- uses JVM memory acceleration, ode generation and modular design
- Type safety
- Works like streams – you don’t get any values back until terminal operation runs
- Have non-SQL code like a collector to convert the result into JSON
- can use findAny() with Optional on result – generates SQL limit statement
- Have finderBy so can join tables
- Like SQL, Streams are declared. Describe the what, not the how. But with SQL, you have to describe the result set format.
- A package must only belong to one modules. Yet it is common for two jars to have same package. The first one in the classpath takes precedence. In Java 9 must have only place for package.
- Automatic modules are for smoth transition to Java 9. It moves the Java 8 jars from the classpath to the module path. The jar automatically becomes a module
- However, automatic modules create split pakcages and can’t have those in Java 9
- sun.misc.Unsafe – should not be used but a key for real world Java success
- OSGi bundling is different than Jigsaw
Jigsawing the Java 8 open source application
- Running Java 8 under Java 9 JDK is easy
- Created module info file
- Brute force is to move all jars into depdencies in your monolithic module. When works, actually modularize app. Didn’t take this approach because already had OSGi modules
- Moduler approach: create directory for each module and move relevant packages to that directory. Add empty module-info.java (no requires/exports). That won’t compile so now can incrementally add dependencies and re-compile. Since this is iterative, they wrote a script to do it.
- Patch abuse of non-exported JDK APIs. Can add exports of java packages as a temporary workaround. Would need this flag at runtime if the temporary workaround isn’t removed. The workaround is just so you can identify all the issues and TBDs.
- Remove the OSGI bundling. Comment it out so building a jar instead of a bundle in Maven
- Use code generation so no reflection
- Harder becuase use sun.misc.Unsafe, third party dependencies with package issues
The first 20 minutes was about the Speedment library. I felt like that was a lot for a non-product talk. I wasn’t surprised because Dan was at my lunch table. And it was interesting. It just wasn’t necessary to understand the Java 9 part. Dan made a lot of references to things earlier in the day, which was nice. Also, the path Speedment took to move to Java 9 was very useful. I would have wanted to hear more about the issues in enterprise. Are they just outstanding issues. What do they plan to do if the libraries don’t release.
The Java Evolution of Eclipse Collections
Speaker: Kristen O’Leary
See the list of all blog posts from the conference
- was once GS (Goldman Sachs) Collections
Memory efficient collections framework
Open sourced in 2012
8.0 compatible with Java 8+
- Extend Java 8 Functional Interfaces
- New APIs – ex: reduceInPlace
- RichIteratable.detectWith() used to rutn null if no match
Pre Java-8 could use detectIfNone() to create if doesn’t exist
New method detectWithOptional() which returns Optional wrapper
- Collectors2 has collectors
- Can collect into Bag, ImmutableSet, BiMap, Stack, etc
- Have full primitive collections library
- Have full set of multi-map (map with multiple values for same key ex: key to list/set)
- Have extra APIs like chunk() and zip()
- RichIterable is common interface so default methods helpful.
- Used to add reduceInPlace() so don’t need to stream and create new collection
- Also useful for asLazy() or toImutabile() since Eclipse Collections doesn’t provide stream() there.
- Code generate the primitive classes so symmetry
- Showed impressive memry savings – Eclipse Collections and Trove equivalent. Much smaller than with autoboxing and faster too
- LazyIterable availalbe for all 8 primitive types. Just call asLazy(). A LazyIterabe can be reused unlike a stream.
- Module system
- Internal API Encapsulation
- Need to change APIs that use reflection in order to build. Can’t call setAccessible(true) any more.
- There is a command line argument to ignore reflection errors. Don’t want to impose that on callers
I like that Kristen uses kata examples to show hw the APIs work.