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.)


Pavel Bernshtam replied on Mon, 2012/10/15 - 10:03am

Swing is slow ... What do you say to C++ programmers, who claim that Java is slow? Swing is not slow, but requires many hardware resources (as Java BTW) Swing is slow if you do not know how to use it.

Mark Unknown replied on Mon, 2012/10/15 - 10:22am

Funny that you nip ORM discussions in the bud by saying "...obviously ORMs are bad because you read it in some blog by a developer who once had a 'performance problem'..."

and the proceeded to talk about Swing.  So what do you use for Java UIs? JavaScript (slow, non-native, ugly unless you have killer design skills...)?  SWT/JFace? Not a bad choice, but it comes with its own set of issues.


Other than those comments ... pretty much agree. 



Dapeng Liu replied on Mon, 2012/10/15 - 10:23am

not fully agreed on point 0, right tool for the right job there is not one size fit all

for swing, netbeans is no where near "slow"  

Jonathan Fisher replied on Mon, 2012/10/15 - 10:25am

Yes to all of them. 

The only one I can possibly let slip by is #9: SLF4J has a default mode where you don't have to configure it, making most the given argument invalid. Even though JUL sucks big time, it does have a major advantage being intergrated into the SDK.

Joe Attardi replied on Mon, 2012/10/15 - 1:36pm

Another clueless rant against Swing. You don't have to be Sun to write fast Swing code, you just have to understand how Swing works. Give me a break.

Joe Attardi replied on Mon, 2012/10/15 - 1:36pm in response to: Pavel Bernshtam

I'm glad I'm not the only one that was bothered by the Swing comment.

Fabio Canepa replied on Mon, 2012/10/15 - 3:26pm

Not fully agree on point 5. How do you implement authentication on your webapp ? Do you store userSessionID on the client side??

Mark Unknown replied on Mon, 2012/10/15 - 3:49pm in response to: Fabio Canepa

He is mainly talking about storing state in a session, not really about keeping a session so you know somone has been authenticated. That being said, think about mobile applications that use JSON services.  I stay logged in for days in mobile apps...

Lieven Doclo replied on Mon, 2012/10/15 - 5:00pm

"It is also unpleasant and makes GUIs that by default look like a cartoon about native GUIs". By default, maybe... But who uses the default LaF anyways? Look at this: I can honestly say I've seen native apps looking a lot worse than that. Do some research before you start ranting. Most unresponsive Java Swing apps are caused by developers not understanding or unwilling to understand even the most basic Swing concepts, such as the EDT. Slow? Mayble that was an argument before Java 6, not anymore. So Andy, here's an addition to your list: Not doing any research before a rant.

Logging does suck, but at least both JBoss logging and SLF4J have API's that don't incite suicide. Every time I see java.util.logging code, I tend to search for a gun...

Allen Chee replied on Mon, 2012/10/15 - 9:21pm

0, 1 - Agree

2 - There's still a need for GUI desktop applications. If not Swing, then other technologies also have pros n cons. At least Swing is in core Java and widely understood (debated, workaround-ed, best-practiced etc)

3 - Real developers need to deal with legacy codes which will still need casting

4 - Fair enough

5 - Depends on project needs

6, 7, 8 - Agree!\

9 - Save time, just use SLF4J/Logback 

Ramesh Kapa replied on Mon, 2012/10/15 - 9:39pm

You should definetly be having problems with GUI code. Swing/JavaFx is Coolest and Cheapest than any other GUI techs out there.

Andrew Oliver replied on Tue, 2012/10/16 - 1:24am in response to: Mark Unknown

I don't think Java is a great thing to write UIs in anymore.  Oracle is pretty clear that JavaFX is the future  However when I watched this stuff demoed recently at the Chicago Java Users group (we have an office in Chicago and I split my time between our Durham, NC office, our Chicago, IL office and our likely third location Los Angeles, CA) I kept thinking "looks better in JQuery and is easier to do" after each demonstration.  I also kept thinking "reminds me of the SwingSet demo 12 years back".  

The same lack of killer design skills caused me to make applications in Swing that didn't look like I had killer design skills.  I still don't make applications in jQuery that look like I have killer design skills.  However, they're faster and don't require any plugins.   

I also am not bullish on fat clients generally though: 

Jilles Van Gurp replied on Tue, 2012/10/16 - 3:26am

0) Well, if you had a hibernate monkey design your database, you pretty much have no choice to use it or refactor it to somthing more sane/appropriate. Otherwise, hire somebody competent to do your stroage layer and don't spend 80 percent of your project budget on doing stupid crud related things. In my book that means json in a text column plus a hand ful of columns I actually query on. Whether you use a mapper on the actual json is a matter of taste, personally I prefer to just hand it off to the frontend, which is of course javascript based. It's funny you should mention hipsters. Hibernate used to be very much a hipster thing. Now it's the boring old conservative option with a rapidly shrinking group of people that are competing with the cobol crowd for hipness. Go figure.

1) No argument on that. If you use Oracle, you deserve what's happening to you. It's like dropping the soap in a prison bathroom on purpose.

2) Is this still happening? I'm shocked.

3) If you get bogged down in generics and obscure compiler issues, maybe it's time to switch languages to something with type inference, closures, etc. I'm not a scala fan but there are alternatives to Java's crummy old type system. I find not doing a lot of stupid model classes helps keep things somewhat sane here (see 1).

4) Right tool for the right job. Personally, I don't spend a great deal of my time doing date manipulation. Whatever you do here, make sure you have unit tests.

5) Wow, sessions. Are people still using those? Definitely don't do that indeed.

6) It depends. Sorting gets interesting when you have a lot of data. But yeah, needlessly reinventing wheels is not high on my list either.

7) Use guava. The collections framework is an important reason why stuff like that exists.

8) Definitely use something off the shelf. Best to try avoid baking concurrency into your system at all. Java architecture is biased towards working in a way where it seems like there's no way around the fact that you need pooling, synchronized access, etc. A lot of other languages manage to scale without this complexity. Worth taking a look at that. If you are stateless and single threaded, you don't need to deal with concurrency and you scale by adding more (micro) processes.

9 Ignore Sun and their java.util.logging (JUL) and use something that decouples API usage from log configuration. This is the key feature you are after: it gives your operations people the freedom to do what they need to do. Slf4j provides all the bridges you need (commons-logging, log4j, etc.) and is very convenient for integrating legacy code and code that just insists on using JUL, log4j, or commons-logging. Basically, unless you don't care about logging, you'll want to have something capable on the configuration end at least (i.e. anything but JUL). In any case, some people confuse logging with debugging. Good code is silent. I don't understand why people feel compelled to litter their code with debug and info logging. It's an anti pattern really.

Mark Unknown replied on Tue, 2012/10/16 - 8:18am

"I kept thinking "looks better in JQuery and is easier to do" after each demonstration.  "

I've looked at most JavaScript UI libraries.  While they are better than raw JavaScript and they might look better than Swing, but in the end... they still use JavaScript - difficult to maintain and creates an "impedence" mismatch if you dont use JS on the server.  Additionally, with most you have to use CSS to make it look even half way decent (some have a standard L&F) - and CSS does not make it easy on you. 

For instance, I was looking at YUI, Sencha, Enyo (etc). I was just trying to get a basic app talking to a JSON service and some navigation. While I got at least one of those sort of working working - it took a while and lots of ... well lets just say I had lots of confessing to do. I have just started looking at CodeName One. Within short order I had screens and was navigating and was getting data. 


"The same lack of killer design skills caused me to make applications in Swing that didn't look like I had killer design skills."  You dont need any design skills with Swing. Apply a L&F. Sure you need to lay things out.

 "However, they're faster"  - Faster to code? Not for me. Faster to run? Its JavaScript

:"and don't require any plugins. " Swing does not require plugins. JQuery might not require plugins, but it has them 

"I also am not bullish on fat clients generally ".  I understand this from a deployment standpoint. But if you look at the mobile market and what Apple and Microsoft are doing with their app stores, I am not so sure.  If you ignore deployment, "fat" clients are, for the most part, much easier to develop and maintain.  HTML5/JavaScript are another set of tools that are, sometimes, the lessor of 2 or more evils.  I know some apps will require this type of UI. But it is the future for all UIs, then the future is mighty depressing.

 I went and looked at the link you posted and some of your comments (When you print a PDF in the browser ... You are using a "fat" client). Also, if you look at some of the comments ... HTML5/JavaScript is effectively a fat client. Just without the benefits. :)



Yeshwant Nandi replied on Wed, 2012/10/17 - 10:41am

Do not agree to point 1.   The Database is not a DATA DUMP.   The Relational Database technology (like Oracle) is BORN to manage transactions.  That is the thing it does best in Financials, HRMS or any other ERP modules. 

 If you have paid for it, why not use it to the maximum ???   If we have invested in the Oracle RDBMS technology, I think PL/SQL is the only place to manage bulk data processing.   

Andrew Oliver replied on Wed, 2012/10/17 - 11:58am in response to: Mark Unknown

I should mention that I HAVE coded extensively in Swing. My hatred comes from years of familiarity with it. And if you think applying that L&F is sufficient, I may not be a design genius but I assure you, your GUIs are ugly too :-)

Andrew Oliver replied on Wed, 2012/10/17 - 12:00pm in response to: Mark Unknown

Yeah to be clear I don't think it is the end of the world to have session ids replicated, on the other hand it is much nicer to use JSON/BasicAuth/whatever to avoid it and just cache authentication.  

Mark Unknown replied on Wed, 2012/10/17 - 4:56pm in response to: Yeshwant Nandi

The db is not an app server. Sometimes SPs are the best answer but then you will have suffer the maintenance overhead. 

 Using and ORM does not eliminate TXNs from the DB.  In enterprise systems many times you need to commit units of work that are more than just relational db TXNs. The db will still handle the db txn though.

 WHy not use it to its maximum? Because it might not be the right tool for the job.  Don't base you decisions solely on "we paid for it" 

Raging Infernoz replied on Wed, 2012/10/17 - 5:40pm

0. BS, what about when you need cached lookups of expensive to assemble meta data.

1.  Sounds nasty, but maybe required for business reasons.

2. Learn to use the correct controls, models, and layouts, and learn the wonder of SwingWorker and concurrent code; basically stop being too lazy to learn it and learn to extend it.

4. If you write static utility classes, learn ThreadLocal, Date and Calender become a doddle to use.

5. Yuck.

6. This is common with idiots who don't explore the Java docs before coding; I saw this with ex-C++ and ex-VB coders, and had to recode their array based buggy code.

7. True, unless the existing Collections Classes can't be mutated enough or make poor use of memory.

8. Doug Lea is great, however you still need to write code to fill in the gaps and sometimes you need custom behaviour which off-the-shelf pool and collection libraries can't provide.

9.  WTF!  Logging does not suck, Logback is a wonder to behold, and ALL serious software needs logging, period!  Learn the wonders of the very light weight SLF4J logging facade and it's wonderful family of logging redirectors and a choice of logger targets; it stomps all over the commons logging garbage.  It's also about redirecting logging from the carp legacy loggers used by libraries, and to not hard code which logger you use; even to allow use of a custom logger, possibly prior to logger migration.


Mark Unknown replied on Wed, 2012/10/17 - 6:09pm in response to: Andrew Oliver

Not as ugly as most Web apps. :) 

I will definitely admit Swing is not perfect. But it sucks less. :(  

Andrew Oliver replied on Wed, 2012/10/17 - 6:35pm in response to: Raging Infernoz

Logging doesn't suck but all logging facades suck and bridging 20 logging frameworks sucks

Grant Dawson replied on Wed, 2012/10/17 - 6:42pm

Finally my personal spokesman. I've been walking around secretly hating hand-written sort algorithms and the cartoon GUI for a while. Was pretty sure some electric car would pull around the corner and give me a good lesson for saying that out loud.


#4 and #8 (Calendar math and Doug Lea) also. +1. 

Horse Badorties replied on Wed, 2012/10/17 - 8:23pm

1) Half right. Developers don't get databases, and make their own mess. a) Stored procedures are often faster. Making a simple API with stored procedures can save pain later by avoiding weird queries. b) Leaving database integrity up to the coders is a terrible idea. Putting database integrity checks (not code, just assertions) in database triggers is the one most effective thing you can do to avoid database corruption and being there at 3am fixing people's mortgage records.

Alied Pérez replied on Fri, 2012/10/19 - 12:38pm

I tend to agree on most things. However, I have worked both desktop (swing, Netbeans RCP) and web (GWT). I can tell you, HTML can be a real pain in the ar\0x07\0x07se; at least for me. Still don't know why people accuse Swing of being slow. Not my experience at least, and whenever I've found something is slow, I was doing something wrong. Again, HTML is not the future. There is too much hype in it, but we still use lots of desktop applications every day. and you will be amazed how many of them are swing based  (you just don't notice it)


Taht said, you forgot one more awfull practice I've seen associated to someXML-based frameworks:


public class MyEntity {

  private String property1;
  private String property2;

  public String getProperty1() {
    return  property1;

   public void setProperty1(String property1) {
    this.property1 =  property1;

  public String getProperty2() {
    return  property2;

   public void setProperty1(String property2) {
    this.property2 =  property2;

No constructor, no validation at the setters, mutable objects;just a C struct!

just declare your members and let the IDE create accessors.


Lund Wolfe replied on Sat, 2012/10/20 - 3:43am

I strongly agree with all but 2 and 9.

9 - Let's not all agree to use the reject library just to be consistent.

2 - Everybody knows Swing is hard and has a steep learning curve.  Even Sun wrote some pretty sad Swing apps.  Swing really requires a senior Swing developer.  SWT requires a mid-level Java developer.  Otherwise, you are just asking for trouble and you'll be much better off doing the best you can with a web app.  If you need it, you need it.

Mark Unknown replied on Sat, 2012/10/20 - 9:44am in response to: Horse Badorties

1) Half right. Developers don't get databases, and make their own mess.

Half true. Many developers get databases. The problem is that most developer should be doing something else. The other side of the coin - most  DBAs are not developers. SPs are code.

  a) Stored procedures are often faster. Is the code fast enough? Maintenance is more important. Sometimes SPs are the right tool. There are other ways to gain speed without using SPs (and thus tight coupling).

 Making a simple API with stored procedures can save pain later by avoiding weird queries. But SP queries are even weirder. And it doesn't always make the API less simple (probably less seldom). Also, code you eliminate with an ORM is increased when you use SPs.

 b) Leaving database integrity up to the coders is a terrible idea.  But leaving code up to DBAs who dont have good coding practices or tools is good? (no OOP, IoC, code reuse, and a "scripting" language). Just because someone is a "DBA" does not make them good at DBs. What happens when you need something other than a relational DB?  Just because someone is a "developer" does not make them bad at databases.

 Putting database integrity checks (not code, just assertions) in database triggers is the one most effective thing you can do to avoid database corruption and being there at 3am fixing people's mortgage records.

It is effective assuming, the triggers are correct and you only are comitting transactions at the db level. In enterprise applications, this is not the case.  The problem is that triggers are in the database language (see above for issues) and lead to duplicate code.  The better solutiion is to use good coding techniques and enforcement. If you must, use db triggers, but make them the last line of defense, not the only. You still have to enforce rules at the UI and "Domain" layers.




Yeshwant Nandi replied on Sat, 2012/10/20 - 12:50pm in response to: Mark Unknown

<<<<<<   Sometimes SPs are the best answer   >>>>>> Good. We agree.   You need to qualify what that "sometimes" use case is ....  <<<< but then you will have suffer the maintenance overhead.   >>>> SP's are no more or no less maintenance overhead than code written in any language .....  it is just code written by either good or bad developers ....  <<<<   WHy not use it to its maximum? Because it might not be the right tool for the job.  Don't base you decisions solely on "we paid for it"  >>>>>  Why did you pay for it then ??  Just to use it as a CRUD with ORM tools ????  Why not use free open source RDBMS technologies then ????  What is the difference between Oracle RDBMS and My Sql RDBMS ????  If you can convince your management that you can run Financial operations on My SQL ... then go for it ...  hell, even  Facebook runs on free open source RDBMS....

Horse Badorties replied on Sat, 2012/10/20 - 8:10pm in response to: Mark Unknown

DB triggers are good as the last line of defense. All other things being equal, fewer lines of code = fewer bugs. DB trigger code (SQL one hopes) is much denser than app code, and is in fewer places.

Alied Pérez replied on Mon, 2012/10/22 - 9:32am

just one more I remembered (and somehow related to my previous comment):

public class my class {
  Date myVeryImportantDate = new Date();
  List<String> myVeryImportantListINeedToControl = new ArrayList<>();

  public Date getMyVeryImportantDate() {
    //returning a mutable Object. related to 4.
    return myVeryImportantDate;
    //Will not add a setter because this field is supposed to be r/o
    //but I've seen things...

  public List getMyVeryImportantListINeedToControl() {
    return myVeryImportantListINeedToControl;//!!!

Even worse!!!
  public void setMyVeryImportantListINeedToControl(List thaList) {
//yes, I have seen this A LOT!!
  this.myVeryImportantListINeedToControl = thaList;



Eric Weimer replied on Mon, 2012/10/22 - 2:36pm

my 2 cents:

1. Agree

2. Never wrote swing

3. Generics are bogus. After a decade of code reviews, don't recall ever seeing a bug generics would have prevented. They clutter code making it less readable, yet provide almost no benefit.

4. Or use Groovy. Gotta love a fully object orientated language.

5, 6, 7, 8: Obviously yes

9: slf4j + Logback 


Comment viewing options

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