Page 2 of 2   « previous page

db4objects has recently released a replication tool called dRS that lets you exchange data not just with other db4o instances but with relational database systems as well. This makes it easy to design systems where a large enterprise data store contains information that workers need to access from disconnected devices. This is a common problem - a salesperson on the road needs customer data; someone working in a warehouse needs to collect and propagate inventory information; medical devices need to gather and process vast amounts of data from a patient. In all these cases, mobile devices have limited resources and have to exchange information with larger systems. db4o excels at this.

Christof Wittig, CEO of db4objects, explains his company's decision to release its software this way: "We live in a post-materialist world. People don't have long lead times to do everything themselves. It's only through collaboration that we can empower each other to succeed." Asked why they support Open Source, "That's easy," he said. "We owe everything to the community. From the outset, the user and developer community have helped shape and refine the product design and direction. We wouldn't have had that if we weren't Open Source. Even more important, our product is already easy to use; Open Source means that db4o is easy try and that in turn wins us customers."

db4objects, Inc. releases db4o under a dual-license model. Manufacturers can choose a commercial license if doing proprietary embedded work for a surprisingly modest price per unit. And if you want to evaluate its use, are doing in-house work, or want to use db4o in your own Open Source projects then you can use db4o freely under the GPL.

Obviously we've been talking Java here, but developers who have to do cross-platform development in heterogeneous environments will be interested to know that there's a .NET version of db4o available as well. The two are entirely binary-compatible; a number of its customers are running db4o as the storage back-end on Java application servers while writing their clients in little .NET programs. Yet-another example of Open Source bringing communities together.

Open Source to Change the World
For most people, Open Source means cost free. But a growing number of people have come to believe in the freedom that the Free Software movement preaches. Freedom to innovate. Freedom to modify and to help others with your work. It's the way the information age began.

Over the last few years an increasing amount of effort has been invested in what I'll call Free Java. As ever, the word free is a tad inadequate; the Open Source movement encourages you to realize that their essential message is freedom as in liberty (to modify a program, to enhance or reuse it as you see fit to redistribute) in addition to the notably useful property of being free as in price (though many of us gladly pay our distributor or vendor to package it all up and provide us support).

Sun's Java VM is, of course, not free or Open Source and until recently its license forbid redistributing Java binaries. So, not unexpectedly, the free software community has been creating an implementation of Java that does give you those freedoms.

The GNU Classpath project is working towards providing a fully compatible set of class libraries and supports a dizzying array of Java Virtual Machines - from research VMs like Kaffe and SableVM to the quaint little JamVM to the rocketing CACAO and JikesRVM and the truly radical GCJ project.

GCJ deserves special mention. Five or six years ago, hackers at Cygnus (now part of Red Hat) realized that one way they could look at Java would be to consider it a specifically defined subset of C++ (in the same sense that XML is a specifically defined subset of SGML). They reasoned that if they wrote a first-stage compiler that would take Java in the front-end and spit out the tree representation used by the gcc compiler internally, they could take advantage of the tremendous power of the whole GCC suite behind it to optimize that code and link it to binary executables that would run on any of the many platforms that GCC already supports.

And, ta-da, one of the consequences of the Free Java effort is that you can run Java programs on virtually every architecture out there. You are no longer limited to the few platforms that the major vendors create their runtimes for - a significant factor for embedded developers. Concurrent efforts to create a tight but highly performing garbage collector have meant that you can now create efficient and optimized programs with small footprints that - gasp! - are written in Java.

Ahead-of-time compilation (AOT) is somewhat unusual for us to think about - we're quite used to the just-in-time compilation (JIT) that has been part of commercial VMs since Java 1.1 days. JITs have a particular challenge though - they have to turn the intermediate representation (Java bytecode from a .class file) into native machine code fast enough that the user doesn't notice. That's a tall order, yet it's amazing how well modern VMs do it. There is, nevertheless, a limit to how much optimization a JIT compiler can achieve because of the limited time it has available. There's also a question of how much computing power is taken to do JIT compilation - horsepower that may not be available, especially on resource-limited machines like small embedded devices. By doing the compilation of native machine code ahead of time, GCJ isn't constrained by having to provide near-instantaneous compilation and has the luxury of being able to try more in-depth optimizations. The result is fast code and even better, there's no start-up penalty when a Java program is launched. Instead of the overhead of instantiating a massive VM and struggling through the JIT compilation of an enormous number of core classes, the code is already native and can immediately start executing - brilliant for small processes and desktop applications.

Red Hat, in particular, has invested significant effort into improving GCJ and the Classpath libraries to achieve this outcome on both small systems and enterprise servers. This has had impressive results: major projects like Eclipse and JOnAS can be built native resulting in a considerable performance boost. And if you're running the Fedora Core Linux distribution then any time you install a Java library it will be compiled native and transparently used to speed up your programs.

And there's even more to report from Free Java land. Recently a new project being incubated by the Apache Foundation has emerged on the scene. The effort, called Harmony, also aims to develop a fully compatible Open Source class library and VM implementation. It doesn't have much of a community behind it yet but it's been getting impressive donations of code from several major players in the Java space.

So across-the-board activity is up. Amazingly, some lament the bevy of choices maturing in the Java world, complaining that they have to invest effort into figuring out which solution is best for them. Ignoring for the moment that it has always taken hard work to figure out what course is best to take on an IT project, Java developers should be glad of all the competition. As all these projects jostle together, collaborating where they have common interests and competing where they think they can do better than the others, better platforms emerge, and that benefits all of us who write Java programs.

Conclusion
All is not quiet on the Open Source front. From simple collaboration to unexpected innovation on platforms tiny or huge, Java stakes out a vibrant place in the Open Source pantheon.

Of course, we can't end a discussion about Open Source and Java without briefly touching on the strong signals coming out of Sun Microsystems that it will in the not-too-distant future open its Java implementation. It remains to be seen whether Sun will choose a license that will actually qualify under the Open Source Definition, but early indications are that it's listened to people from the FOSS community and know it has to go all the way.

And then watch in amazement at the hordes who'll be using Open Source. Keep watch at the gates!

Page 2 of 2   « previous page