I’ve been a professional programmer for over three years now. I have worked on projects both large and small, ranging from Java Web Services to Perl-CGI, J2EE web sites and JavaScript prototyping. I can say that i’m experienced enough to know how to approach most aspects of the programming-industry and work related issues. This said, I am going to explain why I think the Java programming language is now obsolete, in an industry ripe with languages new and old, useful and stupid.
Background
Before I start, I want to explain my programming background with Java and other languages, so this post isn’t regarded as Just Another Flame ™.
I am a Sun Certified Java Programmer, and have been contracting for 3 years here in the UK. I have worked for two large companies (no names) that have given me excellent experience with the Java programming language and its use in the Enterprise tier. As well as Java, I have been required to develop in SQL (both Oracle and MySQL, as well as MS-SQL), Perl (CGI and scripting), BaSH and the usual web design/development languages HTML, Javascript and CSS. I have recently taken to learning Python, the high-level dynamic object oriented programming language, and doing so has prompted me to post this article.
Common Misconceptions
A lot of the Java doubters out there tend to blow the same trumpet; sing the same tune; fuel the same fire – that is, they all say ‘Java sux!!11′. The problem with this, is that Java is all of three things: a programming language, compiler, and virtual machine/interpreter. This means that those blabbering on about how ‘Java sux’ don’t direct their comments at what particular part they dislike; that is whether they hate the language itself, the compiler or the interpretor. Not only is this an inaccurate flame, but it’s usually bellowed by those who have very little to no experience with the programming language or its uses. At best, they’ve tried to run a Java program and due to their own lack of understanding or misconfiguration, it hasn’t worked. However, some people who flame it do know the language and its software components and therefore have an educated opinion. I prefer, and indeed regard myself as, the latter.
One of the other wondrous clauses that Java-haters tout, is that it is slow. Well, they’re mostly right. Again there’s more to it than just speed. The first releases of Java were very slow. Fact. However, the latest releases (Java 5 & 6) have added language features that speed up the run-time execution of Java code – namely parameterisation of types, auto boxing/unboxing of primitives to objects – by forcing compile-time checks as opposed to run-time checks of types (the old object cast when adding/retrieving to/from collections is now unnecessary). Whilst these features do speed things up, Java is still relatively slow.
Now, on to the flame…errr, constructive criticism.
Java’s too Strict
Java has prided itself on two things – strict object orientated design (OO) and ‘Write Once, Run Anywhere’ multi-platform availability – and has been both accepted and rejected on the merits/pitfalls of these features. I don’t actually see anything wrong with OO design. In fact, it’s my preferred software development approach. The issue with Java’s strict OO design, is that it’s very difficult to program otherwise. You’re forced to stick to OO practices whether you’re writing a quick hack, or a fully-fledged framework, and this forces its usefulness to be restricted. This isn’t the case with Python. It’s so dynamic and productive to write, that it can be used to write a quick backup script or large back-end services.
Java is also a strict-typed language. This means that at instantiation, objects are given a type (or ‘class’) and the compiler enforces this. If an object needs to change type, it must do so through the ‘Polymorphism’ object oriented design approach. This is enforced by Java at runtime. It’s another extension of Java not allowing you to make the decision over what software design approach you’re going to take – procedural or object oriented – so you’re stuck from day one. Languages like Python and Ruby are not strict-type. This means the programmer has more flexibility (but has the overhead of ensuring specific types at runtime, and checking thus) over how specific aspects of a program treat information.
Java’s too ‘wordy’ – a.k.a Verbose Syntax
The nature of OO design means that more code is written to define objects and their relative connections. Java does this well, with a nice object hierarchy, but it’s a victim of its own design and conventions – accessors/mutators (‘getters’ and ’setters’) mainly – whereas in languages such as python, the convention isn’t to use this approach, but to expose an object’s properties either by direct dot notation, or to define it as a dict. You can still do this in Java, but obj['val'] is much easier to write than ‘obj.getValue()’. You might see this as a moot point, something that’s purely implementation specific, but in reality anyone that knows how to write Java, will stick to the strict convention that objects should hide their underlying implementation. This is definitely a good approach to software design, but in practice it becomes too much of a burden on a programmer to write and use such design aspects. Not to mention it doesn’t bode well with the 80 character per line rule…
Another example of Java’s ‘wordy’ syntax is the Collections API. Once touted as its glorious achievement, the Java Collections API was an outstanding set of objects aimed at providing objects – an extension to the typical array – that provide easy, OO and fast access to a collection of objects. With the emergence of other languages however, the Java Collections API has become rather stagnant due to the language’s lack of dynamic syntax. Below are two examples, one of defining and iterating over a list in Java 1.5 and the other iterating over a list in Python 2.5:
List<String> list = new List<String>();// define a List that contains only String objects
list.add("Herro");
list.add("Moo");
list.addAll(myOtherList);
for (String str : list)
System.out.printf("Item: %s\n",str);
And the exact same operations in Python 2.5:
list = ['herro','moo']
list.extend(my_other_list)
for item in list:
print "Item: %s\n" % item
4 lines of code, or 6? Stretch that out over a large application (what application these days wouldn’t use lists or maps?), you can see that code written in Java would become quite large, purely because of the language’s syntax. Programmers like to program, they don’t like having to write more than they need to. Python allows you do write exactly what’s needed, and without having to write 100 words to do so.
‘Write once, debug anywhere’
The ability to run an application on any operating system without the need to recompile is a nice idea. Java’s main selling point is that it has this ability. Initially this was a useful and much desired feature of the language because not only did it work, but it was at an age where the Web was booming (pre-2000) and new technologies were on the uptake. Nowadays, the platform is the Web. This means you don’t necessarily need inter-platform abilities from a language and compiler/interpreter. You just need a working web browser, and an internet connection. Indeed, with the rapid adoption of AJAX (Asynchronous Javascript and XML), web sites are now replacing the desktop application. Software As A Service (SAAS) is now the forefront of software development and business aims, and the need for desktop applications becomes ever smaller as more and more websites offer an abundance of features from the web browser – just checkout GMail, EyeOS or Google Maps – and you’ll experience feature rich applications, all in the comfort of your web browser.
What’s next?
Undoubtedly Java will remain a large part of the industry for the next few years. Sun are a large and powerful company, and are good at keeping things alive. Not only that, but they’ve recently released Java under the GPL , so it’ll be around for a while yet. Some might say that this was part of a clever marketing campaign to get people back in to using Java. Either way, I can really only see its demise as more dynamic, open source, reliable technologies take the driving seat.
Java still has a large place in the enterprise market. According to this site, it’s the number one language (in terms of job opportunities, third-party vendors and courses); but as with all statistics, i’d take that with a pinch of salt.
Summary
I’m not a Java-hater. It’s paid my bills for the past few years, so I owe it some credit. Due to my recent adventures with Python though, I immediately saw the flaws in Java. Python makes things quick to write. It’s powerful, ever maturing and more to the point – it’s open source. I think Java will stick around for the foreseeable future, but its original merits are no longer going to keep it alive…
12 Comments
I’m in the same boat as you. Java paid the bills for a few years, but once I discovered Ruby and PHP, there was no going back. Java is adaquate for a monster enterprisey application server project with 10+ developers, but its just too restraining for small projects or web projects.
I almost in the same boat.
But I can’t say PHP (at least until version 4 which is the one I’ve been using) is any good.
It leads to much to bad habits and is , at least to me, error prone ..
I love python tho .. I wish I had a project that required me to do something with “THE” language.
I still like C++ and Java tho.
1. “The first releases of Java were very slow. Fact. However, the latest releases (Java 5 & 6) have added language features that speed up the run-time execution of Java code – namely parameterisation of types, auto boxing/unboxing of primitives to objects – by forcing compile-time checks as opposed to run-time checks of types (the old object cast when adding/retrieving to/from collections is now unnecessary).”
Those runtime checks are still performed. The language features compile into the same runtime-checked code that it always compiled into. The performance improvements in Java 5 and 6 are due mainly to a smarter VM and optimized library code, mainly in Java 2D (thus affecting swing).
2. “Java does this well, with a nice object hierarchy, but it’s a victim of its own design and conventions – accessors/mutators (’getters’ and ’setters’) mainly – whereas in languages such as python, the convention isn’t to use this approach, but to expose an object’s properties either by direct dot notation, or to define it as a dict.”
Neither getters and setters nor exposed properties are OO. They are used in Java to write procedural code (a method operating on an external data structure’s properties). The OO equivalent would be to put the functionality, or at least the portion of the functionality requiring the object’s properties, IN the object itself. There are various design patterns that can maintain separation of concerns while maintaining encapsulation and I won’t open that can of worms here…
3. “And the exact same operations in Python 2.5:
list = ['herro','moo']
list.extend(my_other_list)
for item in list:
print “Item: %s\n” % item”
And again in Java:
Collection list = Arrays.asList(new String[] {“herro”, “moo”});
list.addAll(myOtherList);
for (String item : list)
System.out.println(“Item: ” + item);
The Java code is approximately as terse yet far more powerful than the python code. First of all, the Collections API allows many implementations of collections to be used interchangeably. It is a library-level feature, not a language-level one, so users can create their own collection implementations on the fly. Secondly, the one reason the Java code above is more verbose than the Python code is that the Java code has words where the Python code has syntax. Words are descriptive and are library-level, meaning more general than language-level features. For example, I could replace Arrays.asList( with another method call that returns a different type of collection; the same cannot be achieved as elegantly with language-level features.
4. Java code is insanely easy to port. I write programs on my mac and run them on Windows without any trouble. There are a few corner cases such as headless mode and file paths, most of which are completely portable if used correctly.
1.) Those runtime checks are still performed. The language features compile into the same runtime-checked code that it always compiled into. The performance improvements in Java 5 and 6 are due mainly to a smarter VM and optimized library code, mainly in Java 2D (thus affecting swing).
Interesting, can you prove this please?
2.) Neither getters and setters nor exposed properties are OO. They are used in Java to write procedural code (a method operating on an external data structure’s properties). The OO equivalent would be to put the functionality, or at least the portion of the functionality requiring the object’s properties, IN the object itself. There are various design patterns that can maintain separation of concerns while maintaining encapsulation and I won’t open that can of worms here…
I was actually referring to the issue with the Java conventions (bad sentence structure, perhaps). Technically the use of getters/setters are encapsulation.
3.)
Collection list = Arrays.asList(new String[] {"herro", "moo"});
list.addAll(myOtherList);
for (String item : list)
System.out.println("Item: " + item);
The Java code is approximately as terse yet far more powerful than the python code. First of all, the Collections API allows many implementations of collections to be used interchangeably. It is a library-level feature, not a language-level one, so users can create their own collection implementations on the fly. Secondly, the one reason the Java code above is more verbose than the Python code is that the Java code has words where the Python code has syntax. Words are descriptive and are library-level, meaning more general than language-level features. For example, I could replace Arrays.asList( with another method call that returns a different type of collection; the same cannot be achieved as elegantly with language-level features.
Not only is that code awful to read, but it is inherently going to be slower than using the language feature that is parameterisation – you’re converting an Array to a collection (although the asList() method is probably optimised heavily) as opposed to just creating a list directly.
You can also define user-level dicts/lists yourself in python by extending the relevant built-in types.
4.) Java code is insanely easy to port. I write programs on my mac and run them on Windows without any trouble. There are a few corner cases such as headless mode and file paths, most of which are completely portable if used correctly.
Yes, it is easy to port. Trouble is, who does it nowadays?
First of all, sorry if I was abrasive in my initial post.
1. “Interesting, can you prove this please?”
From http://java.sun.com/j2se/1.5.0/docs/guide/language/generics.html :
“Generics are implemented by type erasure: generic type information is present only at compile time, after which it is erased by the compiler. The main advantage of this approach is that it provides total interoperability between generic code and legacy code that uses non-parameterized types (which are technically known as raw types). The main disadvantages are that parameter type information is not available at run time, and that automatically generated casts may fail when interoperating with ill-behaved legacy code. There is, however, a way to achieve guaranteed run-time type safety for generic collections even when interoperating with ill-behaved legacy code.”
From http://java.sun.com/j2se/1.5.0/docs/guide/language/autoboxing.html :
“The performance of the resulting list is likely to be poor, as it boxes or unboxes on every get or set operation. It is plenty fast enough for occasional use, but it would be folly to use it in a performance critical inner loop.”
The above is not a proof, just an indication, but other sources such as http://www.jroller.com/voidmain/entry/jdk_5_auto_boxing_best strengthen my argument.
2. “I was actually referring to the issue with the Java conventions (bad sentence structure, perhaps). Technically the use of getters/setters are encapsulation.”
The following is my opinion… Getters and setters encapsulate fields. However, they don’t encapsulate the data structure of the object. A more object-oriented API exposes functionality instead of data. Then, subclasses can use polymorphism to perform different functionality by overriding the functional methods and those methods can operate on whatever data the subclass happens to store internally, leading to greater generality of any code using the class. The primary purpose of object orientedness is to allow reusable black box components in this way. Many people are so accustomed to getters and setters that they write them automatically. That habit is the fault of the programmer and I don’t think it should reflect badly on Java.
3. “Not only is that code awful to read, but it is inherently going to be slower than using the language feature that is parameterisation – you’re converting an Array to a collection (although the asList() method is probably optimised heavily) as opposed to just creating a list directly.”
Arrays.asList creates a list backed by an array, meaning the collection wraps the array instance and delegates to it. The list should be at least as fast as ArrayList – it’s about the fastest and simplest list implementation possible other than Collections.emptyList(). I would imagine that Python converts your special syntax into an actual object and thus does something similar. I don’t see why Java would perform worse. Of course I don’t know what’s going on under the hood…
4. “Yes, it is easy to port. Trouble is, who does it nowadays?”
A lack of porting isn’t necessarily a fault of Java. Also, some of the apps I use are Java and all are cross-platform. I use Eclipse, NetBeans, IntelliJ IDEA, and core Gnutella library written in Java; all are cross-platform. Also, most popular Java programs, like Azureus and LimeWire, are cross-platform. I develop Java apps at work on Windows and they’re deployed on Red Hat. I could also work on them at home on my Mac too.
J:
No offense taken, it’s an interesting subject and it’s great to get feedback and different views.
1) ““Generics are implemented by type erasure: generic type information is present only at compile time, after which it is erased by the compiler.”
Very interesting indeed. Could it be that Java’s a victim of its own success – legacy interoperability causing slowdown for future features – and thus confirming my “Java’s slow” point? Admittedly, this was not my original intention, but you’ve certainly proved your point (and helped mine along the way, perhaps).
2) “Getters and setters encapsulate fields. However, they don’t encapsulate the data structure of the object”
The problem with this subject and resulting arguments for either case, is that the specifics are implementation dependent. Getters and setters could be used for pure field access (a.k.a. Java Beans), or to wrap access to maps or lists within the object (though the Iterator design pattern would be best here, along with extending Map/List). It may have been more beneficial for me to include a larger example.
3)
The issue isn’t performance here, it’s the amount of code you have to write in Java to do the simplest thing with list/map types. Python exposes these language features quickly and easy.
4)
Interestingly, we’re in a very similar situation. The client I currently work for has the same setup: Windows developers (writing Java) and the site being deployed on a Red Hat server. The point though, is that this doesn’t really exercise the multi-platform interoperability well. Most releases tend to be built on or for that platform. The multi-platform abilities of Java were mainly aimed at desktop applications to bridge the divide in the desktop market. I don’t deny server-level aims by this feature of Java, but this wasn’t my point; hence the discussion of Ajax and the web being the platform.
Thanks for your comments and for reading. It’s an interesting topic and it’s great to get feedback.
Cheers!
i’ll stack my 25 years in IT against anyone’s three years – or ten years – any day. suffice it to say i have been everything from programmer to CIO with projects ranging from three developers to over 40.
what seems to be overlooked in all of the discussion is the development and use of tools which generate most of the code. programmers debating the “efficiency” or “work” to write 4 lines of code versus 6 lines of code have missed the more important issues altogether: maintainability, interoperability, and portability.
20% of the cost of an application is the development. 80% of the cost is lifecycle costs after deployment.
java addresses all three of these key issues. WORA clearly addresses the portability issue – for a price. applications do run considerably slower because the byte code is interpreted by the jvm rather than having binary code fed directly to the cpu. for web based applications, the performance considerations are minimal. where performance does matter, there are java compilers availble – at the price of portability.
strong typing helps enforce good design. good design improves maintainability.
java has a strong framework with good implementations for interoperability. few developers ever work with enough complex applications to get into JNDI and related areas, but Java’s interoperability is another strong point where it leaves most other applications in the dust.
getting one’s head above the computer screen long enough to see “the big picture”, one should be able to gain some perspective about what makes Java a strong solution in the enterprise well beyond lines of code and functional versus OO.
let the tools write the code.
don’t be a tool !
Can anyone do anything USEFUL with object-oriented programming? In 2005 I beat my brain to learn C++ for the first time at a local community college in their Introduction to Computer Science course and its sequel. I earned A’s in both courses. In 2007 I studied Java on my own. I read an entire book on Java. I wrote sample practice programs with the help (and punishment/derision0 of my older brother,
a pro-Java fanatic.
However, I feel I simply cannot get into object-oriented programming (OOP), even though I marvel at its structure.
For ALL of my computational needs spanning my entire life – beginning in high school when I touched a computer for the first time for word-processing project, through my first FORTRAN course in 1981 at the same community college where I would take C++ 24 years later, through chemical engineering courses where I wrote and ran FORTRAN programs, and a physical chemistry course where I programmed a TI-59 calculator to its maximal capabilities – to my work as a chemical engineer at Rohm & Haas chemical research plant where I did a few computations using SAS (statistical analysis system) through my 12 years as a mathematics graduate student, earning a PhD in Math in 2000 – using MS Word and Mathtype and a little Mathematica computation to put together a 275page dissertation – as both a fulltime and parttime professor of mathematics -
to one week of work in 2006 at a casino slot machine testing facility where I computed odds and payouts on an Excel spreadsheet -
to a homework assignment on molecular modelling in 2008 in which I used Maple computer algebra system to compute electron orbitals -
when I actually have to do the REAL practical useful computer work – the work which gets evaluated and graded or paid for – NOT ONCE have I used C++ or Java or any other form of OOP (except, of course, for the 2 C++ courses I took).
Oddly, OOP has inspired me to create innovative mathematical models of game theory – competition, war, etc – because of its way of organizing the universe. But the inspiration for me is still on good old paper (or, rather, in an MS Word document stored on the computer). OOP has not inspired me to do more computer programming.
I know that every individual’s needs are different. Each individual needs to use the right tool for the job. So, I shouldn’t feel guilty about not having made any use of OOP and of Java in particular.
But, what I want to know – does ANYONE in this world have a job where they get paid money AND where they HAVE to use some form of OOP or Java for their job?
I published my 6th math paper this year, and I am energized to write more – although I am terribly stuck on how to get the thoughts from my brain to the page.
sorry, the link ought to be:
http://vijaymathew.wordpress.com
Hi John.
Firstly, thanks for reading and taking time to respond.
I work for one of the largest insurance and breakdown providers here in the UK, and we use Java exclusively for our Web tier, and the majority of the business layer systems. I spend a decent amount of time at the beginning of any large project designing my classes using UML and ERD (for DB related matters), and this is a constant thing.
It sounds like you’re doing a lot of mathematical related development, where things are probably more procedurally structured in terms of logic. Whilst I’m sure there’s a lot of use for OO in the maths software development field, I am inclined to think that the tools/languages you use such as FORTRAN do not provide the features that you’re looking for. Without seeming blunt or rude – perhaps a change of employment setting might provide you with a means of gaining experience on a day-to-day basis with not only Java, but OO design and implementation.
Failing that, there are plenty of open source projects that will use OO as their development approach, so perhaps looking for a project on sourceforge.net or Google Code might yield something along those lines.
There’s no right or wrong with all this. Like you’ve said, OO is one approach and we all use the tools we need to get the job done.
Cheers,
Placid
Placid,
Yes, a change of employment setting would be nice. Unfortunately, there are no paid jobs anywhere in the world, especially in the USA.
My life’s goal, ever since I was a kid: to be a bionanotechnologist. To all my math and science and engineering to use in genetic bio-nano-engineering. Regarding the right tool for the job, for the ideas I hope to see realized and things I want to achieve, math is still 99.9999% of the work ahead of me. Computer programming it afterwards accounts for only 0.0001% of the work.
I don’t mind Java at all. I think it’s a great language and some of the apps written in Java are fantastic. I also like C and C++. However, I have one criticism of Java developers: Everything is Java! Let me explain. Why in the world would you want to develop a web app in Java? Hmmm? What advantage does running Tomcat give you? I know, I higher salary. There may be an exception with some massive enterprise web application. Though, I do wonder if the same thing can be written in PHP.
I think the main drawback of Java for web apps is that they are compiled. I just want to log in from my Iphone and make a quick edit. Hmmm… Not really quick…
Here is an example: How complex is a Java CMS vs. a PHP CMS? How portable is it? Usually the PHP app is more portable. Weird huh?
2 Trackbacks/Pingbacks
nice site d00d…
heres mine…
[...] So do I have a point or is this just a rant (and certainly one that is not as erudite as many have written)? [...]
Post a Comment