CodeFutures FireStorm/DAO 3.0 is now available.

FireStorm/DAO is a Java Code Generator that can import existing database schemas (from a SQL script or from a live JDBC connection) and can then generate a complete persistence tier based on any of the following Java persistence technologies:

• Java Database Connectivity (JDBC)
• Java Data Objects (JDO)
• Enterprise JavaBeans (EJB)
• Hibernate (new in Firestorm/DAO Release 3.0)

FireStorm/DAO generates code that is compliant with the Data Access Object (DAO) design pattern (DAO is a core J2EE design pattern). For the new release, FireStorm/DAO can now also generate native persistence code for Object Relational Mapping (ORM) products (such as Hibernate or JDO-based products).

The change log for the new release shows over 100 improvements, with the headline features such as Hibernate support, better Mac OS X support, and including the Apache Derby database for local development.

The product announcement is here:

http://www.codefutures.com/firestormdao-release-30-ga/

The product is available for download here:

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

Great to see a new major release from CodeFutures. I've been using Firestorm since version 2.0 and it really takes the grunt out of DAO work. The quality of the generated JDBC code is excellent.

The Hibernate support is something I've wanted for a while. It has been a while coming, but at initial glance it looks like they've done it again.

Great interface, I can't wait to see spring and Xdoclet supported by Firestorm.

Great interface, I can't wait to see spring and Xdoclet supported by Firestorm.

Support for Spring JDBC and Spring MVC is planned for version 3.1

Great interface, I can't wait to see spring and Xdoclet supported by Firestorm.

Does anyone seriously still use that? I'd be really surprised if there's any demand for that feature.

Great interface, I can't wait to see spring and Xdoclet supported by Firestorm.

Does anyone seriously still use that? I'd be really surprised if there's any demand for that feature.

I think Xdoclet is a great solution when you want to keep your configuration close to your code, it's really neat to maintain. If by this remarque you mean that Xdoclet should be replace with JDK 5 annotations, I agree, but for now it cannot be the case, in most area, maybe it will ...

Are you sure, you are not close associate of FireStorm.....
I have evaluated fire storm and in all honesty not very impressed, If anything it is a gloryfied DAO genrator which any adequate developer could write with X-doclet or XSL. If you are going to have 1:1 mapping of DAO to an entity or BO you must be MAD and if your design requires this, you better go back to design school..

Are you sure, you are not close associate of FireStorm.....

I'm not sure if that question was directed at me or not but I am CTO at CodeFutures and the architect behind FireStorm/DAO. That's the reason why I know what features are planned in the next release ;-)

If you are going to have 1:1 mapping of DAO to an entity or BO you must be MAD and if your design requires this, you better go back to design school..

FireStorm/DAO doesn't limit applications to having 1:1 mappings between business objects and DAOs. FireStorm/DAO does generate DAOs for each table, view and stored procedure in the database and also allows DAOs to mapped to any SQL statement (including multi-table joins and bulk updates). These DAOs can be utilised by the business objects and services tier in many ways and this is not dictated by FireStorm/DAO.

Cheers,

Andy Grove
CTO, CodeFutures

...If you are going to have 1:1 mapping of DAO to an entity or BO you must be MAD and if your design requires this, you better go back to design school..

Get off your high horse pal. If your database is modeled correctly, a 1:1 mapping of DAO and entity is a beautiful thing - a very simple and elegant pattern that even junior programmers can follow.

...If you are going to have 1:1 mapping of DAO to an entity or BO you must be MAD and if your design requires this, you better go back to design school..

Get off your high horse pal. If your database is modeled correctly, a 1:1 mapping of DAO and entity is a beautiful thing - a very simple and elegant pattern that even junior programmers can follow.

It depends, different applications connected to the same database can see it in different ways, but "CREATE VIEW" exists for this reason, probably it is the best way to map entity to table if SQL skills is not a problem (I am not sure design school can help to solve this problem, but any book about SQL must help)

...If you are going to have 1:1 mapping of DAO to an entity or BO you must be MAD and if your design requires this, you better go back to design school..

Get off your high horse pal. If your database is modeled correctly, a 1:1 mapping of DAO and entity is a beautiful thing - a very simple and elegant pattern that even junior programmers can follow.

It depends, different applications connected to the same database can see it in different ways, but "CREATE VIEW" exists for this reason, probably it is the best way to map entity to table if SQL skills is not a problem (I am not sure design school can help to solve this problem, but any book about SQL must help)

The starting point for FireStorm/DAO is the database schema. There are, of course, very many good reasons not to use a 1:1 mapping. But if you don't have a good reason, then I recommend using the most simple approach, which is 1:1.

In fact, taking the most simple approach is not a bad way to look at the whole area of Java persistence.

For example, there are many good reasons to use JDO, EJBs, or Hibernate if it's required by your application. But if you don't have a good reason, then CodeFutures recommends using DAOs and JDBC.

PJ Murray
CodeFutures Software
Code Generation for Java Persistence

...If you are going to have 1:1 mapping of DAO to an entity or BO you must be MAD and if your design requires this, you better go back to design school..

Get off your high horse pal. If your database is modeled correctly, a 1:1 mapping of DAO and entity is a beautiful thing - a very simple and elegant pattern that even junior programmers can follow.

indeed and if not 100% can be 1:1 then it is still a timesaver that the xx% that can be 1:1 is generated for ya. I also hear that complaint with auto-crud, you must be crazy if your screen reflects your db schema. In lots of situations the screen is a reflection of the schema, as long as finetuning can be done I think it is the way to go.

I've been using Firestorm since version 2.x and find it an invaluable time-saving tool for my small consultancy. I'm seeing much wider use of Hibernate these days so good to see this finally implemented.

Can't wait for better Spring support too. Any plans for integration with common testing frameworks such as JUnit etc?? Firestorm might produce quality code but some developers have terrible SQL skills.

Keep up the good work.

Any plans for integration with common testing frameworks such as JUnit etc?? Firestorm might produce quality code but some developers have terrible SQL skills.Keep up the good work.

We have explored the possibility of adding JUnit tests. The main problem is defining meaningful tests that do not require knowledge of what data to use for paramters to finders and what results are expected.

However, we'd love to hear more about this idea. Can you provide an example of the type of unit test you would like to see generated?

Thanks,

Andy Grove
CodeFutures

We have explored the possibility of adding JUnit tests. The main problem is defining meaningful tests that do not require knowledge of what data to use for paramters to finders and what results are expected.However, we'd love to hear more about this idea. Can you provide an example of the type of unit test you would like to see generated?

I see your point regarding requiring knowledge of parameters etc for tests. If Firestorm could generate the test classes and methods per DAO this might encourage developers to fill-in-the-blanks with data specific to their database and needs. I ended up writing my own tests per table but found they needed to be run in a particular order to be useful. My idea was that the tests could run and leave the database in a consistent state yet satisfy my test conditions. e.g.

-INSERT test Customer,
-run a query or queries based on inserted test Customer,
-UPDATE the test Customer,
-run a query or queries based on updated test Customer,
-DELETE the test Customer,
-run a query or queries to confirm test Customer deleted

Another thing which might be useful for rapid prototyping without having to actually setup any database is to somehow mock a DAO implementation, say using XML files and XMLQuery and a limit of 10 records per table. In theory, a developer could then code and test a system against a lean mock database before choosing a real database with real data.

Also, Firestorm gives you the ability to create custom accessors such as getThis() and getThat() but what about custom modifiers such as updateThisWhereXXX() and deleteThatWhenXXX(). Will this be supported in the future?

http://www.neurallimits.com/

Can this thing generate methods/interfaces/classes from parameterized SQL statements like SQLC does?

Can this thing generate methods/interfaces/classes from parameterized SQL statements like SQLC does?

I'm not familiar with SQLC but FireStorm/DAO does support parameterized SQL statements. In FireStorm/DAO this is referred to as Custom SQL DAO support. You can define literally any SQL statement supported by the underlying DB and define the parameters and/or result columns. FireStorm/DAO will then generate the appropriate Java DAO code.

Cheers,

Andy Grove

May be worth mentioning it costs $595 for the Enterprise Edition (most basic version).

Shimon

We're not shy about the product pricing. There's links from most Web pages on the site.

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

What you might find interesting is the theory behind the product pricing. I've written a blog entry to discuss this.

http://www.codefutures.com/weblog/corporate/archives/2005/09/pricing.html

Information Week has said that 'More than 82% of IT decisions now require a cost versus benefit analysis'. This is particularly true in enterprise Java development, where there are so many excellent open source options.

So in addition to openly publishing product pricing, we also try to provide the information Java developers need to justify purchasing.

PJ Murray
CodeFutures Software

good tool, but please add jsf support. struts and pure jsp are not mainstream today

good tool, but please add jsf support. struts and pure jsp are not mainstream today

Generating the presentation tier started out as a simple testing feature that turned out to be very popular. When we just had JSPs, we got a huge number of requests for Struts.

The market take up of JSF was much slower than anticipated, and so far, we have not had that many requests for JSF.

However, JSF seems to be gaining market traction, at last, and it's certainly on the roadmap.

I guess we're waiting for a major customer to insist on the feature.

PJ Murray
CodeFutures Software

In fact, firestorm is a good souce code generate tool.
But,I think it is not too hard to crack the product.
Though,the product is objconfused ,but we can still unjar and uncompile the class file.
From the main license java file,we can find the product just use sun`s security jar.It used a signature to confirm the license file.
And this is the problem.
As you know,sun`s security jar is open source,we we just need to find the source of the jre version you used,and change the method of sun`s verify signature method(return true),compile and replace the class file of runtime.jar.
So,it will be cracked.
I have tried this way before.