Archives For Java

I’m back to finding alternatives to the use of Java. Oracle is working to increase license collections on Java big time starting this year. I loath Oracle and all things Oracle, and the fact they now own Java and have gone after licensing fees for Java means, for me, that I have come to loath Java equally. It is for this reason I’ve once again flip-flopped toward finding and using any and all alternatives to Java on every platform I work with. An excellent example of an alternative is the image burner application Etcher from resin.io.

Etcher ticks a number of key boxes for me:

  • It can safely copy a Linux image from an image file (iso, img, etc) to a USB drive or SDHC device.
  • It can work on Windows, Linux, or macOS. In this example I tested it on macOS Sierra.
  • It’s open source and available via github.
  • It’s based on Electron, using CSS, HTML, and JavaScript.
  • I can use it to copy my Raspberry Pi images to micro SDHC cards simply and reliably on my MBP.

That last bullet is what makes it a full keeper for me, as well as the tool I now point novices towards who want to work with the Raspberry Pi and want to create their own micro SDHC cards. It is absolutely as simple as starting the application, pointing it towards the image, and then plugging in the device to be flashed. Etcher finds the device automatically, making it dead simple to click the button and start the image copy to the device. No more tricky and down-right dangerous CLI dances with mount, umount, and dd.

Other Electron-based applications I now use are Atom, the editor, and Slack. There’s a whole bunch more out there, and the tooling to write even more is available where-ever there’s tooling for writing web applications. Java isn’t going to die anytime soon as it has a lock on a lot of legacy software. But that’s the same formidable block that Microsoft Windows posed back in the day, and we’ve seen where Microsoft is today, especially in mobile. Rather than complain about how bad Oracle and Java have become, my energy would be better spent promoting Electron and other foundational products and tools as better solutions than Java, even Java 8. It really is time to move on.

1000px-wave-svgBack on 14 July I wrote a post titled “no more java“, in which I swore off the use of Java for everything new and to “walk away from any Java programming opportunity.”

It turns out that there is, practically speaking, no way for me to do that. As much as I despise Oracle, the use of the language throughout the last 21+ years of my software engineering career (Java officially turned 20 in 2015) isn’t something I can just blithely walk away from. As I came to discover over the last 60 days, while there are a lot of very good programming languages besides Java, there are some things for which Java is the better fit, warts and all.

That’s not to say I didn’t find the other languages I looked at as less than Java. I found them all quite compelling in their own rights. The languages I did go back and look into included Python, C-Ruby, JavaScript (via node.js), the latest stable version of C++ (C++14 via gcc and clang), Google Go (up to 1.7) , and Rust (up to 1.11). Notable by its absence is Swift. I chose not to dive into Swift because it’s still only on one platform (OS X, soon to be called macOS) and because it’s still in a state of flux as it transitions to Swift 3.

All those languages I did look deeply into were quite compelling in their own rights and offered powerful solutions for different classes of problems. And while they tended to overlap some features and capabilities of Java, they could never replace Java for the types of software problems I like to work on. And please note, when I speak of the languages I also speak of the development, build, test, and deployment tools that wrap a language and help make it a powerful problem solver.

I don’t consider my two months looking elsewhere a waste of time; far from it. It was an eye-opening trek into languages I would have never taken otherwise, as well as a deeper dive into some languages I’d had considerable experience with before, such as Python and Ruby (in fact, working with Python 3.5 was almost like re-learning the language, as the last version I’d touched was 2.4). With Java I’d grown a bit stale in my thinking, which is never a good thing. Looking at other programming languages fosters opportunities to expand perspectives and offers alternative solutions to tough problems for which Java might not be the best fit. It also illustrate ways to weave these “new-ish” solutions back into new and existing Java solutions.

And finally, by taking two months away from my Java work, I discovered when I came back that tough problems I couldn’t quite solve before were suddenly solvable, some of them quite easily so. I really needed a break away from Java.

So it’s back to Java, or more precisely, the Java Virtual Machine (JVM). For with the JVM I also have Scala, Groovy, Gradle, and JRuby, not just Java 8. I’m using the Actor pattern¬†Futures and Promises and the Parallel Collections Library supported by Scala for modeling and simulation, while using Groovy and JRuby to solve unique problems while calling down into the Java libraries, especially for UI bits. And finally I’m getting the hang of using Gradle as my primary build, test, and deployment framework. I am so tired of Ant and I’m no fan of Maven either.

I need to do this again, at least once/year, to maintain a clear mindset and fresh perspective. I look forward to my next walk-about through the programming language landscape.