When to Say NO to Java

Java, a portable, multitasking, object oriented language. It has captured a considerable share of market so far. We also have huge number of products developed using this language to provide need based features to applications using it. It has also come long way since it’s birth. We have been using this language in many applications; still there are some places where we would prefer to say No to Java. These occasions may be result of some inherent disadvantages in Java, or these can be the side effects of some of the features which we most commonly use. Let us see when would we say, “I want to avoid this cup of coffee”.

1. Huge Operating System Interaction: Java program runs on Java Virtual Machine (JVM), and subsequently JVM interacts with underlying operating system. We all know this the platform independence feature of Java. But to provide platform portability, it is obvious that it is possible to offer only those platform interaction features which are applicable to all supported operating systems. Means, these are the language features which can be applied to Windows, UNIX, and Linux and so on. If the application to be developed needs heavy interaction with underlying operating system then it is better to select some other programming language which tightly coupled with the operating system. Here the selection may be a compiled language than an interpreted language like Java.
2. Heavy String Processing: Though characters and strings are integral part of any programming language, the amount of processing support each language gives varies from a language to language. Java handles string operations in immutable way i.e. each operation results in a new string. Though StringBuffer and StringBuilder ease out some burden, still if the application expects huge string processing then it is better to switch to a language like Perl, which can do these operations with lesser memory usage. Otherwise in Java the application may end up generating heavy garbage collection load and requiring higher processing power just to clean up intermediate memory consumption.
3. Low Level Tasks: Java is a high level language, meaning it combines many operating system commands in one Java statement. This revokes freedom of low level interaction with underlying operating system. Though there are limited features in this language to interact with operating system, still this high level nature reduces the available options further. On the contrary, you can take example of C, it is a high level language allowing low level processing as well.
4. Fast Processing: Some of you may say it is myth, but it is arguably true that Java is not the fastest language. You can achieve desired speed by different means with this language, but it is not this language’s inherent quality. The reason may be introduction of JVM as middle processing tier while running programs on a operating system. Highly efficient scientific programs may explore other language instead of Java.
5. Heavy Client Side Processing: Some of the Java based application clients use browser JVM, Swing, Applet etc. to render client side information. Still these do not use client processing power effectively. If the application permits use of client side processing, then you can go for an application that installs on each client and interacts with server for data and some specific processing. In such case the client – server technology of Java may fall short. Also it expects strong server side processing power.
6. Less Processing Power and Memory Availability: This is result of couple of points discussed above, but the truth is if you want to run an application requiring many enterprise services with very high performance, then you should be ready to invest in high end infrastructure. You can’t achieve it with tiny servers relying on high processing power of this language.
7. Technology Mismatch: This is applicable to any language suite. If your rest of the technology stack is from Microsoft then don’t introduce Java in between, there may not be seamless integration. Even if you try to do it, you will end up spending considerable effort unnecessarily. It is not only Microsoft but applicable to any other tech stack.