Home

	Links
	w3.org Java Home TU Muenchen

Contact

To-Do

Write more documentation. You can never get enough of it. Especially more javadoc in the generated source code.

Write javahelp for the GUI.

There is no version info included and the About dialog is very rudimentary. Hope you do not get annoyed by my grin.

Well, and of course this web site could do better. I have the problem, that I have no own server and cannot use dynamic pages likes JSPs in order to that. If anyone knows a good and cheap host, or wants to feature my site, please tell me. I don't like JavaScript and all this "dirty tricks" myself.

Comments in the DTD should appear as javadoc class comment in the generated source code.

Add a little beautification facility to the generated XMLWriter.

INCLUDE and IGNORE sections are not supported yet.

Add possiblility to generate GoF Visitor pattern enabled sources.

I should rethink and change the license. It is too restrictive.

The Getting Started page is not up-to-date.

Known Bugs

There was a missing argument check causing the generated XMLWriter to thow a ArrayBoundException in method setDocumentTypeDeclaration(style:int).

Rationnal Rose does not like the comments of the form // foobar // and interprets the marker interfaces as not terminated.

There was a severe bug in the inner Handler for MixedContent Elements. A SAXException was always throws due to a missing return statement.

Within the generated XMLHandler there were multiple ChoiceContentSubHandler created for ChoiceElements created. This was not harmful but they were simply not used and blew up the size of the XMLHandler code.

If a SequenceContent embedded within an other child content particle ends with a optional Child, parsing aborts with an Exception, if it is not present.

IDREF and IDREFS Attributes with a #FIXED Modifier won't be compileable if not treated as Strings.

If in the DTD there is a construct like <!ELEMENT foo (something, something)> the generated code will not be compileable. This is because there will be two members with the same name, and to sets of the same get and set methods. You will have to fix this by hand up to now. I am working on it. So the generator will check for similar sub elements and name them different.

NOTE: If you correct this bug in the generated source code by hand, do not forget to change the appropriate XMLSubHandler in the XMLHandler. Especially for ambigious content models like <!ELEMENT foo ((something)?, something)> you have to thing about the sequence of setting the sub elements...

There is some cheating in the JavaCC grammar for parsing the DTD. Some DTD do not get parsed although they are correct and well-formed.

ID and IDReference classes are generated if you proceed to the OutputTab with this Option enabled. And then go back and disable it.

The generated code for an #IMPLIED ID attribute in the appropriate SubHandler is buggy. I need to add a default constructor.

There is a severe bug in the cascaded InputStreams/Readers. Occasionally some characters get dropped.

The new Directory Dialog (Version 1.0.2) freezes the Application under Solaris (and other Unices?).

#FIXED Attributes are generated as final members, but a call to the set-Methods is generated in the Reader.

If you specify a XML file with a PUBLIC DTD, you will get a IllegalThreadStateException. This is because of the little Thread, which makes the moving dots, gets started once again. I will fix it as I know someone uses my software.

With the SAX2 methods optionenabled, XML2Java generates a file called SAX2Reader.java but class name in file is SAXReader.

When an attribute can only have a fixed number of values, an interface xxxxxxValues.java (eg. PageStatusValues.java) is generated. The code iterating through the values to see if they are valid when setting this attribute is buggy. for(int i=0; i>... should be for(int i=0; i<...