Language Wars – Maybe Enough Already

Maybe I’m just old and grumpy, but I’m tired of surfing the internet and seeing language wars. I just saw this line “100% Java free!” the other day, listed as a product feature and it makes me shake my head. Of all the product features that would sell a product, you want to include that one?!?

There are programming languages for: scripting, back-end applications, front-applications, web containers, cloud, utilities, etc. One programming language does not cover all these use-cases. Although, someone people like to think so. 🙂

Most of my work day, I write code. 47% of my programming time is writing ‘C’ code, 47% of my programming time is writing ‘Java’ code and the remaining time is writing ‘C#’, ‘REXX’ and ‘PHP’ code. REXX is a great scripting language. It just doesn’t get the love it desires, probably because it originated on the mainframe – lack of exposure.

The programming language I use will depend on what I’m trying to accomplish. If it is a GUI desktop application or requires threading, I will choose Java because it is so much easier to do than ‘C’. This is especially true if I want it to run on other non-Windows desktops (ie. Linux or macOS). Of course, I can if/def the hell out of my ‘C’ code to accomplish it but why go through the aggravation.

The biggest complaint people have against Java is the JVM (Java Virtual Machine) load/startup time. There are thousands of web pages that talk about the startup of a JVM taking longer to load/start than a native ‘C’ application. Eclipse is usually the poster-child of this issue. This is all true. But who in the world cares if a desktop application loads in 0.5 seconds vs 2.0 seconds. Maybe you would care if it was a back-end application that was being launched every second but on the other hand, what the hell kind of application design is that? It should start and use threading. There are far, far too many novice/newbie programmers creating junk applications that somehow end up in production. I digress. Ok, back to JVM startup time. If you are using a desktop application during your work day (i.e. 8 hours), is there really an issue with the startup time? Maybe, just take another sip of your coffee, soda, green tea or water and then it will be loaded/started. 🙂

I created and sell 4 Java desktop applications: MQ Visual Edit, MQ Visual Browse, MQ Batch Toolkit and MQTT Message Viewer. Plus I have many helper (utilities) Java desktop applications for the various back-end solutions that I sell. Why Java? I want cross-platform execution and the ability to easily code “good looking” (aka modern) GUI applications.

A long time ago, I had some customers doing things with my Java applications that they shouldn’t have been doing. So, I decided to spend the money and purchase Excelsior Jet. Excelsior Jet compiles and links Java applications into native executables. I originally just purchased Excelsior Jet for Windows and Linux. After using it for a while, I decided to take the plunge and purchase it for macOS too. Besides IP (Intellectual Property) protection, using Excelsior Jet to compile and link the Java applications to native executables means that the startup/load times is on par with regular native applications.

Why macOS for an MQ application? Because shocking as it may seem, the break down of MQ Visual Edit end-user desktops is: 80% Windows, 13% macOS and 7% Linux. Yes, there are far more people using MQ Visual Edit on macOS than on Linux. Rather shocking if you ask me!

I use Eclipse to write all of my C and Java code. I use makefiles for my C applications and Eclipse executes the build process (makefile) as I save my code. For Java, everything is built into it for compiling Java code to classes and for testing (very nice). I have a separate makefile which I use to build the native executable using Excelsior Jet on Windows. For Linux and macOS, I copy the updated JAR to the respective OS and then run a similar makefile to create the native executable for that particular OS.

When Excelsior Jet compiles an application, it sucks in everything required to build the native application. So, what does that mean?

  1. It means that MQ is NOT required on the end-user’s desktop PC/laptop.
  2. Nor is Java. That’s right, Java/JVM is NOT required on the end-user’s desktop PC/laptop. It is because the Java application is compiled as a native application. 🙂

So, when I see comments like “100% Java free!“, I think that someone is stuck in the 90’s. There are millions of Java applications available that do thousands and thousands of useful things including games. (Of course, there are lots of poorly written Java, C/C++, C#, Python, PHP, Swift, etc. applications.) Over the years, first Sun then Oracle improved the startup/load time of the JVM. Hence, the slow load/startup time is not as much of an issue as it use to be but it is still there. For developers, who want to go that extra mile, there is always Excelsior Jet.

Can we stop with the language wars? Because for every complaint about Java applications, I can point to just as many poorly written and/or designed C/C++, C#, Python, PHP, Swift, etc. applications. So, lets move on. There is no need to go to war over which language to use or which is better. Use a language that is best suited for the job and don’t try to fit a square peg into a round hole.

Regards,
Roger Lacroix
Capitalware Inc.

This entry was posted in .NET, Assembler, C, C#, C++, IBM MQ, Java, JMS, Linux, macOS (Mac OS X), MQ Batch Toolkit, MQ Visual Browse, MQ Visual Edit, MQTT, MQTT Message Viewer, Perl, Programming, Raspberry Pi, Rexx, Swift, Unix, Windows.

2 Responses to Language Wars – Maybe Enough Already