Chaotic Java

Time for some refreshing the memory with a Java language feature probably few use, and maybe for a good reason. Suppose you’re running code on elements of an array up until a certain element is found. When your code finds that element, it stops the iteration. Therefore, your code might look like the following:

for (int i = 0; i < array.length && condition(array[i]); i++) {
  // your code here
}

Or, if you’d like to use the new foreach feature, like this:
Continue reading »

We all know the Java Collections Framework – Collection, List, Set, Map are used in almost every Java application. We also know that operator overloading in not available in Java, something that has caused a huge debate over the years, especially after C# came out and had it as a feature.

In fact, just today Daniel Pitts posted something about it under his “almost useful” tag. In that, he obviously mentions the convenient square brackets operator map[“key”] or list[1] where map is a Map instance and list is a List instance, of course. Continue reading »

Know when you have a lot of objects relying on some database information, but there’s no way to tell whether that information has been changed? I’m not talking about the majority of data in a database, just the little bits that help the application start itself. As an example, a distributed tax calculation application, where each accountant uses it to manage his clients. However, when it loads, it reads some critical information – tax rates, for example. These don’t change often, but when they do, you wouldn’t want to have to tell everyone to restart the application, would you?

So what are the options we’re left with?

• Have a big button saying “Refresh Configuration” and have the users click it whenever an email to do so is distributed to them.
• Have a function that does the checking periodically for them, basically “pushing the refresh button” every now and then.
• Register for database notifications, and be alerted when a change in a table you’re interested in has occured.

The first two options are okay-to-have, but aren’t useful when talking about applications which have no daily human-interaction or that cannot afford to check a database for changes constantly (and even if so, it is critical for them to be aware of change in certain tables as soon as they happen), such as distributed research applications being configured remotely using a single database. Continue reading »