Starting Listeners in the Correct State

A problem that I'm having with event listeners at the moment is making the listening object begin at a point in time in the correct state when it is really designed to build its state from the the events that are received while assuming a state to begin with.

For example, say you add a listener to an observable containing the state for a light switch, the listener should really know the state straight away but the event could be fired in 8 hours, or never. There are two ways I can see to fix this.

When adding the listener the listener gets the current state from the observable and updates itself.  This is fine but it does mean that the listener needs to know about the observable which adds a dependency so that the listening object is less reusable.  The Java property change framework is weakly typed, treating sources and values as objects anyway so you shouldn't really be expected to add this dependency.  Plus it makes the listener more difficult to test.

The observable holds a copy of the last event object it fired and when a listener is added fires all events to that listener.  This can give us even more problems.  Imagine firing an event with a complex or resource hungry value.  The complex object could have references to many other objects that would get garbage collected except that this stored event keeps them in memory.  An image is probably the best example of an object that you wouldn't like to keep in memory longer than necessary.  This really means that only primitive values, enums and other small immutables should be the values in change events.

These problems are really compounded for state machines where to get begin at the correct state the machine has to analyse system state in much the same way a conventional solution would need to.

Statics

Statics: the natural nemesis of discoverability -_-

European Java Roadshow

My registration for the European Java Roadshow has been accepted, WOOT!  There are some real nuts and bolts talks about Java and the JVM at the London Roadshow which should be interesting.  Here's my views on the talks...

• Firstly, Java Hotspot Optimisations.  I'm always fascinated at the work going on in this area, also I know that at the moment it would go way over my head if it got down to the nitty gritty and I think its the same for anyone who hasn't whole heartedly delved into the OpenJDK source.
• Secondly, Java Garbage Collection.  This should go way beyond the generation garbage collection diagram that we've all seen implemented in every half arsed VM.  I really want to know what the G1 garbage collector is going to give software in the future, and more importantly the trade offs involved.
• The More about Java SE embedded talk is interesting simply because I have almost no knowledge of whats going on in that area.  I've worked with software engineers doing embedded programming and don't think they would give up their beloved C lightly.  Its going to be good to hear about the inroads the JVM is making in this area, especially in memory usage!
• Java Realtime VMs promises the same as above, although its more pertinent to my area of work; simulation.  There are certain cases where realtime is important and its certainly something to be strived for.
• When I read Java Futures I instantly thought java.util.concurrent.Future, great a concurrency talk!  This is just my naive programmer's mind.  Hopefully it will be something like the previous Java Futures talk at JavaOne.
• Not sure about Java for Business: Business Cases, is it a sales talk?  I'm guessing theres something more.
  

If you're going, or just commuting to London... See you on Feb 4th

Implementing Application UI in XML

I just noticed the new release of Pivot on DZone, and the whole idea just leaves me confused.  Why would anyone want to do complex coding in XML?

Java isn't the best for the kind of declarative style that you need when coding components that need a lot of information to be passed in such as colours and fonts.  The rows of sets really become ugly but at least you can have named constants for things like points and rectangles which is really difficult in XML.  Ant is a good example of that, properties soon become complex which doesn't happen in a Java project.

I don't think JavaFx is the answer either, it's just as confusing.  It's a high level language without an advertised purpose.  Yes it can do nice graphics easily but this must account for a single figure percentage (if that) of the total amount of software currently being developed.  If it hasn't been made to scale up to more complex tasks then whats the point of it?  Thats more of an advertising blunder than a language problem since it has all of the features that I would expect of a non-innovative modern language.  Maybe it's just not for me, it's created for designers and I'm not the target market.  Concurrency features are a hard sell to hasn't seen their UI mysteriously lock up.  Overall I'm just not impressed enough to make the switch when I could spend my time learning much more interesting tech.

The Groovy builders are impressive but aren't so much greater than Java to make the massive leap of incorporating a new language into your system. 

Back to Java, what does it really need to catch up in productivity to the main players?

• Closures,  this would just be really nice to have.  Anonymous classes achieve the same thing but Swing would look so much nicer with closures.
• String interpolation and multiline string, so simple and so useful.  Over Christmas I read up on Ruby, the language is a good manual on how to make our lives easier for day to day tasks.
• Clear up the cruddy Swing API, an average custom component has a multitude of inherited methods.  Just think how many different size properties there are, do you know which layout managers rely on which properties?  This can be improved.
• Inbuilt listener framework, the property change listener framework is really underpowered.  The default framework for property listeners should have weak listeners, annotated methods that can generate handlers and threading strategies as standard.  Think EventBus or something similiar.
• Configurable style, style should really be configurable and maybe even injectable as in Fuse.  The Swing Application Framework has this as well.

Using frameworks like Guice and MigLayout really improve design and coding as well and should be more standard in Java desktop development.

Twitter

The blogosphere isn't what it used to be, I've realised that a lot of the people that I keep up with have moved onto Twitter.  To keep up on the interesting tech news I've also got round to following people on my previously empty account.  I'm on as @andy_till suprisingly.

UI Code Don'ts

It's important to keep code quality in check constantly in UI classes probably more than others as it typically seems to get out of hand more quickly.  Here are some observations, they hopefully do not fall into the micro-optimisation category but I definitely feel they are bad to have around.

• Images or other memory hungry objects/resources marked with static.  These objects will never be garbage collected even if they are never used.  A shared object should store these images short term or SoftReferences should be used to store the images for a greater time without the danger of memory leaks.
  
• Style information spread out across the whole program.  Especially Font objects, this seems to be the first thing to change and if it is spread out across the whole project then its going to be a mess.
• Creating new Color objects in setters.  This causes a couple of problems, you're creating new Color objects all over the place which is only a minor problem but still pointless.  The other problem is understandability, it's hard to see what that colour is from the RGB constructor.
• Magic numbers.  Not much need to explain why this is bad, please name them.  If there are too many then create a separate class to house them, you can even use a static import to keep code readable.
• Too many anonymous classes.  Anonymous classes are useful buf too many look ugly (I don't like the syntax noise) and can cause memory leaks as the reference isn't explicit.
• SwingTimer.  Please no!  Even if you know the memory leak pitfall, it's still too easy to fall into it.  Just avoid.

This is just a short list off the top of my head, I'll update it if I think of anymore.

Snowtastrophy

Your grandchildren will ask... "Where were you when it snowed a bit in January 2010"? Thats the situation as I understand it from Sky News anyway.

TweetDeck and Window Title Bars

I've just downloaded tweetdeck and it looks really beautiful.  The Adobe AIR install worked seamlessly as well, working with Java it's easy to forget thats possible :P

The problem is that TweetDeck uses the standard title bar in XP and I assume for other operating systems as well.  This is fine for systems that actually look nice like Mac and some of the newer Gnome skins but in XP this is noticably ugly since the rest of the UI looks so nice.  Firefox also suffers from this when using the Personas plugin.  It isn't that difficult to have an undecorated window and create a custom title bar is it?