The Javamex companion blog. This blog includes both technical articles relating to the programming information that you'll find on the Javamex site, plus information covering the IT industry more generally.
Thursday, March 10, 2011
Suggestions for new programming articles
The Javamex site is open to suggestions! Please make a suggestion for a new programming topic at the top of the home page!
Friday, March 4, 2011
Update to Currency Quoter utility
The latest update to the Currency Quoter utility available on this site, version 0.04a, fixes an issue which prevented currency data from being downloaded under some circumstances. It also introduces a parameter allowing you to control the number of months' worth of data that are taken in producing the forecast value of a given currency exchange. You can currently configure this between 1 and 12 months. The default is 3 months, which appears to be suitable in most cases. However, you may wish to take a greater period, for example when looking at a longer-range forecats of the value of a currency that has had a particular trend over a longer time.
Please report any issues with this program bugs@javamex.com
Please report any issues with this program bugs@javamex.com
Thursday, February 17, 2011
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.
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.
Wednesday, February 16, 2011
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
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.
Friday, February 4, 2011
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.
- 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.
Saturday, January 15, 2011
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.
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.
Labels:
64-bit hash function,
Bloom filter,
hash table
Subscribe to:
Posts (Atom)