Introducing Project January

A new project proposal from the Eclipse Science Working Group (SWG) goes live. Project January aims to provide a set of standardized Java-based numerical data structures for scientific computing. Scientific tools are rapidly scaling to meet the increasing demands of the user both in sheer volumes of data as well as complexity. Back at a site meeting in Trondheim, the SWG members agreed a generic dataset that would promote tool integration was one of the key priorities of the group. In the short-term, this looks a lot like “numpy for Java”. That in itself is a pretty big deal, but the future plans are equally exciting, check out the proposal here.

As for the name, project January works on many levels. Besides being the month the project proposal goes live, it is also an acronym: JAva NUmerical ARraYs :-). The month January is named after the Roman god Janus, god of new beginnings and doorways. Project January is a foundational building block of scientific computing and certainly a doorway to greater collaboration and tool integration within the Eclipse community and beyond.

Modularity in Java? Don’t Wait For Java 9/Jigsaw

Before 2016 all I really knew about Java 9 was that it would have project Jigsaw for modularity and that it would be late. A London Java Community meetup gave me an excellent excuse to pay more attention to Java 9 and think more on the whole concept of modularity in general.

The evening featured two excellent and complementary talks, Alex Blewitt on ‘Modularity in Java With OSGi‘ and Simon Ritter on ‘Modularization With Project Jigsaw in JDK 9‘. With those, some follow on insightful pub-talk & more discoveries on the web, below are the key things I take away from it all.

  1. Java 9 will be modular, hooray! And there will be a new linker tool jlink  to allow you build a streamlined custom image of the JDK. Using this to run Eclipse on a custom Java 9 image resulted in a 40% size reduction.  And that still included Swing & AWT, so the full benefits may be yet to come as application developers can start to take advantage of this new underlying modularity.
  2. OSGi & Jigsaw are both frameworks that facilitate modularity in Java, so have plenty in common, but some major differences. The most significant are basically features that OSGi has that Jigsaw lacks, namely versioning, dynamic modules and a service registry. By all appearances, Jigsaw is going for appearance of simplicity at the cost of functionality and complexity down the line. With no compelling reasons to switch, I will happily stick with OSGi and bet on the fact there are enough folks out there who will figure out how to get them working together.
  3. Jigsaw doesn’t make code more modular, developers make code more modular.  As Alex points out in his slides, modularity is hard. Frameworks like Jigsaw and OSGi make it easier, but there is still alot to be done on our own codebases. I know from experience, even OSGi users may sometimes have delusions of modularity – lots & lots of bundles which still, in practice, amount to a monolithic application. A notable amount of work we do is just that: understanding the essence of what each bundle should be then distilling it down by reworking it and removing bad dependencies so code can be reused in multiple forms with minimal dependencies.

So don’t wait for promises of Jigsaw to make your code more modular. Start now. Use OSGi. And don’t see it as a one-off thing. Actively developed code doesn’t stay modular for long. Review often. Modularity in Java is not a framework, it’s a habit to cultivate.