New articles in the 'Java collections' section

Readers are invited to explore some new material that has been added to the Java collections section of the web site. By rights, this material would probably belong in a "Java algorithms" section, as they don't use the collections framework as such, but rather look at structures closely related to those used in the standard collections classes.

In the section on Advanced use of hash codes, some new material firstly looks at how we can implement a strong, 64-bit hash code in Java, and how we can use this to create a Java hash map implementation that saves memory by storing only the keys.

A further section on Bloom filters builds on this strong hash function further, allowing a set of objects to be represented very compactly in memory in return for a certain "false positive rate". This tradeoff is useful in certain situations where we want to "weed out" certain items that require further, resource-intensive processing from those that don't (for example, when wanting to reduce database hits), but where it doesn't matter too much if a small percentage of items "slip through the net". We look more closely at how the initialisation parameters of the Bloom filter can be configured to tune the false positive rate in return for more or less memory space being required.

Javamex moved to a new server

The Javamex web site has been moved to a new server. Hopefully the move was fairly transparent to readers, but I of course welcome any feedback in case of any gremlins you may spot...!

iPad for programmers: new section and survey

In preparation for a new section of the site dedicated to programming tools for iPad users, the site contains a survey to find out which tools people are currently using. If you have a few seconds to spare, you are invited to fill in this very quick survey.

What kind of tools are we interested in? Well, essentially any iPad app that you consider to be "programming-related" in some way: for example, code editors, tools to run scripts, calculators that ease with programming-related tasks etc. Even general tools such as VNC clients are also welcome if you use them for programming-related tasks.

Javamex survey

Readers are invited to take 5 minutes out to answer the site's Java programmer survey. The survey asks you your opinion about various aspects of Java programming: how difficult or easy do you consider aspects of Java such as threading, the 'volatile' keyword, using databases in Java etc. The survey is completely anonymous and the results will be used to improve the focus of future articles published on the Javamex web site.

The cost of object orientation: an update

Back in March, an article was added to the site on the performance cost of object orientation which showed that on a test system, "hand-cranking" computationally expensive complex number calculations to avoid the use of encapsulating objects gave a notable performance benefit. The results also showed, however, that the benefit of using mutable objects was limited.

In some work I've been doing more recently on a wider range of test machines and versions of Hotspot, at appears that this effect is not universal: on at least some systems, there is a benefit from using mutable rather than immutable objects. More details will be posted to the site in due course.

The performance impact of object orientation

Today's new Javamex article looks at the performance impact of using an object-oriented approach vs an optimised, non-object-oriented approach in a case where the OO approach requires high object throughput. Specifically, we look at the case of calculations with complex numbers.

The basic tenet is that the most intuitive program design is to have a complex number encapsulated as a Java object, and furthermore, as an immutable object. This means that at each individual step in a calculation, a brand new object is created. However, performance measurements suggest that using immutable objects is only around 28% slower than using mutable objects, whilst the codability and maintainability impact (threading issues; bugs introduced by forgetting to copy objects and hence making accidental modifications to an obejct) may be considerable.

In our example, a version of the algorithm that does away with encapsulation and "inlines" its calculations on raw double primitives is more than twice as fast, as perhaps might be expected. On the other hand, "only" being between twice and three times as fast means that a comparable improvement will be possible in some applications by making use of more processors, or potentially making other algorithm improvements, whilst the codability and maintainability implications of not using encapsulation become more severe for more complex applications.

When your antivirus nags you worse than your mother: the power of bloatware

If you're looking to rub salt into that wound we call life, few things can top the mighty blue screen of death followed by the severe ticking off that comes from allowing thy computer to be shut down in an improper fashion.

But if there's one thing that comes close, it's got to be Antivirus software. Few other inventions succeed in reducing a squillion-gigahertz processor to the power of a ZX Spectrum. And on the scale of severe tickings off, little can beat the scolding that I received today from the antivirus I had trustily installed not four score and ten days ago.

- "For the last 90 days thou hast willingly deterred from scanning thy device for evil malware," quoth ye antivirus.
- "Evil what?", quoth I.
- "You know-- bad stuff like cookies and worms and shit.".
- "But isn't that your job?"

Alas, my assumptions regarding the autonomy of the antivirus software had proven false. Despite years of research into artificial intelligence and the inordinate number of clock cycles that said software consumed, it would transpire that scanning for evil malware was a task upon which it preferred not to take the initiative.

Thanks be to pointless bloatware.