Ben Hill - August 28, 2008

I work for a enterprise product company and we use threading frequently and sql often. Threading is required for scalability. SQL to interface with third party products and customer databases.

This packages are far from dead in my part of the coding world.

bob - August 29, 2008

you are fucking crazy

henk - August 29, 2008

I agree with the author. The average programmer doesn’t use those low-level constructs as often. In some parts of Java, you really shouldn’t use those anyway (like EJB for example). There are plenty of high level replacements out there or just on the horizon.

The low level SQL stuff will be mainly replaced by JPA. Yes, I’ve already seen a bunch of people starting with Java and going straight to JPA. They never even touched the JDBC APIs.

I suspect a similar thing will be happening to Thread. With all the goodies already available in the Java 5 concurrency package and more on their way for Java 7, I see the need to manage your own Thread classes *greatly* diminishing. In fact, very soon it might even become an anti-practice. When we all work with 32+ core CPUs, no way that Joe-average Java programmer is going to manage that efficiently.

Chris - August 29, 2008

We use java.lang.Thread heavily throughout a huge portion of our codebase. We also use plently of the newer concurrency APIs where suitable. But they aren’t (yet) anywhere near a complete replacement for java.lang.Thread and it’s very unlikely they will be for a long while yet.

As for JDBC, that’s all we use everywhere for all our DB code. JPA doesn’t even come close to meeting our performance/scalability/functionality requirements for the most part (very high volumes, data warehousing). We could theoretically use JPA when talking to some of our admin/config databases, but adding a mix of technologies (JPA + JDBC) and a further layer of abstraction to existing code with only debatable benefits (for us) doesn’t appear to be a very sensible move.

Note that we primarily write server software (on pure J2SE) that involves shunting around terabytes of data and number-crunching on 8-32 core CPUs that are distributed globally, so we’re probably not your typical Java dev environment. But we also have Swing GUI tools and to a lesser extent some webapps. And I have to totally disagree with Henk’s estimates, there are more than 10 of us here alone writing software of that nature. Just because it’s in-house and proprietary doesn’t mean we don’t face the same challenges as a much higher visibility project like Tomcat.

henk - August 29, 2008

@Chris

As you mention, you are obviously not in a typical Java dev environment You are right perhaps that the “no more than 10″ estimate was exaggerated, but I really would be surprised if it was more than a 1000 teams writing such software. The overwhelming majority of Java programmers seems to be writing the kind of software where JPA actually is the better solution.

Of course “better” is a term open to debate, but I simply see it happening in practice. I’ve seen batches of Java programmers who didn’t start out with JDBC but based their very first applications that used persistence on the JPA or Hibernate API.

Now this may be sour to us. We -know- that JDBC is more powerful and has better performance. On the other hand, in 1989 I also knew assembly had better performance. Yet all those crazy youngsters around me started coding in C/C++. In 1997 I knew C++ gave me more power and more performance, but yet those crazy youngsters again started programming in Java.

I’ve been around in IT since approximately 1983. Perhaps not as long as some other veterans, but I think it’s still some time. After a while you simply see certain patterns reoccurring.

A minority group will keep using the powerful tools of yesterday. Even to this day, people still program assembly language. It’s just that you wouldn’t code your entire average enterprise system with it these days, but restrict its usage to small pieces of ultra high performance code, some drivers and some embedded stuff. I really think the same will happen with Thread and java.sql. Maybe not today, but surely tomorrow.

Cliff - September 2, 2008

(Thread || JDBC).equals(”boilerplate logic”)

While saying Thread and JDBC is dead may send a confusing or misleading message the author makes a very valid point. For modern software there are plenty of high level replacements for these APIs. I frequently find myself tucking calls to these types of APIs behind interfaces to be either immediately or eventually replaced by a framework like Spring, EJB, iBatis, or the like. There are a few other APIs I would rank similarly such as URL. The problem with URL is that people still think they actually need it in high level interfaces. Most often what you need/want is a callback such as:
Object result = requestData(String requestQuery,
new MyCallBack(){
public Object recieveData() { /*…*/ }
}
);
Using these lower level APIs puts these APIs as a direct dependency of the code you write. It’s limiting and unnecessary unless you yourself are writing a framework.

werutzb - September 29, 2008

Hi!

I want to extend my SQL knowledge.
I red really many SQL resources and still feel, that I am not an expert
in SQL. What can you recommend?

Thanks,
Werutz