Finding the Maximum Possible Value in a Set Number of Bits

I needed to find the maximum possible value for an unsigned 64-bit int, what better way that to write a script a groovy to find it, and numbers of bits if I need it again? One problem is that java cannot handle unsigned values so the only option is to use the next biggest primitive but a long is the biggest int type available, except for the BigInteger which can handle any value. You can force a number in groovy to be a BigInteger by suffixing the number that is being assigned with G.


def bits = 64;
def maxValue = 0G;
def bitValue = 1G;

for (int i=0; i<bits; i++)
{
  maxValue += bitValue
  bitValue += bitValue
}
println maxValue

------------------------------

18446744073709551615


Hungarian Notation on Type Names and Eclipse Java Browsing Perspective

For a few years I've been using notation on class names, for example IDisposable for interfaces and names like AbstractCollection for abstract classes but recently I stopped and started named classes only using terms in their domain.  I believed this described the code and make it more understandable and in some ways it was.  It was easy to see what kind of type the class with the cost of obscuring what the class is responsible for, classes also get alphabetically sorted so similiar classes are not next to each other in the package (having a greater number of classes in a package is useful since package scope can be enforced).

Another problem is that the class is less flexible to change, actually its usage is less flexible.  If this coding standard is imposed and a class needs to become an interface or abstract then the class name needs to change everywhere that its used, in a whole bunch of files.  This makes the code commit really ugly, in the worst case you don't own all of the code that used the class so its not possible to easily change it.  As long as the class didn't have a public constructor then its quite viable to make a class abstract or an interface.

The deal breaker for me was when I started to use the eclipse java browsing perspective, an excellent write up can be found here.  After dabbling with Pharo Smalltalk I started to wonder why this was preferred, after a couple of awkward days I found that it was much easier to use and showed me much more useful information, more concisely, including the class type information that I was encoding in the class name. 

Miglayout DSL

Here's an embryonic DSL for MigLayout in Java.  Statically imported enums turn out to be a pretty handy alternative to Smalltalk or Erlang atoms.  Unfortunately I can't find the HTML syntax highlighter for Java.

import static MigBuilder.*;

Object mig = mig(size(BUTTON_WIDTH, BUTTON_HEIGHT), gapleft(LEFT_GAP), hidemode(zero), growx, growy);
        

String migconstraint = "w 11!, h 52!, gapleft 3, growx, growy";

enum MigBuilder {
  grow, growx, growy, push, gapleft;
 
  public static Object mig(Object...strings)
  {
    StringBuilder builder = new StringBuilder();
    for (Object object : strings)
    {
      if(object instanceof MigBuilder)
        builder.append(',');
     
      builder.append(String.valueOf(object));
    }
    return builder.toString();     
  }
 
  public static Object size(int width, int height)
  {
    return mig("w ", width, "!,h ", height, '!');
  }
 
  public static Object gapleft(int pixels)
  {
    return mig(gapleft, pixels);
  }
 
  public static Object hidemode(HideMode hidemode)
  {
    return mig("hidemode ", hidemode);
  }
}

UML

I was reading this article about the supposed best use of UML diagrams during the course of a project, in particular, generating code from UML is useless.  I have to agree that it seems pointless, once the generated code is modified the UML diagram is no longer useful and can no longer be used to generate the source.  Maybe this has just be used in the wrong way.  UML could be used in the same way as a unit test.  Perhaps initially it could generate code but also assert that code sticks to the design, if not then this test would fail and the architects would be notified.  This would help keep the architects up to date on what the codebase looked like without constant peer reviews, keep the documentation up to date and give warning when the design needed to change.  I have a feeling this is already done by someone.

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