Sparx Systems Forum
Enterprise Architect => General Board => Topic started by: kiwi on February 28, 2002, 07:12:47 am
-
Hi all,
Ok this is a biggie post, as I thought it would be when I got to this stage.
Java generation has come leaps and bounds since I last tried this in EA (it actually looks like java :) but it still has some stuff that needs work. Unfortunately I know the conflict between a general-purpose code-gen and language-optimised. I'll put my view in anway since I'm keen to see these things work, and perhaps there'll be a general-purpose answer to at least some of the questions.
Firstly: a bug: you must put a default return statement in methods (null for objects, 'true' for booleans, 0 for int, etc) for classes that don't have one. This will at least make the class compile, which will not for any method defined in EA that doesn't already have code in it.
Secondly: a 'kind of bug'. Finalize methods in java are almost -never- used. Just remove that finalize() super.finalize() business. Finalize is not used a C++ destructor because Java has garbage collection. Finalize() is called when the garbage collector has detected that there are no more references to it: this could be only when the system has actually run out of memory (and is often done this way). Finalize() is only useful when you have references to resources that are outside the control of the garbage collector, for instance, native calls etc. So in summary: just kill this bit, it's a waste of time and it's confusing.
Right. Now Java codegen. Hmm. The big thing here is the desire to have access to basic types. This can be included simply by having a large list of java classes in the 'Language Types' menu. That's cool, but then there are namespace (aka package) issues too (see below). I dunno whether namespace issues can be resolved, but basically java programmers want this:
- Don't use the namespace delimiter if the object referred to is in the same namespace as the object being generated (this makes sense and by default is what happens now)
- You MUST use the namespace delimiters if it's in another namespace (it doesn't do this, so code won't compile if the objects span more than one namespace, which is very common in java). Even smarter and cleaner is to use namespace import statements just after the package statement in java, which means later you can just use the name without package prefixes.
- it'd be really nice if there was an option to put the files in folders that correspond to the appropriate namespaces. Java requires that they be in nested folders.. this is not a HUGE thing because you have path settings for each class, but renaming a package causes all sorts of problems.
- you should be able to specify namespaces for language types. This way one can cleanly define the java types used (java.lang.String, java.util.Date etc etc) and then the namespace matching code above would click in cleanly.
- then finally, have an option to hide namespaces from Attribute names: so in the diagram, it's Name:Entity not Name: com.company.bing.bang.hamster.ducttape.Entity
- You really want also to be able to specify that an object extends and implements other classes too, that perhaps may not be in the system. I'm thinking of this because my core entity classes are ultimately going to be generated by TORQUE which is an OR mapping tool by Jakarta (see http://jakarta.apache.org/turbine/torque for a really hard-to-navigate overview of Torque)
Another point re autogen comments, this is an easy one: Class comments: if they’re in java, use /** **/ etc instead of what's used now ('//') and use javadoc comments like @author, @version, see for example http://www.devdaily.com/java/edu/pj/pj010014/pj010014.shtml for a simple overview (you can even put @see for references to other classes that it has links to). This then allows javadoc to generate Nice Pretty documentation with links.
I know there's a lot here, but definitely having this stuff would be Very Cool and definitely go a long way to making the java codegen usable.
and... if I could have it all by tomorrow that'd just be marvellous
;)
-
Hi,
I will try and look thru all your points over the next week or so. Most seem pretty straightforward, so I am hopeful this wont take too long to sort out.
Thanks for the detail,
Geoff
-
Julain,
Nice to see another Jakarta proponent. Your point could also be extended to Struts as well I would think, or even JBoss extensions or even Casto (JDO and XML) <smile>.
Steve