I was looking to learn how to write a non-blocking IO server in Java, but couldn't find one that suited my needs online. I found this example, but it didn't handle my situation. There is also Apache MINA, but it was a little complex for my simple needs. So armed with these examples and a couple of tutorials (here and here), I created my own.
Some time ago I wrote a post describing a Java Multi-channel Asynchronous Throttler I had written. At the time, I stated it would preserve the order of calls, but as Asa commented on that blog post, this was not always the case. Here is a new version that does preserve order, and passes Asa's test. As part of this work I also extracted common code into new classes and created a ChannelThrottler interface. It works by placing incoming tasks on an internal queue. All the code detailed in this post (and the other throttler post) is available here.
In another of my recent series of generic utility Java classes, I present a multi-channel asynchronous throttler. My project connected to an external webservice which imposed draconian restrictions if usage went above a certain level - defined as whether there were more than X service calls in Y seconds. I was determined to stay under this level. Furthermore, some types of service calls were more expensive than others and had their own limits in addition to the overall limit. That is for certain types of service call I had stay under two limits - a call specific limit and the overall limit that applied to all calls. I refer to this as multi-channel throttling. Also, I wanted the throttler to be asynchronous, that is I did not want to stop procesing while waiting for the webservice to respond to my call. Looking on the web I found a number of throttlers, but none that matched my multi-channel, asynchronous requirements.
Java provides a number of methods to run code at scheduled future time, the implementations of ScheduledExecutorService generally being the best way at the moment. ScheduledExecutorService also defines methods to run the code a periodic intervals (scheduleAtFixedRate & scheduleWithFixedDelay). However, what if you have classes that need to be notified at regular discrete intervals and need to know which interval that are in. A timer is required that with a set periodicity fires an event on any listeners and passes the number of times the period has elapsed. What this is doing is breaking up continuous "realtime" into discrete blocks or quantums of time. For example, if the period is 10 seconds, at the start the time quantum is 0 until 10 seconds have elapsed and an event is fired denoting the start of the first time quantum. Ten seconds later another event fires as the 2nd time quantum starts, and so on.
This is a fairly simple bit of Java code. Any experienced Java developer has probably already worked out a good solution, but for me it has come up a couple of times in the last few months so I thought I'd write it down.
This is a quick post about a coding problem that took longer than expected to solve. I have put an example solution here as a reference for myself or others, hopefully speeding up the task. I needed to create a dialog to connect to a local or remote JMX process. Essentially this would be very similar to the JConsole "New Connection" dialog. Initially I thought this would just be a standard component, but instead it took some trial and error (as well as digging through Sun documentation) to get the required functionality working.
Recently I wanted to have a clickable button in a table. Searching on Google for JButton in JTable I found a couple of suggestions, most notably this DevX article and this Esus article. There was also a StackOverflow question that just referenced other solutions. None really satisfied me. So borrowing their ideas I created my own solution.
What is the accepted way to test generated source code? A recent work project required me to generate some Java source code from small definition files as part of a larger framework. The plan was for other project teams to take the framework and use the generator to create source which would become part of their project. I wanted to write unit tests for the source code. The problem was how to write a test for code that didn't exist at the time the test was written because it hadn't been generated yet! I came up with a few options:
In a recent coding project I fell foul of Java enumerations. They seem like a very good idea, and indeed they are when used properly. However, there is sometimes a tendency to overuse them - something unfortunately learnt from personal experience.
Intially Java had no inbuilt concept of enumerated types. Developers often found themselves inadequately simulating them by creating a bunch on integer constants. Proper enumerations were added to Java in JDK1.5 with the enum keyword and developers rejoiced (or at least I did). The following example from the Java Language Guide shows how they are used:
public enum Rank { DEUCE, THREE, FOUR, FIVE, SIX,
SEVEN, EIGHT, NINE, TEN, JACK, QUEEN, KING, ACE }
public enum Suit { CLUBS, DIAMONDS, HEARTS, SPADES }
Actually, the above is just the basic usage pattern. Java enums can have data and behavior, as shown in the Planet example below (from the same guide). They can also implement abstract methods directly at the definition (see the guide) but they cannot be subclassed.
public enum Planet {
MERCURY (3.303e+23, 2.4397e6),
VENUS (4.869e+24, 6.0518e6),
EARTH (5.976e+24, 6.37814e6),
MARS (6.421e+23, 3.3972e6),
JUPITER (1.9e+27, 7.1492e7),
SATURN (5.688e+26, 6.0268e7),
URANUS (8.686e+25, 2.5559e7),
NEPTUNE (1.024e+26, 2.4746e7),
PLUTO (1.27e+22, 1.137e6);
private final double mass; // in kilograms
private final double radius; // in meters
Planet(double mass, double radius) {
this.mass = mass;
this.radius = radius;
}
public double mass() { return mass; }
public double radius() { return radius; }
// universal gravitational constant (m3 kg-1 s-2)
public static final double G = 6.67300E-11;
public double surfaceGravity() {
return G * mass / (radius * radius);
}
public double surfaceWeight(double otherMass) {
return otherMass * surfaceGravity();
}
}
I think the first (Rank & suit) example is correct usage of enums - essentially treating them as related constant values. In my opinion, the second example is problematic. Here the Planet enum is acting similarly to a class with each instance being like an object, with data and associated behaviour. At the level of the example this may seem acceptable - not much is happening here. However, code rarely stays static. Requirements change and thus the code changes to handle different functionality. It is not hard to imagine more data being required for each Planet. Object-oriented classes are designed to help handle this change. Enumerations are not and there is no inheritance, nor is it possible to pass non static constructor arguments. As a result, as the functionality of an enum becomes more "object-like", the code supporting it becomes increasingly messy.
The general rule is that linked constants should be enumerations, but anything more than that should probably be a class.
I have broken this rule myself and lived to regret it. A project I recently worked on aggregated a number of different financial markets and presented a single interface for downstream clients. This project used quite a few enumerations. For example, there were enums to define the market defined type of a financial instrument and another for its pricing method. These worked fine, they were mutually exclusive values read from the markets essentially as constants. There was also an enum for the markets themselves. At first this was fine, each market was treated the same. However, as the system expanded to new markets and extra functionality, differences between markets began to appear. More and more logic began to hang off the market enum. Some was data stored on the market enum. Most was determined by the environment and was set by configuration settings. This logic ended up in various special classes constructed by Factory classes switching on market. Indeed there was quite a bit of logic in the system that switched code path depending on market. The code would definitely have worked better had there been a Market class rather than enumeration. Refactoring all the code to use a class rather than a enumeration was a big job in an important working system.
Recently I have been thinking hard about threading in a Java project of mine, and it definitely requires a great deal of hard thinking. When I started working with Java there weren't any native threads, so it was just easier to make everything single threaded as the performance gain was minimal. However, as time has passed more and more of my code both at work and home has needed to work multi-threaded. As I learn more about Java threading, I realise how wrong I was doing it before - a cycle repeated a few times in the last 12 years. It was only after reading the great book Java Concurrency In Practice a few years ago that I realised that in Java "locking is not just about mutual exclusion; it is also about memory visibility." I can only hope that this is the last such cycle, but realise it's probably not.
I think the next step may be using another language that doesn't allow shared state. Scala uses an Actor model to asynchronously pass messages between threads. There is no shared memory so no threading problems. This sounds like a good way to go, but I still work in Java for most of my programming (not many Scala or Erlang jobs around!).
This whole situation reminds me of memory management in C++. There were simple rules to follow to reduce memory leakage, but the problem was hard to completely solve (especially to a newbie programmer) and normally your program still leaked. I remember leaning heavily on Purify. Then Java came along with its automatic memory management and the problem largely disappeared. Developers could focus on the business logic of their code rather than housekeeping. Hopefully a similar thing will happen with Java threading.
A while ago I wrote a blog post asking is there dumb money on Intrade? The short answer was probably not once the implied interest rate was considered, unless a chain of nearly expired "easy money" trades could be constructed. When I heard that the Goggle app engine supported Java I was keen to try it out. So I ported my manual Intrade interest rate calculation to Java and had it read the Intrade XML feed to check for any contracts finishing soon with high implied interest rates. Unfortunately, the code fell foul of Google's time limit on reading data from other websites. Rather than see the code go to waste, I decided to clean it up and release it. It is a command line Java app with all the code available under the MIT license. It's probably best to just load it up in Eclipse and run the launch file to see it working. Enjoy!
You can download the whole eclipse project here.
I recently needed to write a Combinatorial Iterator for a project I'm working on. That is a class which when given a size and a collection of items (normally a set), returns all the possible unique combinations of elements from the collection of the given size. For instance the combinations of size 3 of the set [1,2,3,4] are [1,2,3], [1,2,4], [1,3,4] and [2,3,4]. There is a nice discussion of this problem on StackOverflow. The number of possible combinations can explode in size quickly, there are 2,598,960 combinations of five cards from a standard pack of 52 cards. Thus I wanted to handle each combination in turn as required, rather than calculate all combinations upfront. Having recently started learning Scala and Ruby, I decided to implement my solution in those languages, plus Java (which I use every day at work).
A few years ago I had the idea of creating a fairly standard online spaceship combat game (like EVE). The difference to other such games being that the players would not control their ships directly, but instead through code they submitted to the game - a more complicated and extended Robocode or CoreWar. At the time I stopped because I couldn't work out a way of preventing Denial of service attacks in the submitted code. I had hoped to use Java as it had an extensive security model, but I found there was no way of stopping untrusted code from starting too many threads or allocating too much memory.
Fast forward many years, and I thought I'd check out if the situation has improved. A search on Google returned all the same webpages I read 9 years ago - there hasn't been much movement in the area. The Javadocs suggested that the thread issue had been fixed, but no word about memory. I checked Robocode and it seems to just ignore the memory allocation problem. This is because it is not fixed!
WTF! Sun has gone on about the Java Security Model for some time now. Touting the safety of its sandbox. However, if untrusted code can crash the system it is broken - nothing more to say. I don't care about the rest. This has been a known issue for years.
Anyway, rant over. On a more positive side, I used StackOverflow for the first time in researching this issue and it is quite cool. My question is here. The answer states that there is a movement to fix the memory DoS attack, but that it is still in the requirements stage and probably will not be part of Java7.
