April 11th, 2009 by Sam
NetBeans is my IDE of choice and I was recently accepted as an approved contributor on the back of RFE 125060, aka the Java Completion Excluder
Exclude classes from appearing in the code completer (such as sun.* and sunw.*) with method-level granularity. Example use case: java.lang.Object.{wait*, notify*, clone, finalize} have more appropriate alternatives so I want to be able to disable the completer from acknowledging their existence, despite the fact that they are still valid methods to call.
In this post, I’ve documented my initial experience of contributing to NetBeans, in the hope that it will lesson the barrier of entry and inspire readers to consider doing the same!
Read on… »
Posted in Java NetBeans OSS SUN
1 Comment so far
March 9th, 2009 by Sam
The Java Applet caused a lot of hype in the mid 90s when some people believed it would become the standard for interactive content on the web. It never happened. Some will claim this is because M$ shipped a buggy implementation. The simple truth is that designers design the web, and Adobe Flash created a very designer-friendly interface. Java Applets are Java programs and you need to be a programmer to write one. It was a completely inaccessible technology from the design side.
Arguably, the race is still on for the next-generation rich-media platform: M$’s Silverlight and SUN’s JavaFX being two new entries. It seems that even SUN have laid Java Applets to death. But recently our team stumbled upon a fantastic project called Processing which is aimed at designers who aren’t scared of a little bit of programming. There is an integrated IDE and although you feel like you’re writing pseudocode, you’re actually writing a simple version of Java (which gets compiled to an applet). For some great examples, see Processing monsters.
At xmas, our team (ThinkTank Maths) wanted to create a mathematics-inspired holiday message. After much thought, we came up with the idea of a repeating wallpaper pattern based on the recipient’s name, perhaps using a Langton’s Ant. The next challenge was to create an implementation. One of our team whipped up a Processing implementation in a few hours. Read on to see our applet, and the clean code Processing encourages…
Read on… »
Posted in Java
3 Comments
December 2nd, 2008 by Sam
In my last post I hope I convinced you that XML parsing with XPath queries and XSD validation is the way forward:-
- W3C Schema Definitions (XSDs) let you separate validation from logic
- XPaths queries are a serious timesaver and make code very readable
But also that the Java XML API is possibly the ugliest and stupidest API you will ever see in your life. In this post my company is releasing a helper class as open source, which makes XML processing a pleasure. Right click on XMLHelper.java and save to disc. Please let me know if you find any bugs or come up with anything worthwhile adding! You’ll need the GuruMeditationFailure exception from my previous post unless you want to edit the code, and the latest version of the Google Collections (which everybody should be using!).
WARNING: you might want to consider using direct access to the Java XML API for performance, especially for reading attributes in a loop.
Read on… »
Posted in Convenience IO OSS Parsing XML
1 Comment so far
November 15th, 2008 by Sam
A year and a half ago, I posted Parsing XML. At the time, my focus was directed at parsing very large datasets of relatively simple XML formats… the Wikipedia Datadumps being a good example. Since then, I’ve found myself needing to parse smaller, well defined XML files that can be realistically loaded into memory. In this post, I will highlight all the XML parsing approaches available in Java and tell you why you should be using XPath with XSD validation.
Read on… »
Posted in API Advanced Validation XML XPath
No comments yet
October 19th, 2008 by Sam
It has been noted by many well respected developers such as Brian Goetz and Josh Bloch that
If an object’s hashCode() value can change based on its state, then we must be careful when using such objects as keys in hash-based collections to ensure that we don’t allow their state to change when they are being used as hash keys. All hash-based collections assume that an object’s hash value does not change while it is in use as a key in the collection. If a key’s hash code were to change while it was in a collection, some unpredictable and confusing consequences could follow. This is usually not a problem in practice — it is not common practice to use a mutable object like a List as a key in a HashMap.
But it’s all too easy to instantiate a new HashSet every time you define a Collection, simply out of habit.
I bet if you were to go through your code and check all your uses of Collection or Set, you might find that many of them should be ArrayList in order to guard against changes in your entries after they’ve been added. You’re probably only getting away with it because your code is not being subjected to many threads that are acting on the entries. Be particularly mindful of field variables if they are not collections of immutable objects such as primitive wrappers and String.
Posted in Collections Concurrency Immutable Java Mutable
2 Comments
October 18th, 2008 by Sam
I have strong opinions when it comes to checked vs unchecked exceptions, as do many other people all over the interwebz. For me, a checked exception should be thrown when the caller can reasonably recover, otherwise if you can recover yourself (or the problem is not that significant) you should just log it and get on with life (e.g. if Closeable.close failed, it’s really not the end of the world… just log it). If it is a serious problem that cannot be reasonably programmatically recovered, then go for a runtime exception.
In this post, I’m going to discuss the RuntimeExceptions that I use and introduce a new exception, the GuruMeditationFailure.
Read on… »
Posted in Basic Exceptions Java
4 Comments
July 12th, 2008 by Sam
Java comes with a built-in logging system java.util.logging which is really quite good. It is very simple to use, highly customisable at runtime and offers incredible extensibility. However, by default it doesn’t allow you to specify the format of your logging messages and this tends to make people angry (the default setting is to print everything to System.err, over 2 lines). In this article I’m going to talk a little bit about why you should use the built-in logging package and show you how to get runtime support for the formatting of log messages.
Read on… »
Posted in Basic Java Logging
8 Comments
