CodeFutures News & Industry Commentary Blog

CodeFutures has a real bias for clever technologies (anybody interested in a cool DAO generator?).

CodeFutures has recently worked with virtual databases, which is a very clever technology. Not a lot of Java developers know about virtual databases, but they solve a very common problem.

If you're building an enterpise application that relies on existing data in an organization, you're probably going to come across a wide variety of different storage formats (for example, there's still plenty of COBOL applications storing data in ISAM (Btree) files).

You could use a traditional ETL tool, EAI, data warehouse, or middleware to access this data, which can create yet more data sources to manage.

The virtual database approach is a more elegant solution - and a lot more convenient for Java developers.

A virtual database consists of a meta data dictionary that holds information about an organization's data sources. It knows about the type of data source, the format, and the location of the data.

So far, nothing very special. But there's some additional key points:

-A virtual database allows the real data to stay in situ and accessed in real-time. No data warehouse with data replication issues.

-For a Java developer, a vitual database looks and feels like a normal database. So the data can be accessed through JDBC.

So what could be a very tricky challenge integrating multiple data sources of different formats becomes a relatively easy task (if you're using a DAO generator, very trivial task).

The product that first alerted CodeFutures to the advantages of virtual database is produced by seeMore Technologies. The product is aimed at database administrators (there's an emphasis on usability and reproducing the look and feel of a traditional relational databae) and should not be too difficult for Java developers to master. It allows the creation of aliases for the tables, views, and columns held within the virtual database. Additional views can be created within the virtual database. seeMore also supports native database and Java stored procedures.

Because a virtual database looks like a real database, there was very little required to integrate the seeMore Virtual Database with FireStorm/DAO, apart from some testing.

So now we have a good answer when we're asked about create DAOs to access data from multiple sources.

PJ Murray
CodeFutures Software

CodeFutures is often asked which data persistence techology should be used in a specific project.

The simple answer is: there is no perfect data persistence technology.

The choice depends on the project requirements, the skills of the development team, and if an organization has standardized on a specific data persistence strategy.
For clarification, CodeFutures provides code generation all of the technologies below. FireStorm/DAO can generate Java data persistence code using DAO or ORM style coding for JDBC DAOs, JDO, EJB CMP, and Hibernate.

All technology choices can be combined with the DAO design pattern - which is Core J2EE Design Pattern.

The only strong opinion offer by CodeFutures regarding data persistence technology choice is that if have a tight deadline, the lowest risk choice is JDBC DAOs.

-JDBC DAOs - Data Access Objects are a core J2EE design pattern - so it's a sound approach (provided you're not hand-writing the DAOs!). JDBC DAOs are most simple solution with the shortest learning curve.
Because you are using a design pattern, longer term maintenance costs are reduced because its easier to review and modify the code.
Also, JDBC is a mature and reliable technology - a safe choice.

There's usually lots of engineers around with JDBC experience - which is an important practical consideration.

There are no runtime/deployment fees because you're using POJOs (unless, for example, you decide to deploy in a J2EE application sever).

-EJB CMP - EJBs are more than just persistence, and often they must be used in projects because everything has to be written for a J2EE application server (e.g. internal coding and deployment standards). Not so bad if you're generating the code.
Most J2EE products have runtime/deployment fees.

-JDO - the best data persistence specification. Problems with politics - even if the JCP vote on JDO 2.0 goes well, the specification has been damaged (which was the intention of the J2EE vendors that voted against it, I suppose). Using mapping tools for 200 tables would be a bit of a drag - but JDO is ideal for code generation so you can have your JDO code in a few seconds.

Some JDO implementations have runtime/deployment fees (although the code generated by FireStorm/DAO has no runtime/deployment fees).

The most positive news for JDO is that Apache is developing an implementation. There are several open source JDO implementations already available, but they have failed to gain the type of market momentum and developer community that an Apache project can often achieve.

-Hibernate - Without doubt, Hibernate has market momemtum with a certain developer profile - what Gartner calls Type A - the technology pioneers - who also tend to be the most vocal in newsgroups, etc. Remember this is a proprietary product - there's only one implementation of the API and its not based on any industry specificaiton or standard - but you get the source code so you'll never really be stuck.

There are no runtime/deployment fees for Hibernate.

CodeFutures already has a preview of Hibernate code generation available and in use by some customers and Hibernate was the headline feature in Release 3.0.

In terms of popularity among CodeFutures' customers, JDBC DAOs are clearly the most popular.

This is good news - it means that developers are going for the simplest and most mature technology.

PJ Murray
CodeFutures Software

Open source software advocates in Europe have achieved a stunning victory in the European Parliament yesterday when the Computer-Implemented Inventions directive on software patents was rejected.

It was a battle between small software vendors and open source advocates and European Information Technology and Communications Association (EICTA), an industry group representing big vendors such as Microsoft.

You can read about the campaign here:

http://www.nosoftwarepatents.com/

There are many reasons why Java developers both in Europe and outside Europe should oppose software patents:

Software patents effectively place restrictions on what Java developers can develop - on ideas. If you think about that for even a few moments, it's as absurd as patenting naturally occurring gene sequences.

At the moment, a Java developer can start coding and produce something interesting of commercial value. The start up costs are minimal. At the current rate of issuing software patents in the US, it won't be long before a Java developer has to do legal searches and negotiate patent licenses prior to distributing even the most basic application.

Software is already well protected through copyright (and trademarks) which cost nothing and are pretty much automatic. If software patents become standard practice, then the cost-of-entry to the Java market will increase substantially.

Software patents can and will in the future be used to create or protect monopolies. Just wait until Windows market share is threatened and watch Microsoft's army of lawyers claim a few hundred patent violations. Preventing competition will become perfectly legal.

Already, even the suggestion of a patent violation can hurt the share price of a technology vendor. This puts customers, who don't want to risk getting caught up in court cases. Which means that large players with large patent collections will become the only safe source of software. This will hurt innovation and diversity, which are two key strengths of Java.

It is very difficult to search for software patent violations - which means its almost impossible to guarantee that no patents have been violated. This increases the risks involved in developing new software products.

Large US sofware and technology vendors have formed cartel-like cross patent licensing agreements. These agreements excluse small and even medium vendors, and certainly have no place for open source software. Even a successful independent software vendor with several patents and $10+ million in revenue is completely at the mercy of major software vendors with thousands of patents.

The developing world is looking to Java and open source as the solution to its software needs (Brazil is a high profile example). This whole strategy is threatened by software patents.

Perhaps the worst long term result of allowing software patents is that innovation will be blocked because software is generally incremental and builds on the current state of the art.

You can find detailed research on the effects of software patents here:
http://www.researchoninnovation.org/swpat.pdf

PJ Murray
CodeFutures Software

FireStorm/DAO is probably unique in being the only Java product named after a core J2EE design pattern.

CodeFutures has long advocated that the Data Access Object design pattern is the key to long-term, sustainable Java persistence.

Now, with the introduction of Hibernate support, the marketing message has changed to generating Java persistence code both DAO and ORM.

So why have we added Hibernate support with the option of not using DAOs?

FireStorm/DAO customers that used the previews of Hibernate support were using a version that automatically generated a DAO tier as well as the Hibernate persistent classes and a Hibernate mapping file (*.hbm.xml) for each database table. However, if you think about it for even a few moments, that test market was already pretty much sold on the idea of using DAOs. If you look at the FireStorm/DAO testimonials - all provided without any guidance from CodeFutures regarding content - you'll see that the DAO architecture is the second most popular reason for buying FireStorm/DAO (after productivity).

So not surprisingly, existing FireStorm/DAO users want to use DAOs with Hibernate.

But then we started looking for experienced Hibernate users. And it turns out there's market demand for generating straight Hibernate code - ORM style, without DAOs. The market for FireStorm/DAO without the DAO seems to be divided into a few groups:

-Hibernate users that already have a database - and find it much easier to simply reverse engineer the database than produce objects then map them to the schema

-Hibernate users that are novice developers and find Hibernate difficult to use (actually, all developers have a certain learning curve with Hibernate - FireStorm/DAO just reduces it from a couple of days to a couple of hours)

-Hibernate users in CodeFutures core market - large corporates and IT consultancies. Time is money for these guys and FireStorm/DAO saves a lot of time. A few years ago, the group would not have considered many open source products like Hibernate. But MySQL, JBoss, Red Hat, and of course, some Apache projects, have changed all that.

We've also made DAOs optional with our JDO code generation.

What CodeFutures suggests to Hibernate users is that they look into the benefits of DAOs and at least try it once. After all, they don't actually have to write any of the DAO code!

PJ Murray
CodeFutures Software