I think a significant part of the problem is that people don't realize that they have a choice. To the vast majority of computer users, Windows *is* the computer. Ask a typical office worker what operating system they use and you'll get responses ranging from blank stares, to "Office", to "Microsoft". They can't imagine replacing the operating system because they don't even know what an operating system is.
And to an extent, they have a point. A computer is a combination of hardware and software; with a few exceptions, hardware without software is a large doorstop and software without hardware is a stream of bits on some form of media.
There are already a huge number of everyday devices that have embedded hardware and software - cellphones, VCRs, DVDs, and cars, for example. They all need some kind of operating system. But by and large people don't think of these as computers, and even if they didn't, wouldn't care what operating system they ran, much less understand why they should care.
Much as I'd like to think education will help, I think it will take something dramatic to make people start to take notice this. When people start dying because of malfunctions in embedded software, they'll wake up and start asking questions.
I spent the last year working on a project that used Torque as its persistence layer. It's OK when you've got a basic one object = one table model. (You can also map an object to a view.) It's fairly easy and fairly flexible, within a paradigm that assumes one table per class.
The mechanics of using Torque are that you define your objects using an XML schema from which it generates both code and SQL CREATE TABLE statements using ant tasks. It uses another Jakarta project (the Velocity template engine) for code generation.
Torque generates five classes. Three are basically internal and shouldn't be messed with. Of these, one is a helper class, one is a base class for the object, and one is a base for the table. (If you will, one class represents rows of the table and one represents the table itself.) The classes you actually use are subclasses of this, and are basically empty stubs to which you can add code. Torque is smart about not overwriting these if they already exist.
You can alter the base classes by changing the Velocity templates or by providing a class that the generated code extends. (This class must extend Torque's BaseObject class.) ISTR that it also supports tables that extend other tables, but we never needed to explore that.
Oh, it also provides its own connection pooling. This could be a problem if you're wanting to make use of application-server supplied transaction management (e.g. for managing distributed transactions.) We did prototype an interface to make it use XA transactions acquired from JBOSS, which worked in unit testing, but was never used in production because we didn't need the functionality.
My only serious caveats with Torque are that (a) it doesn't support SQL aggregate functions (min, max, sum, etc.), (b) it feels like it's designed for a fairly simplistic model where one web page equals one screen, and (c) the documention is a bit skimpy in places. Good for getting started but less helpful on the meaty problems. Not supporting aggregates is a nuisance; we had to drop down to JDBC for those (which Torque allows; just make sure you return the connection to the pool instead of closing it!) The one page = one screen paradigm was less of an issue, more just a sense of what it was originally designed for.
It also relies on a number of other Jakarta projects, which may be a problem in initially configuring it. We were using Turbine and some others, so I'm not sure just what would be involved in using it outside that context.
The other major caveat is that it has no caching, so if you fetch the same object twice you'll end up with two copies which is potentially a problem in a multi-threaded environment. However, this something you might expect to pay big bucks for. As a free product that provides a good and easily-maintained alternative to hand-rolling your JDBC interfaces, Torque is a pretty good solution.
Slashdot Mirror
I think a significant part of the problem is that people don't realize that they have a choice. To the vast majority of computer users, Windows *is* the computer. Ask a typical office worker what operating system they use and you'll get responses ranging from blank stares, to "Office", to "Microsoft". They can't imagine replacing the operating system because they don't even know what an operating system is.
And to an extent, they have a point. A computer is a combination of hardware and software; with a few exceptions, hardware without software is a large doorstop and software without hardware is a stream of bits on some form of media.
There are already a huge number of everyday devices that have embedded hardware and software - cellphones, VCRs, DVDs, and cars, for example. They all need some kind of operating system. But by and large people don't think of these as computers, and even if they didn't, wouldn't care what operating system they ran, much less understand why they should care.
Much as I'd like to think education will help, I think it will take something dramatic to make people start to take notice this. When people start dying because of malfunctions in embedded software, they'll wake up and start asking questions.
I spent the last year working on a project that used Torque as its persistence layer. It's OK when you've got a basic one object = one table model. (You can also map an object to a view.) It's fairly easy and fairly flexible, within a paradigm that assumes one table per class.
The mechanics of using Torque are that you define your objects using an XML schema from which it generates both code and SQL CREATE TABLE statements using ant tasks. It uses another Jakarta project (the Velocity template engine) for code generation.
Torque generates five classes. Three are basically internal and shouldn't be messed with. Of these, one is a helper class, one is a base class for the object, and one is a base for the table. (If you will, one class represents rows of the table and one represents the table itself.) The classes you actually use are subclasses of this, and are basically empty stubs to which you can add code. Torque is smart about not overwriting these if they already exist.
You can alter the base classes by changing the Velocity templates or by providing a class that the generated code extends. (This class must extend Torque's BaseObject class.) ISTR that it also supports tables that extend other tables, but we never needed to explore that.
Oh, it also provides its own connection pooling. This could be a problem if you're wanting to make use of application-server supplied transaction management (e.g. for managing distributed transactions.) We did prototype an interface to make it use XA transactions acquired from JBOSS, which worked in unit testing, but was never used in production because we didn't need the functionality.
My only serious caveats with Torque are that (a) it doesn't support SQL aggregate functions (min, max, sum, etc.), (b) it feels like it's designed for a fairly simplistic model where one web page equals one screen, and (c) the documention is a bit skimpy in places. Good for getting started but less helpful on the meaty problems. Not supporting aggregates is a nuisance; we had to drop down to JDBC for those (which Torque allows; just make sure you return the connection to the pool instead of closing it!) The one page = one screen paradigm was less of an issue, more just a sense of what it was originally designed for.
It also relies on a number of other Jakarta projects, which may be a problem in initially configuring it. We were using Turbine and some others, so I'm not sure just what would be involved in using it outside that context.
The other major caveat is that it has no caching, so if you fetch the same object twice you'll end up with two copies which is potentially a problem in a multi-threaded environment. However, this something you might expect to pay big bucks for. As a free product that provides a good and easily-maintained alternative to hand-rolling your JDBC interfaces, Torque is a pretty good solution.
See http://db.apache.org/torque
....Windows systems are not essential...