Queues with Threads to be avoided.

Warning: Contains some ranting. ;)

It baffles me why so many developers use Queue and Thread explicitly when there is an ExecutorService built in which does both much more elegantly. This has been part of Java 5.0 since 2004 and was available as a third party library many years before that.

There are specific cases where using a Queue and Thread is the best choice but that doesn't appear to be the reason it is done most of the time.

Is it a lack of understanding of these core libraries? Is it because that is how it is done in other languages and people are bringing the patterns they know to Java?

I wonder if developers get some satisfaction doing things the hard way. There is a greater sense of achievement when you have written some really complex code?

Any other theories welcome. ;)

Examples of developers doing things the hard way.
  • Using a text editor for development instead of an IDE
  • Using double checked locking lazy Singleton instead of an enum with one instance.
  • Using primitive wrappers when they mean to use primitives.
  • Trying to guess why a program doesn't work as expected instead of using a debugger
  • Trying to guess why your program doesn't perform instead of using a profiler which will measure it.

Comments

  1. great :D

    need code example

    ReplyDelete
  2. Probably, because most developers can get stuck in their ways, so are still using what worked for them pre-2004 :)

    ReplyDelete
  3. I use them, queues, when I am using a persistent task-threads that need to queue up commands/data to be handled separately from incoming requests. The Executors are good otherwise.

    ReplyDelete

Post a Comment

Popular posts from this blog

Low Latency Microservices, A Retrospective

Unusual Java: StackTrace Extends Throwable

System wide unique nanosecond timestamps