Wednesday February 02, 2005

Java

Makefiles are satan's contribution to software Probably a bit harsh but one of the places I always have trouble is with Makefiles. Regardless of whether I'm building Java or C I normally fall foul of something (Note: I use Apache Ant for all my own personal projects).

My current pet peeve is with Makefiles and jar files. The part of a source tree I am working in generates lots of class files and a handful of jar files. However the ability of the makefiles to correctly rebuild the jar files after I have touched some source appears to be random. This means on occasions when I'm testing changes I find I'm still using old code. This so wastes my time.

(2005-02-02 01:59:28.0) Permalink Comments [3]

Sunday January 23, 2005

Java

webserver + db The other night I was able to grab sometime and continue with one of my own personal Java projects. I wanted to glue together Tomcat and JDOs using JPOX and Derby . This IMHO forms a basic foundation platform for simple web apps. I tend to quickly put together very simple one task apps which are needed for a short period of time.

Then I started to wonder, could I also glue in JAXB and make it generate my JDO classes? Then I could import or export XML directly into the database (either via an web request or as part of some app logic).

Perhaps there is the opportunity to generate (with some help) the JDO metadata from the XML schema. Hmm, given my speed at which my personal project proceed this might be a while. I suspect there are some bright sparks that could quickly tell me the highs and lows of my idea.

(2005-01-23 00:18:32.0) Permalink

Tuesday January 18, 2005

Java

JTree woes (2) Finally got it. The code was trying to collapse the root node and it is this that was causing the corruption and an array out of bounds exception. Removing the collapse call still produces the desired effect. I now need to decide who really was at fault. Either way I don't like the internals of JTree spewing out of bounds exception at me.

Okay next issue...

(2005-01-18 03:11:36.0) Permalink

Java

JTree woes Not having a goodtime at the moment. I have a JTree bug where the list gets corrupted on collapsing all branches so only the root node shows. I've trawled the code, I've traced the code, but I still cannot see why it doesn't work in this instance. The very same code works on another panel so I'm suspecting the data is causing grief. So far though I haven't been able to get a deeper hook on the problem.

I hate days like this!

(2005-01-18 01:09:08.0) Permalink

Thursday November 18, 2004

Java

Intelligent data with Derby, JDO and JPOX... these three items give me something that I have wanted for a long time in my own personal Java apps.

Many times when crafting a Java app I've wanted to have an intelligent data store. Something that I can fire queries at and something that has persistence so that it is available the next time the app is run.

Well of course there are many ways to do this with vanilla Java, custom maps and collections, serialization, etc, etc. All very awkward, especially the data querying.

What I really wanted was a relational database type mechanism that I could throw objects at and then query later. However writing all the classes to wrap the SQL is a drag and specific to each object/table. Also for my sins in the past I had only really ever used Sybase which was far too heavy weight for my Java apps.

In my last job I did get to play with an embedded Java relational database called InstantDB which my last company, Lutris, originally bought and distributed with Enhydra. To make life easier talking to IDB (or any other RDBMS) Enhydra had a package called DODS (Data Object Design Studio). In essence you described some container objects and where they would live in a RDBMS, and DODS generated classes that hid the SQL. It was clunky but it kind of worked.

As I said I wanted to return to the RDBMS object persistence and do it in as a general way as possible. Since my days at Lutris there are some new technologies available that are worth looking at.

Instead of InstandDB a natural choice is Derby, a Java embedded (or standalone server) RDBMS (originally Cloudscape). My first impressions were, "this is really neat". So Derby gives me my data store.

Next is the convenient object to data store mechanism. Well this is where JDO (or Java Data Objects) comes. You have to do more than DODS because you have to generate your inital data objects yourself (the objects that will live in the RDBMS). JDO then "enhances" the classes files. This is the bit that I don't really like. Enhancing your data objects involves modifying the class files and inserting code into them. This all sounds dodgy to me but it works. DODS is different because it generates all the data objects and guts as Java source that then must be compiled.

Included with JDO is JDOQL (query language). This gives you a way of acquiring a collection of a single class of object using a query. The query can refer to the fields of the data object to narrow down the field of returned objects.

JPOX comes into this because it is an implementation of the JDO standard. And it also works with Derby! The two can hook up to provide a RDBMS backed JDO configuration.

After some days of head scratching last evening I finally cracked it. Now I have a simple person object that I cam insert into my data store. Then I cam query fields in my person object when I need to retrieve specifc objects.

When I get a chance I'm going to try something a little more ambitous. A good resource for JDO information is JDOCentral.

(2004-11-18 17:00:43.0) Permalink

Wednesday October 20, 2004

Java

JAXB frustration re-visited...

well last night I fixed my JAXB problem. Well actually I read a forum about a different problem that made me look again at my problem. My schema has a complex type AnyOldThingType which is just used to contain a string:

<xsd:complexType name="AnyOldThingType">
    <xsd:simpleContent>'
        <xsd:extension base="xsd:string">
            [...attribute groups...]
        </xsd:extension>
    </xsd:simpleContent>
</xsd:complexType>

Earlier in the schema I have a global element referencing my complex type:

<xsd:element name="anyOldThing" type="AnyOldThingType"/>

When JAXB's xjc compiler builds the interfaces and implementation classes for my schema it generates two interfaces AnyOldThing and AnyOldThingType. Likewise the generated ObjectFactory also contains two methods for creating implementations of the two interfaces:

 AnyOldThing 	createAnyOldThing()
          Create an instance of AnyOldthing
 AnyOldThingType 	createAnyOldThingType()
          Create an instance of AnyOldThingType

I never really understood why the two methods were needed. When I tried to create an instance of the anyOldThing tag I used the createAnyOldThingType() method.

This is where I was going wrong. This just creates the contents, not the tag itself. Hence the enclosing tag was adopting the contents and attributes.

Once I switched over to the other method (createAnyOldThing()) the tag and the correct contents appeared in my new marshalled file. Hoorah!

Monday October 18, 2004

Java

JAXB frustrations... aaarrrggghhh! I spent sometime this evening playing with JAXB. I've got a schema, I can unmarshal a file, marshal it back to file, no problem. However when I try and replace nodes within the Java representation I can't correctly marshal back to a file. The new tags contents (a string) and it attributes appear on the parent tag, the new tag is no where to be seen.

I've employed a validation handler, but that tells me all is fine.

Time to bang my head against a wall, then go to bed and sleep on it.

(2004-10-18 16:50:02.0) Permalink

Wednesday September 15, 2004

Java

JNI hints and tips (2)... spent along time over the last couple days tracking down a JNI problem which could have been solved really quickly if there were better error reporting.

After extensively altering both the Java and C side of my JNI code my tests would only return an UnsatisfiedLinkError on the first native method called. I looked at the method and function signatures and saw no problems. I looked at the C code implementing the native method, no obvious problems. Then I did lots of head scratching.

Finally I decided to create a small Java class on the side that simply tries to load the JNI code, no other exception handlers, nothing. This revealed that a C library call was unsatisfied in a different native function to the function given in the error message. The result was I had neglected to link in the said library. The conditions that caused the error is now obvious.

So the tip is, when things go wrong in JNI don't get bogged down with the error message. The real problem may exist somewhere else.

(2004-09-15 02:45:24.0) Permalink

Friday September 03, 2004

Java

JNI hints and tips... yes I am once again dabbling in the world of Java Native Interface. Oh what a joy. For those of you who haven't a clue what JNI is, it allows the (soft comfy) Java platform access to the (cold raw) host platform running the Java virtual machine. JNI gives the programmer the chance to really lash things up by either confusing the JVM or by performing some awful action outside of the JVM (like memory leaking or dereferencing stale pointers).

In essence JNI is just "glue", it is normally a small section of C (or some other language binding) that converts Java representations of values into native representations and vice versa. Once converted the "glue" can call native functions or Java methods if needed to move things along.

This why it is interesting, the JNI programmer has to remember that Java is very picky about object references and who is holding them; whereas the native side is very picky about keeping pointers valid and memory allocation/deallocation tallied up. In my opinion this squares the chances of messing up as you are answering to the two beasts in the same code.

This is why I try and stick rigidly to certain rules then writing JNI code. They may not be perfect but they work for me and I'm always open to new suggestions.

1. Clear names -- make the variable names clear as possible. In many case, for instance when working with strings, there is normally a Java reference and a native reference. Make it clear which is which, getting them mixed up will make life really hard when debugging your core dump. Also I find for an object I will end up manipulating the object reference, the class name and the class reference. Make sure this is all clear in the name so you know what you are dealing with (fooBar, FooBar_class and FooBar_class_name).
2. Keep it simple -- keep the JNI sections as small as possible. I define small as possible as the smallest amount of code and functionality. Put complex or even simple native functionality in different functions that don't need to know about JNI references and are as standalone as possible. I know this sounds obvious but sometimes I just get tempted to do it all in the one function. Try and avoid having to pass the JNI "env" pointer down into you native code. If you do it means the JNI code is leaching out into other places which is a bad thing. Of course it is acceptable to decompose common functions within the JNI "glue", just make sure they are only used by your JNI "glue" and that the exit and entry state is clearly known (or documented). Write Javadoc style comments if you want to.
3. Stock take -- everytime you allocate memory or acquire a reference remember to release it back if the memory or reference are only used locally to the JNI "glue" function. I find the best way to do this is by using the hated C "goto" statement. All my "glue" functions leave at the end of the function. If I need to stop executing a given function I goto the functions exit code after goto label. The code after the label checks the unwanted memory and reference variables and if they are not NULL are freed/releaseed in the appropriate manner. This also means that you must be conditioned to set them to NULL if you release them earlier in the function. To overcome this problem I have a couple of macros that complement the standard JNI free/release methods. The macros check for NULL before executing the intended free/release operation and always assign NULL at the end (this also means I make sure that all pointers are assigned NULL at the top of the "glue" function, but you do that anyway). This is why you need to keep the JNI "glue" simple, small and contained. Otherwise you will loose track and forget to do you house keeping. If you have decomposed chunks of you JNI "glue" into other functions consider using PushLocalFrame/PopLocalFrame as it will automatically release unwanted local references.

Monday August 23, 2004

Java

Very dumb toString()... ah, occasionally all my intelligence gets left behind at the coffee machine. Today I spent time debugging a really dumb toString() method. I was using the method to debug the object and see its contents. Alas its contents contained a Map where the values were related instances of the same object. Some of those objects contained references back to my original object. Hence once in toString() all hell broke loose inside an endless loop. The main hinderance to my realising the stupidity of my code was that the error telling me the problem was being eaten by a method higher up the stack. Hopefully my intelligence has finished drinking coffee and will decide to join me at the code face tomorrow...

(2004-08-23 16:46:24.0) Permalink Comments [1]

Friday July 16, 2004

Java

Finding those elusive exceptions (2) ... Thanks Tom for suggesting I take a look at AspectJ. I'll add it to my (ever increasing) list of interesting things to look at.

(2004-07-16 08:44:50.0) Permalink

Java

Finding those elusive exceptions... I always get frustrated when changing or debugging Java code where Exceptions are not chained or propogated higher up. I have spent many a debug session not understanding a problem only to find a try/catch either not logging an exception or generating a new exception. So I thought about it to see if there was anyway I could tip the scales in my favour.

The obvious solution is to search for every try/catch and modify them to generate a log message or throw a new exception. This doesn't really work though if you don't know the code very well because occasionally an exception might not actually indicate a fault. It also requires you to find every try/catch which is a chore in very large applications and it only works if every future try/catch is similarly coded. Yuk, too much duplication.

What I really want is a way of being told about exceptions without disturbing the running application. I could probably use the java debugging API but that might be to heavy and intrusive (my guess, not fact). Then I thought about the normal Event/Listener approach commonly used in Java. What if I could register an EventListener with Throwable? Everytime an Exception is generated my EventListener is given an Event detailing the Exception (message, stack trace, cause, ...). This could be done now with my own Throwable subclasses but if it was in Throwable all Exceptions would also generate events if requested to. So giving a central point for debug logging.

I recently wrote a small GUI utility that displays lists of generated Exceptions in a separate window while the application ran. I had to annotate each try/catch I was interested in. The GUI had the benefit of linking together exception chains. I could move up and down causes which was helpful. Now if Throwable could send me events when an exception is thrown my GUI could work mostly with unchanged applications. All I would need to do is wrap the main method so that I could register my event handler. Alternatively if an event handler was specified on the JVM command line the app could run mostly unchanged.

I've probably missed something really crucial...

(2004-07-16 06:36:58.0) Permalink Comments [1]

Monday July 05, 2004

Java

J2SE 5.0 -- You may not agree but it is the right thing to bump the version to 5.0. I think in the past we should have been openly labeling J2SE releases in the same way (1.4 -> J2SE 4.0). There is so much in Tiger (5.0) that Sun really needs to flog the idea that it is a significant release. Though it kinda makes the `2' in J2SE look stupid given that it was introduced in 1.2. I suspect though there is too much invested in the name and anyway J-five-S-E does not roll as easily as J-two-S-E.

(2004-07-05 01:59:50.0) Permalink Comments [4]

Monday June 07, 2004

Java

Those voices in my head

After reading plamere's blog I decided to take a look at FreeTTS for myself. The example classes clearly show how quickly and easy it is to get your Java code speaking.

I then had a thought, "How can I use a talking Java app?".

One of the things that frustrates me with IRC is I get so absorbed in what I'm doing I forget to look at the chat window. Discussions go past that I never get a chance to contribute to (some people may say this is a good thing). Could I remedy this?

Well I've also played with PircBot in the past. PircBot is an amazingly simple set of classes for throwing IRC clients together. You need so very little code to get simplest of clients going.

So I took FreeTTS and PircBot and threw them together and created my own speaking bot with very little code. Okay nothing original and its been done before but what the heck it was an excuse to write more Java code (one or my favourite pastimes).

Now I can listen to discussions without having to take my eye's off of gvim (okay old habits die hard). By varying the voice/pitch/rate based on the name of the message sender I can even distinguish different people as they chat.

One day I'll turn it into a complete speaking chat client in Java! Of course that's after I've done all the other projects I want to do first.



(2004-06-07 16:00:55.0) Permalink Comments [2]

Tuesday May 18, 2004

Java

More fun with Boolean

After reading Uday's blog on Boolean.getBoolean() it reminded me of some interesting code I have recently seen that uses Booleans in an odd fashion. I'd like to share this odd use because I can only convince myself that it something I shall never use because I really can't put my finger on the expected behaviour.

    private Boolean l = Boolean.FALSE;
    ...
    public void someMethod() {
        ...
        synchronized (l) {        // S1
            if (l.booleanValue())
                return;
            l = Boolean.TRUE;     // A1
        }
        ...
        synchronized (l) {        // S2
            l = Boolean.FALSE;    // A2
        }
        ...
    }

Is this code very smart or very dumb? I err on the dumb side (mainly because synchronizing everywhere on Boolean.TRUE and Boolean.FALSE will cause lots of unecessary contention).The biggest problem I have is the switching of the reference ('l') inside the synchronized statements. Given that the monitor used for the synchronization is in the object at the end of the reference, switching the reference is presenting a different monitor which may or may not be locked by another thread.For instance, if one thread has just completed (A1) and another thread is just about to do (S2) I'm sure that unintentionally both threads can enter the synchronized sections. The same is true for another thread that is about to execute S1. This scenario might come off better because of the condition that 'l' must be false before proceeding.

Thankfully the synchronized code doesn't do any tinkering with data structures so isn't unsafe. I think that it all really comes down to how the Java memory model behaves. Given that double-checked locking doesn't actually work I would steer very wide of the above code.