Is this a valid use of an interface?

I saw a piece of code that made me wonder if this was normal when using interfaces or if it is just abusing the functionality of an interface... The code looks like so:

 
public interface Constants {
    public static final String URL = "localhost:1099";
    ... // Other constants defined
}

Later on it is used like so:

 
public class Something implements Constants {
     ...
     Context ctx = new InitialContext( PropertiesFactory.getProperties( URL ) );
     ...
}

Is  it normal practice to create an interface with a bunch of constants in an interface (without any methods defined), then implement the interface in a class and use the constants? 

I would have just statically accessed those parameters directly rather than doing it this way. If you have an opinion, answer to my thought or are just bored, let me know.  Well, perhaps not if you're bored.

Now this is funky

I wrote something funky today. I was trying to create an instance of an inner-class that was part of my Blah DTO. In Blah, there is a List of Foo objects that needs to be populated based on some logic.

private void populateBlah(Blah var) {

   ...
   Foo foo = var.new Foo();
   ...
}

At first glance, I was baffled at the syntax. I had tried doing the obvious

Foo foo = new Foo();

but Eclipse would have none of it. It threw one of these at me when I tried that

No enclosing instance of type Blah is accessible. Must qualify the allocation with an enclosing instance of type Blah (e.g. x.new A() where x is an instance of Blah).

This still made no sense to me after reading. The Syntax just didn't seem right. I was expecting maybe to create an instance of this perhaps:

Foo foo = new Blah.Foo();

but again, that wasn't the case. Anyway, above is apparently how you instantiate a non-static inner class variable. Who knew. You learn something new every day.

Eclipse, svn, javac and the filesystem have made my day horrible

I've got a strange issue out there that I have not been able to solve. At work, we use svn for source control. As is usual, when I get into the office in the morning, I update from svn and then start my day. At some point, I do a build to make sure everything works before I check code in.

We use ant to build all our projects and run unit tests, do static code analysis etc. When I was doing that today, I noticed that ant barfed on a couple of symbol not found errors. I checked our hudson continuous integration server to see if the build was fine and it was. So, I tracked down the classes in Eclipse. They had been updated recently (though one change was a few days old). However, everything was fine there. The symbols that were not found on the command line did exist in the code. Nearly all my projects in eclipse have warnings, but none had errors. A compile issue is an error in eclipse and would have been flagged as such. 

I was a bit confused. So I did a clean in eclipse, a clean in ant and then rebuilt from ant. Again, same issue. Then I searched for all class files that with the class name to see if something was hanging about. I found 2 class files for that class. But that turned out to be normal. Eclipse creates one and ant creates the other. Incidentally, using the file command against the class file will give you some information on what version of java it was compiled against etc. But none of it was useful in solving my mystery. I used javap to decompile the class files and both of them have the signature for the method in question (its a simple String getter).

I was at a loss as to what to do next. I tried to change the end-of-line characters to Unix to see if that made a difference, but it didn't. I deleted the files, updated it from svn and still have the same problem.

I am at a real loss on what to do next. I have got 4 other people to look at me, and they are stumped as well. None of this code is mine. This code runs fine on the CI server. It runs fine on other machines. 

So, it must be something on my environment. I had made some changes to it recently. I turned off a bunch of Eclipse validation because it was driving me nuts (it took far too long to do things). I turned off file system indexing on Windows (apparently, it will make eclipse faster if you do so). I put my file system in the exclusion list for Sophos anti-virus (apparently, that too will make it faster by disabling the on-access scan anti-virus software does).

None of these things should cause javac to not see a method in a class, especially when the file contains it (I checked the files on the file system as well and they methods are indeed there).

So, if anyone has suggestions on what else to try, let me know. I am going to blow away the entire project where the methods are 'missing' and check it out from svn again as my next step. I don't know if that will make any difference. All I know is, I have had a rather frustrating day where I spent time chasing after bogus errors that stopped me from checking in my code.

Hibernate, enumerations and smiley faces

I have a database table that has a column with single character values that are pre-defined. In the application tier, they are mapped as enumerations. So, it can be of value 'A', 'B', 'C' let's say.

Hibernate works well with that when I have to do something like

SELECT * FROM table WHERE columnX = 'A'; 

I use the CriteriaQuery to generate an instance of the object, add the column name, eq, value and viola, I am good to go. I would get an instance of whatever object the table maps to. Great. Keep in mind that my query is a bit more complex (column1 = blah and column2 = blah1 and columnX = 'A').

Now let's say I want to make this somewhat more flexible. In some cases, I need to do this

SELECT * FROM table WHERE columnX = '_'; 

How do I do that with hibernate (given that I am trying to use the enum for the value portion of the Criteria)?

The best I was able to come up with was to pass in null and check in my query creation method whether the passed in value was null; if so, then don't add it to the query (match any single character for a single character column should be the same as not passing in that where clause). Is there a better way of doing that?

Which is faster, contains() or indexOf() in a List?

One of the small things I was trying to solve today had to do with figuring out if something is not a member of a list. The list can be arbitrarily long and I need an efficient way of getting the data.

My first attempt to write that was something like:

public static boolean isNotMemberOf( Object type, List invalidTypes) {
return (invalidTypes.indexOf(type) == -1);
}

This makes for ugly reading though. My next attempt was to use the contains method

public static boolean isNotMemberOf( Object type, List invalidTypes) {
return (!invalidTypes.contains(type));
} 

Internally, contains apparently uses the indexOf call. So the question then becomes, which one is faster and what should I do? Should I just use contains for easier readability (and fewer WTFs a month later on, when someone else sees it)?

Getting better data for testing

I learned something neat the other day that I thought was worth writing about. I write a lot of unit test code to test the code I am writing. Since I use an ORM, I am able to create the persisted 'objects' in memory using mock factories. These are great because you can do something like

MyObject object = MyObjectMockFactory.create(EntityManager)

object.setProperty(blah);

and then use it in my testing and do something like

assertEquals( expectedValue, object.getProperty);

This is great. I especially enjoy using all that MockFactory based magic to create proper data structures in memory. All the relationships between tables in the database are created properly. There is a slight drawback to this approach though. Say you have an object that you are interested in testing. It is related to 20 other objects that you need to exist for your test. Now, you have to create all those objects, associate them properly so that you can use it in your test. Except you don't care about those objects. You just want them to exist. This starts to get annoying after a while. Imagine the object you are interested in is also relevant to many other classes and tests. All of a sudden, everyone has to create that object and its associated objects over and over for their unit tests. This gets painful (and inconsistent) quickly.

So how can we make this better? One solution I came across was DbUnit. To make this really effective though, I ended up using Jailer to extract the data and use it using DbUnit to do the tests. Jailer is really neat. It allows you to model the data structures you care about, filter it and export it in a DbUnit compatible flat file. Once that is done, you use DbUnit to load up the DbUnit xml files, create the structures in HSQLDB and you're off to the races.

The benefit to using Jailer is that you can have consistent data sets for multiple tests that multiple people can now use without having to build up all those 20 objects one at a time and associating them. All that stuff is now taken care of by a couple of calls to the DbUnit API. 

There are down sides to it for sure. In my case, I have to test for some data that doesn't exist or doesn't match up. That is hard when all the data is exported from a consistent database. But you can doctor that after the model is loaded up. You also need to have representative datasets. As in, if you expect 10 types of orders to be in the database for your tests, the exported data better have that. People also need to know what the data stored in the XML files so that they can use them in the appropriate manner.

I really do like not having to generate tonnes of data artificially; rather, it makes sense to get the data that already exists, plunk it into the model and get on with testing.  And this can be extended to large regression testing models. Generate the model, understand it and add more. OF course, you don't want to bloat your DbUnit tests with large data sets... but you can if you want to I suppose.

COBOL!

That's right. COBOL. I am learning COBOL. Its a long story as to why. All I can say is, there are some amazing programmers out there who are retiring now who have written some awesome COBOL programs. It is something of a wonder that so much in life that I took for granted runs on COBOL. And until this week,  I had no idea how much of what's out there is dependent on COBOL and other old languages.

From DMVs to supply chains, lots of things run quietly in the background, making life function. A lot of it is not running today's technology; rather, it is running on mainframes with code written years ago. Food for thought eh?