Kichwa Coders Join Eclipse Science Working Group Steering Committee

Kichwa Coders is pleased to announce that we have become a member of the Steering Committee of the Eclipse Science Working Group. Kichwa has been an active member of the Science Working Group from the beginning and its involvement includes:

  • Leading projects related to Python scripting in Eclipse EASE
  • Organizing Eclipse community meetups in London (join us for our next one!)
  • Jonah Graham is project co-lead for the January Project for common data structures.
  • Tracy Miranda is on the Program Committee promoting the Science track for Eclipsecon France

Tracy Miranda will represent Kichwa Coders as the Steering Committee participant. The current Steering Committee is made up of members from IBM, Diamond Light Source, Oakridge National Labs and Itema. Kichwa Coders look forward to working closely with other Steering Committee members to shape the future direction of the group and encourage other organizations to participate in this vibrant ecosystem where advancing open-source software advances science.

How to use Python to hack your Eclipse IDE

The Eclipse Advanced Scripting Environment (EASE) project enables you to extend and supercharge your Eclipse IDE like never before. As a preview for my talk at Eclipsecon North America, I put together a how-to guide which you can read at opensource.com

How to use Python to hack your Eclipse IDE

Here are the kinds of things you can do with EASE:

  1. Improve your code quality
  2. Automate tedious tasks
  3. Prototype new features
  4. Quickly extend the user interface
  5. Integrate with third-party tools

My favourite hack is #3 where you can, with about 70 lines of Python, add automatic saving of dirty editors functionality to Eclipse. Something to tide you over until this feature is added to Eclipse proper.

3 Reasons I Love Eclipse

I love Eclipse. Not just the IDE, but the whole community and philosophy of it. There are no shortage of folks who will tell you how they hate Eclipse.  For a change I’d like to tell you why I love Eclipse.

  1. Polyglot IDE – Eclipse IDE is really great because you can use the same open environment for multiple languages. Java, Python and C are three of our staple languages and I often end up using them in combinations. Eclipse understands each of these really, really well and allows for some powerful integrations. There’s no place I’d rather run some Python on a target processor while debugging a Linux kernel.
  2. Determined developers – with all its functionality and extensibility maximising the power of Eclipse is pretty hard. The people in the community who do use Eclipse and master its complexity are full of grit; problem-solvers who won’t give up on their end goals easily. As a result, it’s a great community to be part of.
  3. Continuous evolution – early on in my career I worked with hardware, then I switched to software and today work involves keeping up with several different technologies. Likewise, over the years Eclipse has evolved a lot. Early on it was just an IDE, then a rich-client framework and today it features many thriving working groups growing in areas like IoT. Adapting and learning can be quite a journey, so it’s great to have a community along for the ride.

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.