Alignment: Chaotic Java

Saturday, December 24, 2005

XML to POJOs Example - Contacts List

Showing off X2J I created the following XSD example, which is a simple definition for a contact list which can store connections between the contacts:


<?xml version="1.0" encoding="utf-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
  <xs:element name="contactList">
    <xs:complexType>
      <xs:sequence>
        <xs:element name="contact" minOccurs="0" maxOccurs="unbounded">
          <xs:complexType>
            <xs:sequence>
              <xs:element name="friend-of" type="xs:string" minOccurs="0"
       maxOccurs="unbounded"/>
            </xs:sequence>
            <xs:attribute name="name" type="xs:string" />
          </xs:complexType>
        </xs:element>
      </xs:sequence>
      <xs:attribute name="owner" type="xs:string"/>
    </xs:complexType>
  </xs:element>
</xs:schema>



You can see I'm using "friend-of" as a list of names. When an XML binding generator creates classes from this, it is likely to produce a String[] getFriendOfArray() or something similar.

Check out the corresponding X2J code:






01 @Element
02 public class Contact {
03   @Attribute
04   @PrimaryKey
05   String getName() {..}
06   
07   @InnerElement
08   @ArrayElement(label=false)
09   Contact[] getFriendOf() {..}
10 
11 }



Java2html




You can see how I can access the Contact instances who are friends with a certain Contact instance immediately; Also, when an XML conforming to this X2J annotated class is parsed, any contact on the "friend-of" list will be checked for existence as part of validation testing, something that (to my humble knowledge) just wouldn't happen in a regular XSD generated class.

I'd love to hear comments, remarks, bashings, suggestions... Anything.

Related Topics
XML to POJOs alpha 0.1
Possible Advantages of X2J: Primary Keys
X2J on the firing line
Interesting Topics
XML to POJOs Advantages - @Converter

Thursday, December 22, 2005

XML to POJOs Advantages - @Converter

One of the poorest things in XML binding is when the binding framework generates classes from your XSD where you would have used a normal JDK class. For example, consider the following:


<schedule>
  <appointment>
    <date>
      <day>3</day>
      <month>4</month>
      <year>2005</year>
    </date>

    <desc>Meet Omer and Tal</desc>
  </appointment>
  <appointment>
    <date>
      <day>23</day>
      <month>12</month>
      <year>2005</year>
     </date>

    <desc>Joanna is coming</desc>
  </appointment>
</schedule>


Surely I wouldn't want it to create a class for the <date> element, but for it to use the Calendar (javadoc) class!

Well, that's exactly what @Converter does. The X2J framework provides you with an Assigner interface, which will receive all the XML elements related to the parsing of the member annotated with @Converter, and will be responsible to assign the values derived from the XML into the non X2J-annotated Java class.

Related Topics
XML to POJOs Advantages - Repeating Types
Possible advantages of X2J - Primary Keys

Wednesday, December 21, 2005

XML to POJOs - Alpha 0.1

I invite you all to read the code, try the test suite, write your own tests, make it crash and submit bugs, everything at the project's web page! (when SourceForge are working, anyway)

Please note that there are some dependencies you need to get, namely resolver.jar, xercesImpl.jar and xml-apis.jar from the Apache Xerces project. Download page here.

Enjoy!

Related Topics
X2J on the firing line
XML to POJOs advantages - Repeating Types
Possible advantages of X2J - Primary Keys

Thread Static List in Java

We all know what a Thread is and what Static means, and how they collide. For a quick example: I have an event listener method where I want it to have a stopping condition for a suspected recursion. What I want to do is use a Collection of the items I've already received, and check for each call of the listener method if the calling item is already inside the Collection.

I can't add a Collection to the method signature because I can't change it (it came from a listener interface), so using a static Collection in my implemented handler comes to mind. However, what if the event was called from different threads at the same time?

This is, like most of my posts, not a new thing. It's just a nice tool I decided to share its simple code with; Enjoy it or diss it. Here goes:















public class ThreadStaticCollection<T> implements Collection<T>{



  private static Map<Thread, Collection<T>> threadMap = 

    new TreeMap<Thread, Collection<T>>();



  private synchronized Collection<T> get() {

    Collection<T> res = threadMap.get(Thread.currentThread());

    

    if (res == null) { 

      res = new LinkedList<T>();

      threadsMap.put(Thread.currentThread(), res);

    }

    

    return res;

  }

  

  private synchronized void purge() {

    if (get().isEmpty()) {

      thradMap.remove(get());

    }  

  }



  public boolean add(Object item) {

    return get().add(item);

  }



  // Goes on..



  public boolean remove(Object item) {

    boolean b = get().remove(item);

    purge();

    return b;

  }



  // Goes on..

}






Java2html




The get() method will fetch or create the Collection currently available for the current Thread. The Collection interface is implemented by delegating all tasks to what is returned from get().

If items are removed from the Collection, a call to purge() should occur so that the Collection instance could be removed from the static Map. Also notice that both the purge and the get are synchronized for obvious reasons.

Interesting Topics
X2J on the firing line
Time to make a difference in your Java
WebObjects to Cayenne

Tuesday, December 20, 2005

The horrible SAXException

This is obviously going to be one of my rant posts.

I've been working with SAX for a while, and I have to say that the SAXException (javadoc) class couldn't have had a better name chosen for it.

First of all, it can "wrap an exception that is not a subclass of SAXException". Great. But why is it wrapping an Exception (javadoc) class?

Why not accept Throwable (javadoc), the way most exceptions in Java do, including Throwable itself, accepts (javadoc to ctor)?

But that's the least of my problems. I changed my exception class to extend Throwable. My worst problem is when it's thrown - It does not show the Causes! Instead it seems like It only appends their getMessage (javadoc) values together!

Horrible, horrible class. I guess I will have write to the Mustang forums again.

Related Topics
org.w3c.dom should be deprecated
Time to make a difference in your Java
X2J on the firing line

XML to POJOs Advantages - Repeating Types

One of the things I totally forgot mentioning as a major improvement of X2J over XSDs is the most trivial thing: Not having to write complex documents to describe something already natural to you: Defining a class and reusing it over and over again on your other classes.

Maintenence is another obvious issue. Instead of having one huge file to describe all your classes, they are separated over a lot of files. Revolutionary concept, I say! It always felt awkward to me that having an XSD felt a bit like going back to the stone age of programming, having everything defined together in one place, barely readable, hardly reusable.

In X2J however, you'd have your own classes, written in different files (of course!), defining their own validation rules and connecting to one another however they want!

No more thoughts such as "Will I need to reuse this data structure, so I should define it inline or not?", no more silent swearing when you realise you defined it as an inline data structure while it's needed elsewhere!

Related Topics
XML to POJOs project is in the air
Possible advantages of X2J: Primary Keys
Interesting Topics
Time to make a difference in your Java
Reflecting on Generics

Monday, December 19, 2005

Class Enum<E extends Enum<E>>

Check it out. It's not the first time I've seen this, but I've found myself explaining it more than once lately, so I thought I'd share my insights with the blogsphere.

I'm probably not the first and not the last who was baffled by this line. Probably, the thought "What the hell were Sun thinking when they wrote this" came across many, many minds and in many different languages.

At first glance, this looks like the recursive generic definition from hell. However, when examined closely, this defintion makes perfect sense. In fact it could be summed as "Extenders of this class (or interface) can only pass themselves (or extenders/implementors) as E".

Literally, it means "If a class extends this class, it should pass a parameter E. The parameter E's bounds are for a class which extends this class with the same parameter E". Replace E with MyClass for a minute there, and let's look at it again: If MyClass extends Enum, it should pass a parameter E. The parameter E's bounds are for a class which extends Enum<E>, which is MyClass!

With this note of self-created confusion, I'd like to thank you, the readers, for making this blog pass the 1,000 hits in just a little over a month. I have a lot to thank to java.blogs for being a great jump-start aggregator, but nothing can be compared to the feeling I get when I see the counter showing me a user getting in not through java.blogs. So, thanks again!

Interesting Topics
Time to make a difference with your Java
Possible advantages of X2J - Primary Keys

Sunday, December 18, 2005

12daily pro and Andrew Hillman are Comment Spammers

This post is not related to Java.

If you read proBlogger you might've seen this post. I've been attacked by comment spammers in the past and I know how annoying this is.

I think Darren's method is effective, and would take them out to the open for what they are. Hopefully it would affect them in a way.

End of digression.

Time to make a difference in your Java

Well, complaining is fun, but making a difference is even more fun. I've posted this suggestion to the Feedbacks and Suggestions forum of Mustang (The codename for the next Java).

Go, people! Flock and show your support in the reflection mechanism! Show that you really do care about the Class (javadoc) class, however funny it is to say it 15 times straight!

Related Topics
Avoiding Erasure
Reflecting on Generics

Saturday, December 17, 2005

Avoiding Erasure

If you remember my post from yesterday, you'd remember my rant about how generics information is not available in the Class (javadoc) instance.

Well, I've also written something which is wrong: That the information is not found in the .class file. It does, at some level. As far as erasure goes, it will erase all generics information and replace them with the highest bound possible.

However, some bounding information is stored to the .class file, because otherwise it wouldn't know which parameter types to accept. Also, this information is required for the getTypeParameters (javadoc) method.

The simplest solution would be to just create a different Class instance for every different typed parameter set, just like they're creating a different Class instance for every array with a different dimension number and compound type. However, I believe there would be a lot more instances of these differently typed Class instances.

A different solution could be to create another reflector method inside Class - say, a method called Type[] getSpecificTypesFor(T obj) which would return the used types for a specific object. Obviously, that would means saving this information for every Object, but that way a Class instance would always stay the same.

Which is better? And a better question, what kind of a solution would be given to the users?

Related Topics
Reflecting on Generics

Friday, December 16, 2005

Reflecting on Generics

To quote the java.lang.reflect package docs (javadocs), "Reflection allows programmatic access to information about the fields, methods and constructors of loaded classes, and the use reflected fields, methods, and constructors to operate on their underlying counterparts on objects, within security restrictions."

Let me just say that I know it doesn't mention generics. It's weird for me too. But you'd expect it would be there, right?

Let us begin. The interface GenericDeclaration (javadoc) comes to describe any Type (javadoc) that can have generics declared on it.

As you'd expect, the class Class (java) (javadoc) implements this interface and it's single method, getTypeParameters. Unfortunately, this method returns only the declaration type. This is of course a result of a thing called Erasure, which is described here (search for "Behind the scenes").

Fine; I understand why Erasure is needed (and unlike what's said in this post, I do understand why it isn't backwards compatible). However, what should I do? While parsing classes in X2J (sourceforge), I need to retrieve the collection's declared type in order to know what type to instanciate when reading an XML file - And I can't, as this information is not stored in the Class instance (and nor in the .class file!)

My solution for now is to add another parameter to the @InnerElement annotation, but it doesn't seem like the best methodoligy..




Why it (dotNet's Generics) backwards compatible: If I'd change one of my inner modules to start using Generics (externally, anyway) in dotNet, I'd have to change an entire application. In Java it won't happen Because of erasure. That way, Sun could make a lot of their older classes generic while retaining backwards compatibility, while in dotNet they created a new namespace for their Collections, which has a different structure than the original (missing classes, different methods, etc). That way, switching to the generic type fo collections in dotNet wasn't as smooth, as they were different classes.

Related Topics
XML to POJOs project in the air
Possible Advantages of X2J -Primary Keys

Wednesday, December 14, 2005

Factory Design Pattern made simple using Enums

Writing X2J I encountered a state most of us encountered before: The need for a Factory Design Pattern. In my situation, during parsing (using SAX), there is an interface called ContentHandler (javadoc) which is required by my handler. The handler should be created according to the type of the element being currently parsed. An obvious case for a Factory.

Now, I already have an enum such as:


public enum ObjectType {
    ELEMENT,
    ARRAY;
}


I can have a factory class like this:


public class HandlerFactory() {
    /* .. singleton stuff .. */

    public ContentHandler createHandler(ObjectType type) throws X2JException {
        ContentHandler handler = handlers.get(type);

        if (handler == null) {
          switch (type) {
            case ELEMENT:
              handler = new ElementHandler();
              break;
            case ARRAY:
              handler = new ArrayHandler();
              break;
          }
          handlers.put(type, handler);
        }

        return handler;
    }
}


However, since enums can now have properties and methods as part of Tiger's new features and they're not just a group of constant integers, I can do the following:


public enum ObjectType {
    ELEMENT(ElementHandler.class),
    ARRAY(ArrayHandler.class);

    public Class<? extends ContentHandler> handlerType;

    ObjectType(Class<? extends ContentHandler> handlerType) {
        this.handlerType = handlerType;
    }
}


And the factory becomes very simple, such as:


public ContentHandler createHandler(ObjectType type) throws X2JException {
        ContentHandler handler = handlers.get(type);

        if (handler == null) {
            try {
                handler = type.handlerType.newInstance();
            } catch (Exception e) {
                throw new X2JException(String.format(\"Fail to create handler %s\", type), e);
            }

            handlers.put(type, handler);
        }

        return handler;
    }


The added bonus is that I don't have to worry about this factory class anymore - Whatever new enum values I add, the factory will not be changed. I wish I could somehow get away from calling newInstance(), but I guess it's neglegible because I do that once per enum value, which isn't a lot.

Simple, eh?

Related Topics
org.w3c.dom should be deprecated
XML to POJOs project is in the air

Possible advantages of X2J - Primary Keys

I've been thinking a lot about where the X2J framework I'm toying with. I've thought of several problems with XML binding, and several nice solutions. I will give examples of the problems using JAXB, as I know it better than the other frameworks for binding and serialization. I will discuss one problem now, but you are welcome to read all the coming additions to X2J, as shown in the feature requests I've set for myself on the SourceForge page.

Repeating objects



When in JAXB you have a couple references to the same instance. As an example, think of a Schedule instance referencing the same Lecture instance at different time slots (represented by some array contained inside the Schedule instance). When it will be serialized by JAXB, each Lecture item will be serialized separately, as it should be; However, when deserialized, multiple Lecture instances containing the same data will be created. This is, most of the times, unexpected at first use of JAXB for serialization. Luckily, frameworks like XStream do a better job - But they change the way you'd expect to see an XML generated from the serialized class, so that most of the times using XStream for serialization means you have to use it for deserialization as well (Which isn't that bad!)

My suggested solution is reflected in feature request 1380327:


Add a @PrimaryKey annotation, or a value inside the @Attribute
annotation. This will tell the framework to map this object by a
certain primary key, and whenever there is another object with the same
primary key it will be taken from the cache and placed instead of being
parsed.


So that while parsing the data, objects with a set primary key would be cached according to their primary key, and when the same primary key is encountered, the cached item will be set to the referencing object. This way, the generated object tree is created as expected.

Related Posts
X2J on the firing line
XML to POJOs project is in the air

Good ol' genetic algorithms project

I've redirected my old GA project's home page to this blog. This is due to the amount of spammers this project had on its public wiki, which is totally my fault for not maintaining them.

This is an old project I've started long ago in order to create a single framework for applications using genetic algorithms, and eventually it actually found its place in the CodeHaus. In the day, there weren't many frameworks for this.. These days I found quite a few on a quick search on SourceForge's search. If someone finds the project interesting, I'd be happy to start it over again; The reason I stopped working on it was the total lack of feedback, which made me think that no-one really needs such a framework.

I had quite a few ideas on how to improve the framework, so it could be more than nice to work on it again. I love the genetic algorithms subject and enjoy working on projects related to it very much, not to mention talking about it.

Tuesday, December 13, 2005

X2J on the firing line

I've been getting more than one comment about the X2J project I've introduced here and other projects, specifically XStream and XMLBeans. I wanted to clarify the differences (at least the ones I see) between the frameworks to what I intend X2J to be.

The X2J framework, according to myself and the SourceForge title it holds, will "...performs serialization and validation of POJOs to XML, XML to POJOs, POJOs to XSDs, and XSDs to POJOs using Annotations", i.e. will replace the usage of XML Schema Documents by using Annotations. Let's be clear about it - Using X2J means no XSD files needed - You write your own classes, annotate them, and then you writing and reading your data into and from XML documents. It is a binding tool that doesn't use external XSD files for the binding.

You can read about binding tools on a coverpages article about JAXB. To be brief, they state that a binding tool helps "...(1) unmarshal XML content into a Java representation; (2) access, update and validate the Java representation against schema constraint; (3) marshal the Java representation of the XML content into XML content. JAXB gives Java developers an efficient and standard way of mapping between XML and Java code...".

(Yes, I am aware I am shooting really high with this :-) )

Now, about the other frameworks. This is what I understand these other frameworks are meant to do. XStream is a serialization framework. As they say themselves in their FAQ:


Can XStream generate classes from XSD?


No. For this kind of work a data binding tool such as XMLBeans is appropriate.


XMLBeans however is a data binding tool. The way it achieves it is similar to Java Architecture for XML Binding - JAXB. It uses an XSD compiler - scomp - to generate a .jar file containing their pre-compiled XML Schema Object model. Obviously they do a lot more and in some cases a lot better than JAXB, which can be fully read on their Overview page.

The major difference between XMLBeans and X2J is in the binding method. XMLBeans make use of the XSD files; Whenever these files change, they need to recompile their Schema Object model. While this simple compilation process doesn't frighten most of us who know how to use ant, my problem with it is the writing of the XSD files themselves. They are complicated, redundant (as you have the same data structure in your code already in most cases), and hard to maintain (single file for all the data model, instead of the separate Java classes you already have).

The reason behind X2J was to eliminate the need for XSD files, for their complexity and redudancy, and maybe come up with a better way to do XML binding. I would be happy to contribute and join a larger framework - But some are just working on different paths than what I intend X2J to be.

Hope this clarifies some things. I encourage everyone to stand against my words! (or maybe even suggest cooperation?)

Related topics

Xml to POJOs project is in the air

SourceForge approved my project and you can access it.

The page has nothing, really - The default source forge page. I only uploaded the code I have so far; I hope you enjoy it.

Since I was writing this half for self-usage and half for pleasure, this might not (and most likely is not) written using best practices. I implore you - Take the code using CVS and see what you can make of it.

Previously:


Sunday, December 11, 2005

org.w3c.dom should be deprecated

.... Or at least changed to be more easy to use. Take NodeList as an example. Why isn't it Iterable on J2SE 5? And even in J2SE 1.4, why doesn't NamedNodeMap implement NodeList, even though they share the same methods for "iteration" (getLength and item)?

I wrote this simple class. Hope you find it useful:



class NodeListIterator implements Iterator<Node> {

  private NodeList list;
  private int idx;
  private int len;

  public NodeListIterator(NodeList list) {
    this.list = list;
    this.idx = 0;
    this.len = list.getLength();
  }

  public boolean hasNext() { return idx < len; }
  public Node next() { return list.item(idx++); }
  public void remove() { throw new UnsupportedOperationException(\"Can\'t remove\"); }

  public static Iterable<Node> iterate(final NodeList list) {
    return new Iterable<Node>() {
      public Iterator<Node> iterator() { return new NodeListIterator(list); }
    }
  }
}



Sorry about the bad format of the code. Anyone knows of a good code formatter to use for my code copy/pastes?

Saturday, December 10, 2005

XML, Annotations and a simpler life

I've just posted a request to SourceForge so I could open-source my X2J framework.

It's a little something I've hacked up lately that helps me generate XML files from POJOs, and POJO instances from XML files, with validation but Without pesky XSD files.

To illustrate, suppose I have the following class:


class ComplexNumber {
public real;
public imaginary;
}


Suppose real=1.0, imaginary=1.0, I would like to see the following XML:



<ComplexNumber real='1.0' imaginary='1.0' />



More than that, suppose I had this:


class EvenMoreComplexNumber {
public ComplexNumber firstComplex;
public ComplexNumber secondComplex;
}


I would want to see This:



<EvenMoreComplexNumber>
<firstComplex real='1.0' imaginary='1.0' />
<secondComplex real='2.0' imaginary='2.0' />
</EvenMoreComplexNumber>



Sure, I could use JAXB for that - But who has the nerves to use this cumbersum library and crazy XSD files?

This is my solution:



@Root
class EvenMoreComplexNumber {
@InnerElement
public ComplexNumber firstComplex;

@InnerElement
public ComplexNumber secondComplex;
}

@Element
class ComplexNumber {
@Attribute
public double real;

@Attribute
public double imaginary;
}



The X2J framework can validate arrays and limitations and can validate mandatory items. It will be able to generate XSD files and generate the annotated classes from already existing XSD files. Just give me some time. :-)

Just a simple note, before someone puts me up on the cross: I called it X2J just out of the top of my head, "Xml To Java" kind of thing. I wasn't aware when I requested the project name that someone took it already. I hope it's not much of a problem. Further, I hope I won't be allowed with this name and I could choose a different one.

Thursday, December 08, 2005

Atom API for Java?

I've been trying to write something in Java that would automate some of the tasks I do while posting to one of my blogs, such as related links or tags.

I know Blogger uses Atom API, so I've looked around for a Java implementation of the Atom API. I could only find Atom4J, but their links seem to be broken.

If there is no choice, I'll have to write down my own implementation. Is that really neccessary?...

Notifications - Old and New Data

Gary Blomquist was kind enough to respond to my post about Data modification notifications and emailed me with an interesting document about implementing such a case using TCP/IP data transfer to all registered applications. We use a similar system with an Oracle package called dbms_alert. The paper Gary sent me proposed to send an SQL statement which would select the new data - We in turn send the table name and generate our own statement according to the table's name and additional data such as primary key values.

The problem in both methods is the same: We cannot provide the Old Data to the applications registering for modifications. This old data is sometimes crucial, and an example follows.


Suppose a stock item is referencing the shelf it is located on. Suppose the application has a view showing the sum of items on each shelf. If a stock item was to be moved from one shelf to another, the application's sum should reflect that. Changing the shelf the item was moved To is easy: It's the new shelf the item is referencing. But what shelf should have its sum reduced?


This is just a simple example, and we encounter problems like this all over our project. At the moment, we are required to re-create these sums. Since we want to send smart updates to the clients, we need some smart business logic behind it too, so that the clients won't just refresh their entire data cache.

Having an option to view at the old values would solve this instantly: I would know exactly which shelf to remove an item from.

I would like to thank Gary Blomquist again for sending me the article - It was refreshing to read of new methods, and also a great pleasure to know that in this community, people really help each other.

Lightweight Java IDE

Ever since I got Booky (iBook G4 1.25GHz 256MB RAM), I've been trying to delegate tasks I normally would do on my BigMac (PowerMac G5 2GHz Dual 1GB RAM). The reason for this is double: First, I'd like to take my work with me and only deploy it on BigMac, where they could consume resources as they please. Second, I'd like to be able to work from my bed, wirelessly. I'm spoiled.

However, writing code proved itself a bit hard. XCode is great especially because it delegates the compiling task to the BigMac, but it lacks a Lot in certain features such as auto-completion. Eclipse was always a good choice, even though the Carbon look and feel it gives isn't the best for (again, spoiled) users like myself. However, if that was the problem I'd deal with it, and I have done so for some time until I've had enough - Eclipse just crawls on Booky, taking up a lot of resources itself that compiling becomes a daunting task.

I would even buy IntelliJ from JetBrains if I knew it would suit my needs.

And what are my needs? I guess I hold out a cry for the public! (again!)

What I need is a lightweight application for coding Java projects. Auto-completion is a must-have, and at least some way of having a "project view" is a great plus. That's all I require, in fact.