Open Software Integrators is an open source professional services company that provides consulting,training, development and support. Andrew C. has posted 5 posts at DZone. You can read more from them at their website. View Full User Profile

10 Things I Never Want to See a Java Developer Do Again

  • submit to reddit

Curator's note: Andy is the CEO of OSI (Open Software Integrators). He's a forward-thinker and exceptional blogger.

William F. Buckley, Jr. once said, “A conservative is someone who stands athwart history, yelling Stop, at a time when no one is inclined to do so, or to have much patience with those who so urge it.” I don’t know much about that, but I want to yell, "Stop!" at the hordes of Java developers doing any of the following -- or when I’m forced to do them.

0. Traverse a resultset and construct an object

while ( {
 String name = result.getString(“name”);
 String address = result.getString(“address”);
 String email = result.getString(“email”);
 String phone = result.getString(“phone”);
 stuff.add(new AddressEntry(name,address,email,phone));
So if you’re a hipster-developer, and not a professional, obviously ORMs are bad because you read it in some blog by a developer who once had a “performance problem” with Hibernate.  Hand coding this “obviously” makes it “better”, but surely you can use JDBCTemplate or something.  I’ll stick with JPA/Hibernate though thank you (cue the clueless flaming).

1. Write PL/SQL on a transaction system

Over time, your business logic will move into the RDBMS.  Your beloved device transaction will move to the database.  Someone will turn this into something resembling COBOL and tied to triggers that call other flattened out versions on a materialized view.  In other words, in a short period of time you’ll have the ultimate intractable legacy system.  This is good news for Oracle investors, but what is good for Oracle is bad for the rest of us.

2. Write/debug or even use a Swing application

For years I thought I was so horrible at GUI code that I should never touch a front-end.  As it turned out Java should never touch the front end.  Swing is slow.  Yes you can make fast Swing code if you’re Sun and writing NetBeans and don’t have to worry about browsers and can pour a lot of money into it....but Swing is slow.  It is also unpleasant and makes GUIs that by default look like a cartoon about native GUIs.  Then there is Java’s sandbox model...

3. Cast

Java Generics is not perfect or even the solution to the problem I would have preferred.  There are the occasional edge case that Java’s Generics can’t handle efficiently...

That said, I really don’t want to
Foo bar = (Foo) FooFactory.get(“bar”);
ever again.  Unfortunately, there are libraries that haven’t gotten the message and there is always legacy code, but let’s all be good little boys and girls and eat our vegetables, write unit tests and use generics.

4. Do date calculations with Calendar or Date

Life is too short to deal with complicated date/time calculations using the JDK Date and Calendar classes.   The built-in classes provide only the most primitive operations and are everything except intuitive.  Use a modern library like JODA Time.  Unless you’re the type who writes webapps in x86 assembler, in which case you might enjoy doing date arithmetic using the JDK Date and Calendar stuff.

5. Configure Session Replication

It is not 2000.  All of the distributed cache products and projects have rebranded themselves as NoSQL Key-Value stores.  Let’s use AJAX/Javascript if we need stateful clients and not use HttpSession for...anything.  This will make for highly reliable scalable applications that we can all enjoy and no more deep dark marshalling exceptions that go bump in the night.  Don’t get me wrong, this was a fun time, it bought my wife a minivan (I prefer my Ninja 650), but now it is time to make better, faster and smarter stuff.

6. Write a sort algorithm

Most of the horrible, I didn’t pay attention in algorithms class, sorting code is written by people that also didn’t notice that Java has the sort algorithm you need (or there is a third party library somewhere with your name on it) or they just didn’t notice how Comparable and Comparator work.  Go forth and read that now and commit the sin of self-sorting no more.

7. Write my own Linked List, Stack, Queue, etc

Admittedly writing a basic linked list is pretty durn easy.  Wikipedia has a nice page ( on linked lists with the code and all.  So yes, I could cut-and-paste, but why?  Maybe I’m just lazy, but I prefer using a data structure that has already been through the testing ringer.  No actually I am lazy, I go to great efforts to remain so.

8. Write my own pool, collection or general concurrency code

Know Doug Lea.  Love Doug Lea.  Be one with Doug Lea’s java.util.concurrent.  Doug Lea is not a mere mortal he is a highly parallel being capable of thinking the solution to any concurrency problem before you do. 

9. Deal with logging frameworks

How do you spell a word that means all of Commons logging, SLF4J, etc: S-U-C-K.  Sun caused this problem by not just taking Log4J’s interface into the JDK years ago.  Oracle could help fix it by making java.util.logging not suck.  That said, I’d rather everyone standardize on the suck that is java.util.logging than another person come up with another “brilliant workaround” for allowing us all to have “logging choice”.  “I’ll have a Coke”  “Is Pepsi okay?”  “Whatever, they both make you fat, what’s the difference?”


Published at DZone with permission of its author, Andrew C. Oliver. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Byron Palmer replied on Mon, 2012/10/22 - 4:29pm

0. I tend to agree here except that I _HATE_ hibernate. I do like MyBatis although there are some issues there as well. There are bugs but I have found the workarounds.
1. I tend to agree except that functions are useful when you have problems that cannot be solved easily using queries. These need to be kept to a minimum as well. I once wrote a full program in Oracle PL/SQL and ended up with a mess. Not only was it 100 times slower than the Java version I went to, it required stopping and restarting the server when an error occurred, related to the use of jobs.
2. I disagree vehemently with this. Swing or SWT/JFace works very well. You do have to know what you are doing, but that is true from any good programming challenge. The interfaces are not bad, they are as good as anything else. They are not slow! I have applications running in a call center where speed is everything. Doing this with web based programs would be a nightmare and would never work. This is just continuing to promalgate the idea that a Java GUI is bad. That was true early on in the evolution but is not so anymore.
3. Yes and no. I agree that your example is one that I wish I never saw again.
4. Agree totally, JODA is the only thing to use for time. Having worked in an industry where time is very-very important, using Date and Calendar is impossible. If I could I would deprecate both of them and insist on JODA.
5. Would be nice but you have to have clients and browsers that work. Both of which are in short supply.
6. Agree, although my sort is ...
7. Agree, although my list is ...
8. Agree.
9. Just use SLF4J and Logback and live with it. Yes, it is a pain that people use a variety, and sometimes it is a problem. But going with Java's logging is stupid and doesn't do what logging should do.

Toni Epple replied on Wed, 2012/10/24 - 4:59am

02: So you're saying we shouldn't use NetBeans or IntelliJ IDEA ("even use a Swing application")? Wow, that was something pretty stupid to say :-).

alfredo scotto replied on Wed, 2012/10/24 - 6:46am

I am fully with you and my list is much longer. Most common issues come from: developer writing code without think, the ones believe to be god and developers without the ability to read the code.

Nick Hellz replied on Wed, 2012/10/24 - 7:44am

On swing, if you're coding with swing today on a new application I feel sorry for you. So I would agree to 'don't do it', BUT it's by no mean slow at all. You want to see what slow is use a browser.

Stan Silvert replied on Wed, 2012/10/24 - 8:09am

I often disagree with you, Andy, but this is a nice list.  I'd say I mostly agree with 9 out of 10.  Pretty good.

 I was all set to respond to your Swing comments thinking I would be in the minority.  Everyone hates Swing, right?  Then I go on to read everyone else's comments and I see almost unprecedented praise.  After all these years will Swing make some sort of a comeback?  Did it ever really go away?

 I was a Swing developer for about one year back in the late 1990's.  Swing was young and tricky, but still better than MFC.  Since then I hadn't touched it.   Been doing the web thing like everyone else.

Then, I had a need for a fairly complex UI.  My choices were Swing or GWT.  I'd been using GWT for the past year, so I had the same amount of experience with each.   The difference was that my GWT knowlege was fresh.  But I took a look at the path I would need to go down for GWT and what I saw scared me to death.

So I literally went into my attic and found my old Swing books.  I had to refresh my memory using the books and then read articles on the web to see what has changed in the last decade.  Boy, am I glad I did.

It turns out that this dinosaur called Swing is pretty awesome.  My GUI is fast and responsive.  It was super-easy to code.  I can't remember when I was so happy with how my code turned out.  Who would have thought that Swing would be like a fine wine, getting better and better with its age?


Manuel Ferland replied on Wed, 2012/10/24 - 9:07am

1) Tom won't agree :)

There are always two ways to solve everything: the easy way and the hard way. Solve problems as simply as possible, using as much of Oracle’s built-in functionality as possible. You paid a lot for it. 

See: Expert Oracle Database Architecture by Thomas Kyte. Chapter 1 Developing Successful Oracle Applications for an interesting point of view.

2) Like cobol, there is and will be swing application for a while. It's more a question of having the right tool for the right need. In real world applications swing speed is the least of your concern. You'll have more problems with bad generated SQL! Even if it's does not look like, good web development is not easy thing, even more if you stack frameworks like seam/jsf/ajax4j/richefaces/facelet/... it's getting ridiculus.

Manuel Ferland replied on Wed, 2012/10/24 - 9:10am in response to: Stan Silvert

I agree

Aurelian Tutuianu replied on Wed, 2012/10/24 - 10:03am

Stable sorting, linear sorting, severe constraints on memory used and there are few more are good enought reasons to think again. Of course, when you are dealing with tens of rows from a relational database like it seems to be your case, you can live without knowing algorithms. There should be somehow somewhere some libraries made by some dudes who test and think for you, right?

Jack Sparrow replied on Wed, 2012/10/24 - 10:54am

I mostly agree with other points but could someone please provide details about what are the alternatives to Session Replication. With Ajax calls we still need authentication mechanism like httpsession. How can we achieve stateless web apps with Ajax/JS? Any pointers to frameworks, examples would be great. Thanks.

Jeff Kesselman replied on Wed, 2012/10/24 - 11:26am

You may never want to see these... but there are very leigitamte reasons for most if not all of them...

(0) Orms are convenient, but they inevitably fall down or get in the way when dealing with applications that have to be tuned.  My last contract in fact was primarily re-writing all the Hibernate in a Grails app to pre-prepared JDBC because Hibernate's use of JDBC was too unoptimized for the big data volume we were dealing with.  Tthis was a game statistics tracking back end for a massively multiplayer casual game.)

Converting the results from a result data set into an intemediate representation can be a perfeclty valid way to prevent abstraction leakage of your table schema into the rest of your app.

(1) I havent written such a  system so I can't comment.

(2) I am sorry if you or your developers don't know how to write efficient Swing code, but the information is available and has been for a long time.  I suggest you read the book I wrote a decade ago which many developers have told me helepd them immensely in this area.  It used to be directly available from Sun's website but Oracle semes to have taken it down.  This seems to be a downloadable copy (I knwo nothign abotu the source):

Alternately there is an update that was written by some other folks that I hear is quite good:

(3) Using generics when they make sense I would agree is a good thing.  However there are some edge cases where an Object class type IS still necessary or appropriate.  If you have a mixed-type data structure, for instance.  Or where you are simply passing through an object whose value your code neither knows nor cares about.

(4) *shrug* they have always been enoguh for me. Frankly, i think relying on a lonf list of external libraries is its own form of maintainence challenge both for code and documentation, and I prefer to use core classes wherever its reasonable to do so.

(5) no experience, no opnion

(6) Yes, agreed, see 4 above.   

(7)  Partially agree. again there are legitimate times for this.  The default Java colelctions for instance are very fast but scale horribly memory-wise.  If thats an issue you may want your own. Similarly if you need gauranteed semantic behavior beyind what is specified in the API docs you will need to write your own.  But if you do, Id say please base them off of the existing interfaces, exntended if you have to, and use UnimplemenetdOperation exceptions for those calls that may not make sense in your implementation.

(8) Doug's libraries are nice.  They are also a  fairly recent addition to the JDK. Lots of legacy code existed that didnt have acess to his classes.  Having said that, Doug's classes don't ensure multi-threaded correctness. Its quite easy to use them wrong if you dont understand the principels on which they are based.

(9) One of MY pet  peaves is people who go off adding additional libraries where they duplicate core functionality and logging is a primary culprit.  i have yet to meet a logging situation that wasn't adaquately covered by java.util.logging. And when different libraries use differnt loggign solutions, maintainence becomes a nightmare.  Love java.util.logging.  Its all you really need and then all your logging will be through one mechanism and in one place. 

Yeshwant Nandi replied on Wed, 2012/10/24 - 3:00pm

Tom Kyte is legendary and has a huge following on his famous site

 For those of you from the hard-core Java world, Please read the below conversation on his site on this debate between J2EE and Oracle.   You could ask him questions for further clarifications. He is brilliant.



Lazzari Daniel replied on Wed, 2012/10/24 - 3:37pm

4- Depends on how intensive is your use of this type of calculations. I really don't need another dependency on my project for something this trivial.

Nicolas Bousquet replied on Wed, 2012/10/24 - 5:11pm

Honestly you have good point but this really look like a rant and a little biased. There many case where what you don't want to see is perfectly correct.

There only point 4) and maybe 1) that I see as always valid. (Althrough using hibernate is as messy than the first code). Other case all have legitimate cases. It all depend of the problem domain. So yes depending on the context this is good or bad advice.

 That a big problem when people start to uses rules. Do this, do that. Don't do this, don't do that. In the end, they don't think anymore and will manage to make weird things with advice applyed without caution.

 So favor thinking and good design. Don't judge in advence what others should do or not.

Horse Badorties replied on Thu, 2012/10/25 - 1:58am in response to: Jack Sparrow

Store all state in an encrypted blob cookie.


Jim Page replied on Thu, 2012/10/25 - 11:41am

Number 5 " no more deep dark marshalling exceptions that go bump in the night" is funny.

A lot of these are good, but is sure is fun to write and rewrite my own linked list, binary search trees, and sorting algorithm in different languages. Really, we should all get converted to C. No, what we should do is pool all of our libraries together into a world wide repository, remove all copy rights and call it JavaUnity.jk

Maybe there is an article out there on the top ten things to become a better programmer. There probably is if I would just look. Would it include a code optimizer and a decompiler. I dont know much about those. I have heard that a person should use the code optimizer and then decompile your code and see how differently it is organized.

Raging Infernoz replied on Tue, 2013/01/01 - 10:21am in response to: Mark Unknown

 There are BIG problems with stored procedures; these include:

  • Complex non-modular code which can be very hard to read and write.
  • Ironic limits on the size of SQL statements which can be built and executed by some databases (MS SQL Server), due to pathetic text data type capacity.
  • Poor or no logging of SQL and execution.
  • No code tracing which I am aware of.
  • You still have to do post processing on data because of the limits of SQL and the stored procedure language(s) supported by a specific database.
  • Not database portable, and some database don't even have usable stored procedure support; this is a killer.

Raging Infernoz replied on Tue, 2013/01/01 - 11:18am in response to: Jeff Kesselman

Re: 8

Doug provided external non-generic versions of his classes for pre-1.5 JVMs; these have been available and maintained for years.

Re: 9

Yes, using a logging API is a good idea; however java.util.logging is a pointless copy of Log4J, which has been replaced by the SLF4J logging facade and logback; fortunately SLF4J has logging bridges for legacy logging APIs, including java.util.logging.

Bruce Patin replied on Thu, 2013/04/11 - 10:12am

I judiciously use stored procedures to greatly simplify my non-database code and speed up performance of the app, often as much as ten times.   It makes it worthwhile to write them for your database, even though it makes it a little more difficult to migrate to another database vendor.  But even that can be done.  Oracle, SQL Server, PostgreSQL and MySQL all have equivalent capabilities, and it is not all that difficult to convert stored procedures from one to another, without having to rewrite your app.  Sometimes, to make the best use of a database requires use of transactions, joins, sub-selects and functions, but you almost never want to code that kind of logic in an application, where it can get horribly obscure or messy and often incredibly slow.  It is usually much more efficient to find such logic in one place in the database, rather than have to spend days browsing through application code classes to figure out how it works and how to change it without breaking something that you missed, then recompile and deploy it.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.