The summer break is finally here, and I for one am very excited about this summer. This year I have a SURF student helping me out with the implementation of my “educational database system” in Java. The working name is currently NanoDB, although I am certainly open to other suggestions.
This is my second summer here at Caltech, and one would think it would be more relaxing than my first summer, since I have more things taken care this time around. However, it has been quite busy since we are trying to put together a new and improved homework management system. It promises to be pretty slick, or at least slicker than cs1man was. It is also a Java EE (aka J2EE) application running on JBoss, like cs1man is, but I am using Hibernate for the persistence layer.
However, I kept running into problems with getting Hibernate to actually save changes back to the database! This was really confusing, since I was trying to integrate Hibernate’s session and transaction management into JBoss’ container-managed transaction (CMT) mechanism. I thought that I had gotten it all configured properly, but it just wasn’t happening.
Finally, today I had the key insight - if I am going to use CMT then the application server kind of needs to know about the data-source too! I had configured Hibernate to connect to the database directly, in order to avoid all the hassles of setting up the data-source in JBoss. That had the unintended side-effect of removing my database interactions from the CMT mechanism, and lo and behold I ended up with no committed transactions.
D’oh!
Once I figured that out, I reconfigured JBoss to expose the database as a JNDI data-source, got Hibernate to pull its DB connection from JNDI, and everything started working properly.
Phew!
During the last two weeks I have been on a very exhausting and frustrating journey through the world of Java web and persistence frameworks. I have been looking at a lot of different platforms, libraries, and APIs, and the reality is, it’s hard to get all of these beasts to play together well. These frameworks are simply not very composable, and the Java platform in general doesn’t provide the kinds of mechanisms to make disparate systems easy to snap together. Of course, such language features aren’t very appealing to work on, so they tend to get short shrift anyway, but the cost in development effort is very large.
The interesting thing is that Java does have the potential to provide snap-together capabilities, because of its binary portability, powerful class-loading abstractions, and the ability to create well-described modules (i.e. the whole JAR format). But it just hasn’t happened, and now everybody is just kind of used to manually working out all of these issues. People grumble a lot, but we’re all used to it by now.
Anyway, that is a big topic, and one that would require a great deal of thought and effort to devise an appropriate solution to. But with the explosion of containers, and persistence mechanisms, and web-service frameworks, and so forth, the need for something to make it easier to compose these systems is only going to increase. Even if it’s just something akin to a thread analyzer, like a classloader/dependency analyzer that will monitor your system and tell you exactly what is messing everything up.
As for me, I’m going to go with something much easier to get working, because I have a deadline! 
Well, it’s the end of the term, and this also happens to be the first term that I’ve had an Advanced Java track to teach, so I have kind of been looking around for good topics to cover. It always seems to be this way with Just-In-Time course development. Anyway, next week’s topics are going to include Java logging frameworks, and that is quite an interesting topic all by itself. Unfortunately, it’s far deeper than I will have time for in class…
I ran my Traveling Salesman GA program on a 200-city tour overnight, and unfortunately it didn’t get too far. That was a little disappointing. But, I have some ideas!
I just finished a prototype for what I hope will be a good “fun Java lab” for my students. It’s an implementation of the Traveling Salesman Problem, as “solved” by genetic algorithms. I have it running on a map of 200 locations right now, and it is slowly but surely progressing in the right direction. That’s always encouraging!
It sure beats my artificial-ant simulation where the ants went away from the food! That one still needs some work…
With N locations, there are (N - 1)! / 2 different paths that can be chosen for the salesman to follow. So, for my 200 locations, there are around 2×10^372 different possibilities to be considered. The GAs search a whole lot less options than that (understatement), and they almost certainly won’t find the optimal solution, but at least you can watch them get better over time!
I have half a mind to leave this running overnight, but I’m not sure if my implementation can even cover the search-space completely. There might be a bug that prohibits it from fully exploring the search-space. But, I’ll let it go - see what I find in the morning!
I have seen this every term in my Java track so far. “Is [whatever] like C++ const?” Sorry, no, it’s not. You see, Java doesn’t have anything like C++ const. You might think that final is like const, but it’s not:
final variable in Java can be assigned to only once, but if the variable is a reference-type, you can still change what it refers to. Fun! (Yes, that is what the language-spec says.)
const variable in C++ can be assigned to only once, where it’s declared, and nothing is allowed to change about the value, whether it’s an object or not. Now that is a nice feature!
I would like Java to have an equivalent to C++ const. Some people have actually worked on variants of Java that include const or something like it. (Just search the web and you’ll turn up more than a few!) But, for now, const is just a reserved keyword in Java, waiting for an implementation.
Don’t misunderstand - it’s still in beta right now - but I am still pretty excited about Java3D 1.4 being released soon. Version 1.4 of Java3D is focused on introducing one major feature: programmable shaders! And, given that I have just been learning about GPU programming, I think this is pretty awesome.
It looks like the Java3D 1.4 shader-support only allows “uniform” shader-variables; that means their values don’t change on a per-vertex (or per-pixel) basis. Rather, you set the variable before rendering a whole polygon or a group of polygons. I think this is a fine limitation; that is the most efficient approach to use, and it also matches up with how a low-level feature should be used from a language like Java.
Anyway, something new for me to download and play with…
Last night I was looking through some of the Java 1.5 API documentation, and I discovered the java.io.Closeable interface. “A Closeable is a source or destination of data that can be closed.” And, you guessed it, the Closeable interface has exactly one method: close().
Thanks! How in the world did we get through five major Java releases without having this interface? I have no idea…
Then I discovered a second Java 1.5 addition, java.io.Flushable. Again, it has exactly one method: flush().
Now, this definitely strikes me as an obvious case of over-engineering. If closing or flushing an object were a lengthy procedure that required some level of attention, then I could see the justification for having a couple of special interfaces. In that case, Closeable and Flushable would each have a couple of methods to track the closing or flushing operation, and it would be really obvious why “It’s such a good idea to have these interfaces!”
However, as it stands, I can’t find a single method in the Java 1.5 API that actually takes an argument of either Closeable or Flushable; they are only used in class-declarations for the java.io and java.nio.* packages. So, presumably, somebody thought it would be a Good Idea, and that was that!
Of course, now we need to have a javax.swing.Closeable interface, for all of the different UI-widgets that can be closed. I mean, how are you supposed to know whether you can close a particular UI-widget? Dialogs and windows and frames cry for a special Closeable interface of their own.
Finally, can somebody explain to me why java.net.Socket doesn’t implement java.io.Closeable? It has a close() method - an obvious candidate for this special new interface.
This evening I got a bug: I wanted to see how easy it would be to implement a profiler using the new Java 1.5 java.lang.instrument API. Not being a native speaker of JVM bytecodes, I also downloaded the Javassist package from the JBoss folks, and started tinkering.
A few hours later, I was able to run various Java programs, and get a dump of object allocations and deallocations as they ran. All with a couple of Java classes that get to transform the bytecodes of classes as they are loaded. Sweet! Most of the hard work centered around figuring out Javassist, which at times produced the telltale impulses of wanting to rip my hair out. But once I worked through those issues, it was remarkably smooth sailing!
This was mainly a proof-of-concept, but now that I know it works, I’ll have to refine this thing! The return on my efforts is pretty high, because of how easy this has all become. It amazes me, what you can do with these things by now.
Sigh, now to get only five hours of sleep, again…
You are currently browsing the archives for the Java category.
