Chaotic Java

A class I find missing in the new java.util.concurrent package is PriorityBlockingDeque. Just like PriorityBlockingQueue, this class should be sorting its elements either by their natural order or by a supplied Comparator.

I fail to understand the reason for having this class obviously missing from the package, and because I need it very much, I decided to create a blocking wrapper around NavigableSet using locks and conditions. This uses NavigableSet’s already existing methods of pollFirst, pollLast, first and last to fulfil the Deque interface.

Update: After some comments appeared I’ve realised that by using NavigableSet I do not allow for duplicate values on the Deque. Therefore, I’ve changed the implementation to use LinkedList internally, using Collections.sort calls to keep the list sorted. Unfortunately, this brings the basic add operation to O(n log(n)), instead of the O(log(n)) it used to be.

The code is fully available here, as part of the collections project, and some unit tests are available here.

I will later post how I used it, but let me know if you used it and if it was of any help (or filled with bugs..)

Ever wanted to be able to know your process’ PID through pure-Java, cross-platform methods? Or worse, other JVMs?

At my work we came to a point where we needed to monitor and register a JVM’s PID (Linux/Windows/Whatever) for some future manipulation purposes. However, Java in itself did not contain the concept of “process ID” - Even the Process class (which is horrible, for different reasons which might be discussed on a different post) doesn’t have any way of getting that information.

However, JavaVM Process Status Tool (JPS) seems to be written entirely in Java and is actually able to retrieve this information! Jps is a Java class located on Linux and Windows in the jdk/lib/tools.jar file, or in the CurrentJDK/Classes/classes.jar if you’re using a Mac. Also, it’s only bundled with JDK 5 and up, which I assume that by now, all of the readers have installed.
Continue reading »

Sometimes, Generics can just cause a mess. Take for example the following definition I had to produce, just to get out of a Generified library I had somehow brought to life:

public final class PlayerFinishedAction<
        TGame extends TurnBasedGame<
              ? extends Board,
              TPlayer,
              ? extends Turn<Phase<TPlayer>>,
              ? extends Phase<TPlayer>>,
        TPlayer extends TurnBasedPlayer>

        extends DefaultAction<TPlayer, Location> {

You can only imagine the horrors inside a class defined that way. Needless to say, I had to re-evaluate the cost versus benefit that the generification of the library has brought to me.

I’d also like to highlight a previous post of mine about generified bi-directionality, and let it be reminded again that thanks to erasure, this is all in the end just a bunch of casts and overloads. What I mean to say is, make sure that the type-safety generated by the Generics mechanism is something of value and not just a nice touch, as it sometimes can make a simple application messier.