Code Futures announced an update to its FireStorm DAO Code Generator for Java and J2EE. FireStorm 1.1 generates persistence logic based on a relational database schema. The generated code uses JDBC via a DAO pattern. It can also generate a Stateless Session Bean facade with delegate classes, and a Struts based interface for immediate testing.

Go to FireStorm/DAO at: http://www.codefutures.com/products/firestorm

Press Release
=============
Code Futures Update FireStorm DAO Code Generator

[1 September 2003, London] Code Futures today announced an update to its FireStorm DAO Code Generator for Java and J2EE.

FireStorm reduces the time it takes to develop Java applications by automatically generating the persistence logic based on a relational database schema. The generated source code conforms to the Data Access Object (DAO) design pattern and uses Java Database Connectivity (JDBC) calls to access the database. The generated code is consistent, elegant, contains documentation, and is easy to understand and customize.

“Since its launch in June 2003, FireStorm 1.0 has helped thousands of developers become more productive”, commented Andy Grove, CEO of Code Futures. “With full support for Oracle, Microsoft SQL Server, and MySQL databases, FireStorm 1.1 will now have broader appeal within the Java community”.

“Using FireStorm it is possible to import an existing database schema and have a complete Java persistence tier up and running in less than 5 minutes”, said Paul Kane, COO at Code Futures. “Gone are the days of writing persistence logic by hand. FireStorm should feature in every Java developer’s tool kit.”

Full product information is available from:

http://www.codefutures.com/products/firestorm

FireStorm 1.1 is available for download with immediate effect and is priced from $195 per developer. Source code generated by FireStorm is entirely standards-based and can be distributed royalty-free. There are no runtime fees associated with the generated source code.

FireStorm 1.1 Features Include:

Reverse Engineering of Databases

FireStorm uses an existing relational database as a starting point and generates Java source code to access the tables and views. FireStorm can reverse-engineer from any JDBC data source. Query logic is generated for any foreign keys defined in the relational schema. FireStorm 1.1 supports all versions of Oracle, Microsoft SQL Server, and MySQL.

Code Generation for Java 2 Standard Edition (J2SE)

FireStorm can generate a complete persistence and query service for standalone Java applications. The generated code does not rely on classes other than the core JDK classes.

Code Generation for Java 2 Enterprise Edition (J2EE)

In addition to generating the DAO persistence tier, FireStorm can also generate a stateless session bean façade along with delegate classes to allow the DAO tier to be exposed as part of a Service-Oriented Architecture (SOA). FireStorm also provides the option of generating a web interface based on Struts for immediate testing of the DAO tier.

Ant Tasks for Code Generation

FireStorm contains an Ant task to generate code from a FireStorm project file, simplifying the task of integrating with build systems.

Open XML format for meta-data

FireStorm project files are in a simple XML format so that external tools can be used to manipulate FireStorm projects.

Oracle provide a more sophisticate framework
http://otn.oracle.com/sample_code/products/jdev/bc4jtoystore/readme.html
enjoy :-)

Hi Marco,

FireStorm is a code generator, not a framework. Of course, if you bought an OEM version of FireStorm you could customize it to generate your code to Oracle's framework ;-)

Regards,

Andy.

I use firestorm and I like it so much...
but I don't like the Hibernate code generated

has so many bugs, and it created 2 classes Person(for example). This is not necessary....
I hope the Firestorm will get better...
:(

Neural Limits - new startup but more to come...

http://www.neurallimits.com/

Greetings,

I think it is too expensive for simple code generator. It automates writing of DAO layer. In my opinion, it is missing at least following things:
- nullable columns vs. not nullable
- entity relationships

Good things about it:
- robust
- nice UI, easy to configure
- generates code that does not depend on any proprietary API.

Regards,

Taras

Hi Taras,

I guess the price depends on the project you are working on. One of our customers has in excess of 500 tables in a database - $195 is a small price to pay compared to several months hand-coding of repetitive persistence logic.

FireStorm does support nullable versus non-nullable columns and also supports foreign key relationships between tables/entities.

Thanks for the feedback!

Regards,

Andy.

better UI, incorporation of a sugestion I made (very pleased about that)
looking forward to my next project now the tedium that is writing DAO's has been taken out of the way. FIRESTORM ROCKS!!!!!

I must be the only bozo around..

Why does persistence code need to be repetitive. I think that a lot of techniques like DAO and even JavaBeans are major repetitive overkill for many data driven apps.

The db returns a RowSet, or you can move it to some generic object like Map or something you make up (this can even be cached).. but WHY do I have to write an instance variable for every column in the DB? Why do I have to repeat the names of my attributes over and over again in my app?

What makes this so OO? Such a wonderful architecture?
I think that a lot of these patterns are just repetitive, inneficient (development-wise) and costly.

Why not just factor out the repetitive side?

Sorry I'm a bit offtopic..
<end of rant>

Well, the argument is that O/R which creates objects is good. This is because it:
Preserves compile time and runtime type checking.
Provides a clean API which is losely coupled to the database - you could hide database changes while preserving the API.
Masks SQL from pure Java coders who can't cope.
Can work across multiple DB implementations, embedding SQL optimisations in the mapping code from Object to DB.

BUT,
A simple #map does work, except primitives must be embedded in objects to work properly.
And you lose compile time type checking.

Or
you could take an even more runtime approach and interogate the DB schema at runtime, creating the mapping layer etc at runtime and then thinking this is a good thing. (name that technology folks).

Take your pick, up til now objects have ruled, but emerging aspects could undermine this with a form of runtime generation (note the word FORM). Hashmaps are perceived an bad, but obviously save coding time, and don't require a code generator.

Jonathan

Hi, Jonathan,

No doubt in that - OO is good but in some cases encapsulating each entity in separate objects are overkill. For web sites that does nothing else other then UI for Database with no application logic - just read database and output HTML. It is more efficient to use some simple model as Amin mentioned in one of the earlier posts. Most of the corporate web sites are simple CMS that has to read data from the table and output in some template - one of the simplest solutions is XML(data)/XSL(format output). And it may be portable solution that will not be database specific, DAO layer can be simply configured not re-written.

Regards,

Taras

I must be dense..

I agree OO is good. That is why JavaBeans, EJB, and DAO and some of these other techniques are ... do I dare say .... "bad".

Here's why:

1. If I expose all the attributes of my object, where is the encapsulation?

2. In a JavaBeans and related approaches I spend a bunch of lines of code on reading an attribute and then writing it. I even tried using reflection/introspection to fill up my beans automatically, that reduced a lot of useless code (at the expense of speed) but the empty JavaBeans are still their and are not pulling their weight.

4. API? APIs are for things that don't change. I change the attributes of my DB constantly as I add functionality. APIs are for things that rarely change.. in business this is rarely the case for data (unless you are working on a legacy db).

5. Separation of concerns.. where is that if I have 5 classes that depend on a column (maybe I'm exaggerating but that is why I haven't adopted EJB).

If I want MVC, I just do MVC. I create a hierarchy of Commands (see Command Pattern) that operate at different levels of abstraction (sometimes one calls another). This avoids all the boilerplate code because most Comamnds are generic (for example AddToTableCommand adds a row to a table all it needs is name/value pairs for the values and a name of a table.. reuse is very high).

The only place where I mention the columns are in configuration file that tells the app what I'm interested. The UI generates automagically from this in most cases.

I can still have generic DBs by wrapping DB calls, and by inheritance. O/R mapping makes me end up writing:

name = customer.getName()
lastName = customer.getLastName()
...

yuck!

I don't want to use a Java class for name/value pairs just for the benefit of compile time checking.. If I need name/value pairs, I should use a name/value pair class not a Customer class, a Company class, etc...

Less code is usually better than more code, and is usually more flexible and maintainable (if designed to be such). I can live with the loss of compile-time checking in these cases.

Still clueless... amin

Oh.. one last thing..

I guess in a command based model I'm reverting in a way to a procedural model since I don't have objects in memory that hold all the data and all the functionality.

This is true. I use a relational model to model my business coupled with "procedures" (these are the Commands in Java). I use OO features to model the framework not the business.

But why should I have 2 models if I already am forced to have one (relational is forced on me). Is it a matter of:

"Why build one when you can build two for twice the price"
- Excentric business tycoon, in the movie "Contact"

While some sort of transparent O/R would be good (where I don't even have to deal with the tables...yeah... fat chance), having both an OO and an R model is overkill in my opinion.

<ok.. I've ranted waaaay too much.. and I'm sure I have no clue..>

Hi, Andy,

You absolutely right that price depends on the project you are working on. My point was that rules for code generated for DAO layer are simple and it is a matter of time to write tool that can do it. I agree FireStream is nice finished tool; I would much better see it integrated with IDE like JBuilder or others.

I downloaded evaluation copy and tried simple ERD: Department 1 -> n User n -> n Role, plus User 1 (manager)-> n(employee) User. Maybe, I should spend more time evaluating it but here results:

I generated code for JDBC and BMP EJB 2.0. I expected that it will recognize many-to-many relationship between Users and Roles and creates appropriate code but it created three instead of two entities, one of them represents link entity. I also expected that User entity will have method like "Department getDepartment" and Department entity will have method "Collection getUsers" as it would be done in CMP EJB 2.0, but it did not do that. Another, test was nullable vs. non nullable, one of the table columns was nullable integer but there is nowhere in code to handle that (for example ResultSet.wasNull() or at least ResultSet.getObject()). Again maybe, I need to spend more time on it.

Best regards,

Taras

Surely any decent programmer would identify a pattern a do the code generation themselves. Who sits around manually coding these days !?

Just be sure you don't have any database columns that are java keywords!

And it's a shame there's no Oracle BLOB support. We'd buy it for sure then.

   C

FireStorm generates default Java names for columns but these can be be manually changed before generating code if they clash with Java keywords.

BLOB support is on the roadmap for FireStom version 2.0 (along with custom SQL and stored procedure support) - due for release in October.

Andy.


> Just be sure you don't have any database columns that are java keywords!
>
> And it's a shame there's no Oracle BLOB support. We'd buy it for sure then.
>
>    C

There is support for CLOB/BLOB in the current version. We've been using it for a while.

Never ran into the java keyword issue, thanks for the heads up.

rodger...

Just be sure you don't have any database columns that are java keywords!

And it's a shame there's no Oracle BLOB support. We'd buy it for sure then.

&nbsp;&nbsp;&nbsp;C