Tag Archives: java-9

JavaOne – Apache Maven and its Impact on Java 9

Posted on by
Reply

“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

migrating speedment to java 9

Posted on by
Reply

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.

Speedment

  • 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.

Jigsaw Effects/Problems

  • 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

Speedment Enterprise

  • 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.

java evolution of eclipse collections – live blogging from qcon

Posted on by
Reply

The Java Evolution of Eclipse Collections
Speaker: Kristen O’Leary
See the list of all blog posts from the conference

Eclipse Collections

  • was once GS (Goldman Sachs) Collections
  • Memory efficient collections framework
  • Open sourced in 2012

Java 8

  • 8.0 compatible with Java 8+
  • Extend Java 8 Functional Interfaces
  • New APIs – ex: reduceInPlace

Optional

  • 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

Collectors

  • 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()

Default methods

  • 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.

Primitive Collections

  • 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.

Java 9

  • 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.