[2019 oracle code one] dependency hell

Surviving Dependency Hell

Speakers: Robert Scholte (@rfscholte) & Ray Tsang (@saturnism)

For more blog posts, see The Oracle Code One table of contents

Identifying problem

  • Setup two dependencies with Maven and ran
  • Errors: NoSuchMethodError, NoSuchFieldError, ClassNotFoundException
  • mvn dependency:tree – lots of output
  • mvn dependency:tree -Dincludes=com.google.guava – filters by the jar suspected
  • mvn dependency:tree -Dincludes=com.google.guava -Dverbose=true – shows conflicts and reason
  • Showed IntelliJ dependency tree graph

Picking a dependency

  • Classpath – first class wins
  • Maven – nearest wins
  • Maven doesn’t understand Semver (semantic versioning)
  • Use Maven Enforcer with upper bound. This assumes library is backwards compatible
  • Guava 21+ is backward compatible

Other problems

  • Shade – Copies files to creates problems. Problem if jars relocated. Only do as last resort
  • Classloaders


  • Explicit dependency with version you need
  • Exclude dependency when pull in transitive dependency
  • Dependency management to specify version you need. Dependency management is a lookup table. It doesn’t actually need to exist. Can have a reference to a snapshot in there.
  • When making breaking changes – use new group id or artifact id. Use new package name. This is what commons lang did. – http://jlbp.dev/JLBP-6.html
  • BOM file for multi module projects with all transitive dependencies needed. Only use for modules within the project. – http://jlbp.dev/JLBP-15.html

<and then I needed to leave to get to my session in another building and get ready>

My take

Regardless of how good this is, I needed to leave early to get to my own session in another building right after this. I’m sorry I had to leave. It was excellent. I like that I learned about http://jlbp.dev so I can do more reading later.

[2019 oracle code one] Machine Learning

Machine Learning for Java Developers in 45 Minutes

Speakers: Zoran Sevarac & Frank Greco – @zsevarac & @frankgreco

For more blog posts, see The Oracle Code One table of contents


  • “AI is the new electricity” – Andrew Ng (societies with AI were above those without
  • For many tasks, algorithms are well known
  • Other algorithms harder – image recognition. Rule based. Constantly add rules. Large number of rules. Complex.
  • When complexity goes up, bells should go off. Avoid complexity.
  • When complexity index is too big, it isn’t scalable. Breading ground for bugs.
  • Not all use cases are not good for ML
  • Core of ML – recognizing patterns in data and making predictions against the data
  • Learn language by understanding all the rules (algorithm) or observing patterns (ML)


  • AI – type of algorithm where machine emulates aspects of human behavior
  • ML – subset of AI. Allows machine to learn from experience/data
  • Deep learning. Subset of ML. Uses powerful computing and advanced nueral networks

Deep learning

  • Accuracy grows with more data.
  • Older learning algorithms get outperformed after a certain amount of data.
  • Think of deep learning as a graph. Each node performs computation. Computation can be reconfigured by tweaking coefficients on edges
  • Layer – groups of nodes


  • Image recognition
  • Spam classification
  • Data classification
  • Identifying handwritten characters/image transformation


  • Training data
  • Try to minimize differences as go thru
  • Once goes below a certain threshold, training stops
  • Determine whether false positives or false negatives are worse for your use case

JSR381 – Visual Recognition API

  • Standard API for computer vision tasks using machine learning
  • Provides generic ML API design to support other libraries
  • Next phase is to figure out who/what get wider support/adoption
  • Brings ML closer to general Java dev audience
  • App programmers need to know this. Don’t need to become a data scientist to use.

Why matters

  • Patterns
  • Can change data structures
  • The case for Learned Index Structures – https://arxiv.org/abs/1712.01208
  • New hardware for API
  • What happens to countries that host call centers and their economy?


  • Need clean data
  • Privacy and ethics
  • Correlation vs causality
  • Data hacking/poisoning
  • DeepFakes – can create people that don’t exist
  • Interpretability
  • AI/ML talent is scarce

My take

This was a great way to get started. There were a bunch of code samples as well using Java APIs.

[2019 oracle code one] JPMS Modules with Gradle

Building JPMS Modules with Gradle

Speakers: Paul Bakker @pbakker

For more blog posts, see The Oracle Code One table of contents


  • Nobody in room yet using module system
  • Often takes several years after a feature release to be adopted.
  • Took 2-3 years after lambda use was common
  • Most open source provides a real module or at least a module name in the meta-inf


  • Maven supported module system early on and still does.
  • Gradle did not so developed a plugin
  • https://github.com/java9-modularity/gradle-modules-plugin


  • Shows modules as folders


  • Each module has own build.gradle
  • Root build.gradle file is where the modular plugin is applied
  • external plugin so set classpath and apply to all java projects
  • Dependencies are defined in both build.gradle and module-info.java. Have to do this in Maven too.
  • Plugin adds gradle configuration when compile/test.


  • Showed exports – plugin has addExports option when compile
  • Showed opens – plugin has addOpens option when compile
  • Also supports AddModules and addReads like the Java options

Application plugin

  • Creates tar/zip with lib and bin folder
  • Supports module path


  • Split packages
  • “The classpath always works – as long as you don’t have expectations”
  • Always a problem; now in your face
  • patch-module as workaround. Puts library in patchlibs instead of being on module path

Multiple start scripts

  • Out of box, can create one zip file/one starting point
  • Module plugin allows creating custom startup scripts


  • For whitebox testing, ok to break encapsulation.
    • Classpath is ok
    • Plugin provides moduleOptions on test to choose
  • Black box testing – want module path to test how module works from outside module boundaries.
    • Use module path
    • Need additional module for this approach for tests

Java versions

  • plugin has modularity.mixedJavaReleases
  • compiler runs in two steps
  • compiles everything module-info.java using recent java version (presumably Java 9) and pulls out module-info.java
  • compiles other sources using java 8
  • the module-info.java is ignored by Java 8

My take

I found the gradle files hard/impossible to read (red/purple/green) on dark background. That made it hard for me to follow the parts I didn’t already know. I did learn some though so it was worth going. And it’s great that gradle has a JPMS plugin! I like how he mapped the command line to Gradle code.