IBM have a good article on their Developerworks site discussing the shortcomings of the current Java Virtual Machince Memory model and what needs to be changed in order to make it more predicable in some circumstances.
The major issues described in the article are problems related to synchronized access to data, and compiler reordering of statements which may cause unexpected side effects.
I came across a link to this blog this morning from www.javablogs.com, and read an article listing ideas for development projects.
I though this was interesting as this is something that I also do on a regular basis – every time I have a ‘wouldn’t it be cool if I had an app that could do xyz’ I keep track of it in my PDA. Some ideas I get round to implementing, others I don’t, but it’s interesting to keep track of ideas like these.
Plus, the name of the guys blog was just so funny I had to link to it here: ‘BadMagicNumber’ (this probably doesn’t make any sense unless you have seen this exception yourself 😉
Since the introduction of ‘feature-light’ J2ME for mobile/small devices, Sun is becoming concerned that vendors are adding many proprietary extensions to the API and hence breaking the ‘write once, run anywhere’ promise.
Vendors have been adding additional APIs to add additional hardware support options – the problem is that code written to take advantage of these specific features will not run on a platform that does not have the additional features.
Sun is therefore going to start a ‘Verification Programme’ to certify core features on J2ME supporting devices to ensure a certain degree of standardization in Java supporting devices.
In order to keep Unit Tests as simple as possible and easy to understand their intent, a good rule of thumb is to limit the number of assertions to 1 per test method.
This article by Dav Astelsdescribes this approach in more detail.
The main benefit from this approach is that each Unit Test method tests exactly one aspect of the system. If it fails then you (or someone else in the future who must debug the code) should know exactly the pupose of the method and therefore have a better idea of what has failed and where to start looking to resolve the issue.