Additional information on the 'final' keyword

The section on the Java final keyword has been expanded. Previously, we concentrated on the use of 'final' for thread-safety but did not give much information about a separate use of 'final' to indicate that a class or method cannot be overridden. The new material expands upon this use with a look at the performance implications of the 'final' keyword as a class or method modifier.

A common view that I have both heard among colleagues and seen in various Java textbooks is that 'final' is as much a performance hint to the compiler as a specification of design. In the new section, I present some data showing that this view is probably misguided: the timing of calls to methods to final vs non-final classes comes down to whether the JIT compiler can determine at runtime the precise subclass of an object rather than whether or not the class in question is or may be overridden.

Initial release of "Currency Quoter" utility

A very initial release of a currency conversion tool is available from the Javamex site. The Currency Quoter utility allows you to exchange between various currencies using exchange rate data reported by the IMF, and also allows you to forecast the likely range of values that a particular exchange will have on future dates.

For news and updates, you may also wish to subscribe to the Currency Quoter project page on Freshmeat. You can report bugs at bugs@javamex.com

New material: doing maths in Java

The section on mathematical operations in Java has been expanded over the last few days to include some new material that will be useful to those writing maths-related applications in Java. Notable inclusions include:

• The section on the performance of java.util.Math methods has been expanded somewhat to include more information about the timing and implementation of certain operations.
• A new section on BigDecimal and BigInteger looks at how to manipulate arbitrarily large numbers (or numbers of arbitrary precision) in Java. We include an analysis of the performance of multiplication.

As usual, suggestions for improvements to this section or suggestions for new material are always welcome, either on this blog or on the Javamex forum.

I thought this was interesting, although the actual security impact is hard to assess. Various sites "leak" information not through the payload returned by a particular HTTP request, but simply by the response code. Thus, as this article illustrates, we can find out, for example, whether a user is logged on to sites like Facebook as follows:

- find a particular page that responds with an error code or not depending on whether or not the user is logged on;
- using a "script" tag, ask the browser to load that page as though it were a script;
- in the onload() and onerror() handlers, take action that assumes the user is logged on in the first place and not in the second.

The fact that a user is logged into, say, Facebook or GMail probably isn't a very exciting discovery: half the Internet population probably are at any given moment. But more controversial sites may want to think about what kind of information they accidentally leak in this way.