db4o runs on Android out-of-the-boy. I tried just now on the emulator. Our JDK 1.1 version works as is out-of-the-box.
The very first impression from my first Android app: GUI design on Android is *very* XML-ish. This will only start be fun with a nice visual editor integrated into the IDE. I am positive that it's already in the making.
This is the the single best possibe thing that could have happened for the success of Java on devices. This SDK will be decisive for how software will be written for the masses in the future: With Java. Don't forget: The number of mobile phone users without a PC will soon be an order of magnitude higher than the number of PC users.
Whenever I see a comment that pair programming does not work I feel sad for the person that wrote it. Maybe you were very unlucky with the peer you were working with, maybe you were unlucky with the task that you were working on.
Without pairing my work would only be half as much fun and I would really miss the opportunity to learn from other people.
- Pairing keeps you completely focussed on a single important task. This benefit alone at least doubles the productivity of every developer and makes pairing cheaper. - Pairing produces better designs that last longer. - Pairing prevents simple mistakes and saves you from loosing time in the debugger. - Pairing fosters shared knowledge about the project that is being worked on. It makes it easier to exchange people between tasks. - Pairing helps learning. People teach eachother programming techniques, patterns and ways of working with IDEs. - Pairing helps raising the spirit of the team. It has worked extremely well to glue our team together, although we only see eachother in real life twice a year. - Pairing activates the speech area of your brain and makes you more creative. - Pairing is fun.
While it may be true that the SQL database market has become a commodity market, SQL databases have never solved object persistence nicely: SQL always remained a foreign language in Java and C#. The object-relational mismatch has forced us to write billions of lines of code over and over again.
Alternate technologies are currently seeing a revival:
- Microsoft has released LINQ to relieve developers from having to write SQL strings. Code that interfaces with the database is now checked at compile time: http://msdn.microsoft.com/netframework/future/linq /
The title is somewhat strange: We are a company and we write open source software. Who says that corporate software can not be open source at the same time?
One of the reasons why we are extremely efficient: We let our developers work from home. We use Skype and VNC for pair programming.
Remote pair programming is the "next big thing"
on
Microsoft Lauds Scrum
·
· Score: 3, Insightful
Agile methods have been around for a long time, they are not new, it's only new that big companies like MS find out that they work indeed.
In the meanwhile globalisation has advanced, there is a more efficient way to build software than to pile people up in cubicles. It's pretty much like an open source project: - Get the best experts from all over the world for the theme where they are good at. - Let them work from home. - Let the team work in remote pairs, using VNC and Skype and change pairs frequently.
In this setup half-hour meetings every day do not work, because of the different timezones. A weekly meeting is good enough, Asterisk works fine for VoIP conferences, CVS email notifications about all checked-in work keeps everyone up-to-date.
This is how our company works. We are very happy with the cost and the quality of the work we get and with the lifestyle to work at home when you want and how you want.
No, reflection won't work to load all classes in the CLASSPATH. For reflection you would need a starting point from where all other classes are referenced. There is no common root. Any line of code can decide to create an instance of a class that has not been used or referenced yet.
How long would it take someone to write this themselves if they needed it? 10 minutes?
Maybe a day ?
(1) Identify all files and directories that can be found in the CLASSPATH. (2) Look at the directories and add all contained files to the list of files. (3) Differentiate beween types of files: (4) Add.class files to the list of class names (5) Look through all zip format files (.jar,.zip,.war... ) and find all class names in there. (6) Call ClassLoader#loadClass with all classnames.
(5) will take longest to write yourself, but there should certainly already be code out there tht gets that done
(6) Which ClassLoader to use? Surely the ClassLoader needs to be supplyable as a parameter.
"A few seconds" and 3MB of memory for rt.jar sound nice but I wonder how timings and memory consumption would look like with a couple of more libraries in the CLASSPATH, how about a full Eclipse environment?
The problem with Java startup times is that every Java app loads it's own complete runtime environment. This is not easy to fix, since many apps depend on the fact that they get their own.
In case you are using an object-oriented programming language, you may ask yourself if SQL really is a good choice. SQL is not object-oriented, it's use is usually neither typesafe nor compile-time checked in OO languages, it can't be refactored from an object-oriented IDE and it does not follow OO principles.
The best recommendation that you can have for a developer job is if you can show with your own code that you have done something very similar before in past projects. ...at least that's how we hire...
In the first outsourcing wave companies are sending complete projects to India or China, that's happening right now.
In the second outsourcing wave companies will hire the best experts worldwide to cooperate on the same project, working dislocated, communicating by voice over Skype, pair programming over VNC. We are working in this mode already. There is no better setup, both with regards to quality and to cost.
To get into a team that works in this way, it is essential to have a good track record. OSS is great because you can: - show the quality of your code, - prove that you can manage yourself, - show that you have initiative and joy for your work.
in case you are working with an OO language (Java or C# ?), you may consider looking into exisiting frameworks that provide object-oriented replication.
That would relieve you from building features like the following yourself: - Unique Universal Identifiers (UUIDs) - Cascaded replication with object member traversal - Conflict resolution at object level providing callbacks
The following open source object database engine provides such functionality and you may even consider it as an alternative to relational databases for caching your data on the clients: http://www.db4o.com/
How can a single-platform platform be more open than Java?
Java is proprietary. In theory:
If an Arabian oil company would buy Sun tomorrow and decide to charge USD 100 per Java runtime, they could. I posted something similar to the above as an April-fools-day-joke to the de.comp.lang.java newsgroup on April 1. 2001 and was surprised at the traffic it produced.
C#'s standardization is simply a marketing trick by Microsoft
Mono is reality and it's doing quite well.
Kudos to Miguel, Erik and all contributors.
It is really meaningless in the big picture, especailly compared to Sun's JCP, which has hundreds of members
JCPs are design-by-committee which is not always efficient. Sometimes it can be like having too many cooks in a kitchen. Just look at the latest EJB vs. JDO clash. It is a lot easier for MS to move faster by simply "setting" "standards" with no discussions. Pace is an important factor for innovation.
Voltaire said: "I would rather be ruled by a lion than by a thousand rats."
Did I already say that I prefer Java (the platform) to C# (the slightly better language) ? You should just never ignore the other side, there may be a lot to learn.
Yes, I trust the Mono guys to catch up very nicely.
How many "dialects" are there of Java?
JDK 1.1 is still heavily in use as "PersonalJava", on quite a few limited platforms which are nonetheless important, like Symbian.
Some of the more important J2ME dialects:
CLDC
CDC
MIDP
PersonalProfile
Not all companies can or may upgrade to the latest Java VM. Some developers have to restrict themselves to one of the following. Bytecode produced with newer compilers is not backward compatible.
JDK 1.1.8
JDK 1.2.x
JDK 1.3.x
JDK 1.4.x
Finally there is the glorious current JDK 5.
I call that dialects. It's quite a mess if you want to develop GUI that has to run on a handheld and on a desktop.
Talking of GUI dialects. There is:
AWT
SWT
Swing
...just to name the major "corporate" ones. There are tons more by small to mid-size shops.
C# only has two major dialects:
normal C#
C# for the CompactFramework (handhelds)
The strength of Microsoft will prevent the entry of third parties. Many people will not like that at all, but there is one advantage, if you want to build professional software:
You can take a decision to start today, there is a clear one-and-only choice, with little risk of discontinuation.
You can't have it both ways; it's either standardised, or it includes GUI stuff.
Maybe my posting looks biased when you compare the number of pluspoints. They are random, I just listed what came to mind.
My personal opinion is very strong towards Java. Cross-platform outweighs everything else by far.
I wouldn't exchange Eclipse against VS.NET 2003 for one day, it feels like your left hand is cut off.
VS.NET 2005 will catch up on refactorings but the Eclipse platform is gaining a competitive advantage which can't be beaten by MS: It is becoming a crystallisation point for all kinds of open source plugin tools like database browsers (our own brandnew Eclipse plugin will go online on Monday), JSP editors, language converters, you name it, it's there.
One very important pluspoint for Java which I forgot to mention: You get all the sources. You can debug into them and see how Sun's professionals (try to) solve things. Yeah, sometimes (Swing) you can also see that Java does let you write awkward code also.
Pluspoints for Java -------------------- + more OS Platforms that you can run on + Eclipse as a terrific free IDE + huge number of free open source libraries + further away from MS (O.K. there is Mono too, but you only have one single second vendor that you can rely on)
Pluspoints for C# ------------------- + one single choice for UI development + more language features (this may be a minuspoint for corporate development, when you only want one way to write things) + one language standard, less dialects + believe it or not, it's an open standard and (on paper) less proprietary than Java, which is owned by Sun + easy GUI development for WinCE or windows mobile, including many mobile phones + possible easy interaction with other.NET languages + easy direct interaction with Windows OS features
Many people in this thread have come up with alternatives to VB.NET. Here is a very strong argument for VB.NET and for the.NET platform in general, whether you want to run on Mono or on MS:
Since Java and C# are very similar, just about all the important open source Java libraries are being ported to C#. Once on C#, they are available for all CLR languages - also for VB.NET.
An object database will do all that you want for you:
database.store(object);
Behind the scenes it should: - analyse your class structure, even if it changes - ensure everything you do is transactional - provide fast querying functionality for you with indexes - help you improve your memory management by allowing to unload unused objects from RAM
Prevayler may work O.K. for a small web application but you will need some grown-up features every now and then: - fast querying functionality that runs on indices - SQL query support, to be able to use existing tools - automatic schema evolution in case you add new fields to classes - memory management - multi-user locking - load balancing - replication Some available object databases already supply a lot of this functionality and I do think they are a better choice for professional products than Prevayler.
The first "object database" available - ObjectStore - did work a lot like Prevayler. It's immature technology was responsible for the bad reputation of object databases.
It seems that each of us have different ideas about what's right and what's wrong.
Reading your posting, this is probably very true.
Excuse me for starting my last posting off in such a negative manner. I have just had a flame war "S.O.D.A. database Query API - call for comments" in quite a few newsgroups. Reading through all the postings to this thread in Slashdot must have blown a fuse. I do consider many statements here to be wrong, but my understanding of an object database is probably entirely different to what some people here are talking about.
Reality... can be represented by relations also No doubt.
Even if objects are convenient for some programming domains, it isn't for data storage and retrieve, except if your program will never change *and* it is object-oriented. Object databases of course don't make any sense if the programming language is not object-oriented. From my experience and from a practical point of view, *changes* can be handled much easier than in a relational database because there is only one single place of change: The class scheme of the application. The respective programming tool will automatically help the application developer find all references. I was referring to this sort of change with my point on reengineering. Errors in SQL strings will not be automatically detected if the table scheme was changed.
The issue is that these relationships are maintained physically in the database You are talking about possible implementation details here. They are handled entirely different by different database vendors. A foreign key in a relational database is nothing else than a pointer from one table to the next. This is principally exactly the same linkage as an object to its member in an object database. I have 5 years of hardcore professional experience writing a cross-vendor framework for relational databases. I think, I know what a relation is.
The fundamental issue of OO is that is an over-extension of some simple programming rules-of-thumb. I would consider a discussion about the advantages of object-orientation as totally off-topic in an ODBMS thread. I fully agree that it has not been proven yet, that object-orientation is the ideal programming paradigm. Personally I am extremely happy and successful with it. The need for ODBMS only arises out of the use of object-oriented languages. With the arrival of C# and VB-dot-Fred, more than 50% of the world-wide programming will take place in clean object-oriented languages. Success seems to be there, in spite of theorists that deny a theoretical foundation. Yes, OO gets complicated if you discuss multiple inheritance and all kinds of possibilities for method invocation. If we only look at the very small subset of OO that is sufficient to model relations, OO is extremely simple:
classname.membername
describes that "membername" is linked to classname. This is it. No keys to represent relations are necessary.
I want my data in my database, in a well defined and theoretically sound *data* sublanguage, not only in a programming language. What for? For the fun of it? Can you grasp the data with your hands? All that you get from your data or from your theoretically "clean" system is what SQL delivers you. We will also provide a declarative query interface with the same efficiency. Yes, you will be able to evaluate objects against eachother that are not even linked together. Yes, there will be declarative update statements.
keeping data logically organized, easily accessible and readily available to access plans created by a good query optimizer. All of this can also be done with an object database. Internally the principle is practically the same. The advantage of current object databases for object-oriented languages: They understand inheritance.
>> Object databases also use optimizers to
>> analyze queries. But your access paths are predefined.
Why?
And if you ever need a schema change, you will have to rewrite lots of queries.
Is this specific to one system or the other? Again, a typesafe system using objects will enforce the rewrite. A typeless string system will need to be scanned manually for possible errors.
>> Our product simply stores a superset of all
>>used schemas. This won't fly. This is schema accumulation, not change. This flies today. Of course a combination with declarative updates can also be necessary. A compact run gets unused space back. Where is the negative aspect in comparison to relational databases?
read also The Third Manifesto, then Database Debunkings, and then we can talk Lee Fesperman, the maintainer of those "debunkings", is the person I exchanged about 20 mails with in the running newsgroup discussions. It is interesting to see that he also used the offensive and arrogant "Learn first and then we can talk" jargon.
each user has its own schema "User" schemas are application schemas. They are nothing else than some added namespace for table names. We can also use one database file for every user if you find this appropriate.
..you haven't yet understood the fundamentals of the field. Insults never are a basis for an objective discussion.
Calling someone else a "beginner" that has just devoted 15 months of his life to write a database system is a very professional insult. Good bye.
Carl Rosenberger
db4o - database for objects
http://www.db4o.com
>> Reality is object-oriented.
> Really? When the Sun rises, does it send
> messages to the birds to tell them to sing? :-)
A lot of OO-confusion in the past has been caused by "object gurus". Wanting too much in one innovation step, they have always pronounced the great advantages of associating data with methods.
The first benefit from using objects and object hierarchies is that you can remodel real-world objects and relationships between them very nicely by simply using the terminology mankind has developed in human language.
Reality does consist of objects.
Birds sleep in trees, not in tables.
Bringing your very nice example to a dry programming language:
The birds do not sing, because the sun *rises*.
Birds poll their environment. Illumination and temperature are functions of the position of the sun.
I'm an OODBMS advocate in some ways, I think they're great when in the hands of experts.
There are many different object databases. The most friendly comments we get come from database newbies.
In my opinion ObjectStore has done a terrible job for object databases in the past 8 years, by overcomplicating things. The simplest features need to work first. Being able to store objects would have been a first step. What did they do? They tried to skip two innovation steps by attempting transparent persistency. What did they achieve? Pointer chaos and the need for highly skilled experts to understand what was going on. We are working on a system from the ground up. Before we will even think about transparent persistency, we want to provide functionality to store and query objects in the most natural way possible.
until a fully expressive ad hoc query capability is on these object systems
We are working on a common basic API to query object databases.
http://odbms.org/soda/soda.zip
This API simply is intended to provide a programmatic interface to the functionality a query parser usually has.
An ad hoc query language (possibly an SQL- or OQL-derivate) would sit on top of this API.
Again:
We try to build the house from the ground up.
I have posted a "call for comments" to various Java and database newsgroups. What happened? I was flamed down for object databases in general and for the approach to do something new in particular. I found most arguments very ignorant and simply wrong. Maybe we get some more interesting comments from/.. I think I will start a thread here soon.
does your ODBMS have associative B-Tree indices built in?
Yes.
that work when your query is traversing over collections? etc.
No.
In fact we have not released full Java Collection support to the public yet. It will be included with the release of version 1.1 by the end of this month.
Queries for array members will already be capable of using the internal indices.
We still have some work before us for member indices. The benchmarks available with the download show this very nicely.
Carl Rosenberger
db4o - database for objects
http://www.db4o.com
[but ONLY using queries and transactions that are defined up front in your modeling/design process]
We are currently designing a query API to outperform SQL - with dynamic queries.
http://www.odbms.org/soda/soda.zip
[In the real world, data can be modeled hierarchically, but often shouldn't be.]
This is no argument against object databases. You are free to choose the hierarchy that you prefer.
[Circumventing the Need for a Query Language]
Many object databases do support query languages. We currently support query-by-example, the most natural approach. "Give me all objects like this one."
[just has one 32-bit integer member. In an OODBMS, the space required for an OID is many times larger than an instance of the class itself!!]
This is dependant on the implementation of the object database. In our system a 32-bit integer needs 4 bytes, what else? Strings have a variable length. They only need this length, a 4 byte OID and a 4 byte integer. The overall advantage is strongly dependant on the datamodel but typically our database file consumes less than half of what a relational database needs.
[every lookup of an OID potentially requires a search through every object in the system, not just the primary key of one table]
Now what if the OID exactly specifies the place in the file? Then it works like a hashtable - you get immediate access. All object databases use some kind of efficient tree mechanism to cache object data, typically one tree for every class.
[Defining primary keys is one of the easier tasks in relational modeling, IMHO.]
Yes.
Defining foreign keys is like modelling objects, just more abstract and less intuitive.
Carl Rosenberger
db4o - database for objects
http://www.db4o.com
It is interesting to see that a posting with so many wrong statements receives such a high rating here.
[database best practices and theory]
Reality is object-oriented. We use objects in our modern programming languages. Why should we flatten these out to tables with unnecessary keys, if we store objects? Relations between objects can be maintained transparently within the database. Let's forget about methods for the moment: objects are nothing else than recursive links of primitive types.
This is common-sense and there is no need to write scientific papers about it.
[you should design data before your application]
Yes!
You can design data by writing classes in your respective programming language.
[independence of the logical and physical layers of your database]
Where do you need tables here?
Class members define properties.
Methods define behaviour.
[shifting the performance optimization issues to the DBMS' optimizer]
Object databases also use optimizers to analyze queries.
[any schema change do not only need an application recompilation]
There are object databases that manage schema versioning automatically. Our product simply stores a superset of all used schemas. Schema changes can occur in realtime. You can even switch back and forth between different class versions.
...without recompilation of the engine.
[you won't be able to keep several logical schemas to different users]
Wrong. Our object database is not multi-user as of today but the current mechanism will allow different schemas for different concurrent users in the future. By the way: Do you typically have different tables for different users?
[rethink the data access path]
Reengineering is a terrible problem with relational databases. Strings are not typesafe, so you have to parse the entire application for strings with no help from the compiler. We are working on a typesafe query specification.
http://www.odbms.org/soda/soda.zip
[leaving it up to the DBMS to create the best access plans]
Our query optimizer generates an access plan for objects. Simply for query-by-example.
[so OODBMSs sounds nice but offer no real improvements over RDBMSs]
5 out of 100:
- Performance. Our object database beats any relational database insert performance by factor 10 to 100
- Ease of use. Store a complex object network with one single statement:
db.set(object);
- Retrieval of objects. The database manages to put all these stored objects back together again. It controls that only *1* instance of each object is created and everything is linked the way it was stored.
- More compact storage
- No more fixed length strings.
[which should give us practically all of the advantages of OODBMSs without their cons]
We are going the other way. We want to provide all the relational functionality that you wish with our object database. We might finally end up with very similar engines.
Carl Rosenberger
db4o - database for objects
http://www.db4o.com
Slashdot Mirror
db4o runs on Android out-of-the-boy.
I tried just now on the emulator. Our JDK 1.1 version works as is out-of-the-box.
The very first impression from my first Android app:
GUI design on Android is *very* XML-ish. This will only start be fun with a nice visual editor integrated into the IDE. I am positive that it's already in the making.
Android is fully based on Java.
Being a developer of an open source java database myself, I am absolutely thrilled.
This is the the single best possibe thing that could have happened for the success of Java on devices. This SDK will be decisive for how software will be written for the masses in the future: With Java. Don't forget: The number of mobile phone users without a PC will soon be an order of magnitude higher than the number of PC users.
Whenever I see a comment that pair programming does not work I feel sad for the person that wrote it. Maybe you were very unlucky with the peer you were working with, maybe you were unlucky with the task that you were working on.
Without pairing my work would only be half as much fun and I would really miss the opportunity to learn from other people.
Some thoughts taken from a recent blog post that I wrote:
- Pairing keeps you completely focussed on a single important task. This benefit alone at least doubles the productivity of every developer and makes pairing cheaper.
- Pairing produces better designs that last longer.
- Pairing prevents simple mistakes and saves you from loosing time in the debugger.
- Pairing fosters shared knowledge about the project that is being worked on. It makes it easier to exchange people between tasks.
- Pairing helps learning. People teach eachother programming techniques, patterns and ways of working with IDEs.
- Pairing helps raising the spirit of the team. It has worked extremely well to glue our team together, although we only see eachother in real life twice a year.
- Pairing activates the speech area of your brain and makes you more creative.
- Pairing is fun.
While it may be true that the SQL database market has become a commodity market, SQL databases have never solved object persistence nicely: SQL always remained a foreign language in Java and C#. The object-relational mismatch has forced us to write billions of lines of code over and over again.
q /
e .html
Alternate technologies are currently seeing a revival:
- A new portal on object databases was recently launched:
http://www.odbms.org/
- Object databases are going open source:
http://www.db4o.com/
- Microsoft has released LINQ to relieve developers from having to write SQL strings. Code that interfaces with the database is now checked at compile time:
http://msdn.microsoft.com/netframework/future/lin
- Native Queries show that Java and C# can be directly used to express typesafe queries:
http://www.ddj.com/documents/s=9948/ddj0602e/0602
The title is somewhat strange: We are a company and we write open source software. Who says that corporate software can not be open source at the same time?
One of the reasons why we are extremely efficient:
We let our developers work from home. We use Skype and VNC for pair programming.
Agile methods have been around for a long time, they are not new, it's only new that big companies like MS find out that they work indeed.
In the meanwhile globalisation has advanced, there is a more efficient way to build software than to pile people up in cubicles. It's pretty much like an open source project:
- Get the best experts from all over the world for the theme where they are good at.
- Let them work from home.
- Let the team work in remote pairs, using VNC and Skype and change pairs frequently.
In this setup half-hour meetings every day do not work, because of the different timezones. A weekly meeting is good enough, Asterisk works fine for VoIP conferences, CVS email notifications about all checked-in work keeps everyone up-to-date.
This is how our company works. We are very happy with the cost and the quality of the work we get and with the lifestyle to work at home when you want and how you want.
No, reflection won't work to load all classes in the CLASSPATH. For reflection you would need a starting point from where all other classes are referenced. There is no common root. Any line of code can decide to create an instance of a class that has not been used or referenced yet.
How long would it take someone to write this themselves if they needed it? 10 minutes?
.class files to the list of class names .zip, .war ... ) and find all class names in there.
Maybe a day ?
(1) Identify all files and directories that can be found in the CLASSPATH.
(2) Look at the directories and add all contained files to the list of files.
(3) Differentiate beween types of files:
(4) Add
(5) Look through all zip format files (.jar,
(6) Call ClassLoader#loadClass with all classnames.
(5) will take longest to write yourself, but there should certainly already be code out there tht gets that done
(6) Which ClassLoader to use? Surely the ClassLoader needs to be supplyable as a parameter.
"A few seconds" and 3MB of memory for rt.jar sound nice but I wonder how timings and memory consumption would look like with a couple of more libraries in the CLASSPATH, how about a full Eclipse environment?
The problem with Java startup times is that every Java app loads it's own complete runtime environment. This is not easy to fix, since many apps depend on the fact that they get their own.
In case you are using an object-oriented programming language, you may ask yourself if SQL really is a good choice. SQL is not object-oriented, it's use is usually neither typesafe nor compile-time checked in OO languages, it can't be refactored from an object-oriented IDE and it does not follow OO principles.
e papers/
q /
Food for thought:
Native Queries
http://www.db4o.com/about/productinformation/whit
DLINQ
http://msdn.microsoft.com/netframework/future/lin
Some indicators that SQL does not have a bright future as a database interface for object-oriented programming languages:
q /
LINQ/DLINQ
http://msdn.microsoft.com/netframework/future/lin
Native Queries
http://www.odbms.org/
http://www.db4o.com/
What does Oracle have to offer in this direction?
Seeing the Gorilla drive the money out of the SQL stack is a strong sign that innovation is over.
The best recommendation that you can have for a developer job is if you can show with your own code that you have done something very similar before in past projects.
...at least that's how we hire...
In the first outsourcing wave companies are sending complete projects to India or China, that's happening right now.
In the second outsourcing wave companies will hire the best experts worldwide to cooperate on the same project, working dislocated, communicating by voice over Skype, pair programming over VNC. We are working in this mode already. There is no better setup, both with regards to quality and to cost.
To get into a team that works in this way, it is essential to have a good track record. OSS is great because you can:
- show the quality of your code,
- prove that you can manage yourself,
- show that you have initiative and joy for your work.
Hi,
in case you are working with an OO language (Java or C# ?), you may consider looking into exisiting frameworks that provide object-oriented replication.
That would relieve you from building features like the following yourself:
- Unique Universal Identifiers (UUIDs)
- Cascaded replication with object member traversal
- Conflict resolution at object level providing callbacks
The following open source object database engine provides such functionality and you may even consider it as an alternative to relational databases for caching your data on the clients:
http://www.db4o.com/
- Java has "foreach" in JDK5 and it works very nicely for arrays and lists:- Although there are many layoutmanagers for Java, you usually end up writing your own from scratch if you really care for a nice user interface.
- For beginners that want to write user interface I see an advantage to use VS.NET.
How can a single-platform platform be more open than Java?
Java is proprietary. In theory:
If an Arabian oil company would buy Sun tomorrow and decide to charge USD 100 per Java runtime, they could. I posted something similar to the above as an April-fools-day-joke to the de.comp.lang.java newsgroup on April 1. 2001 and was surprised at the traffic it produced.
C#'s standardization is simply a marketing trick by Microsoft
Mono is reality and it's doing quite well.
Kudos to Miguel, Erik and all contributors.
It is really meaningless in the big picture, especailly compared to Sun's JCP, which has hundreds of members
JCPs are design-by-committee which is not always efficient. Sometimes it can be like having too many cooks in a kitchen. Just look at the latest EJB vs. JDO clash. It is a lot easier for MS to move faster by simply "setting" "standards" with no discussions. Pace is an important factor for innovation.
Voltaire said: "I would rather be ruled by a lion than by a thousand rats."
Did I already say that I prefer Java (the platform) to C# (the slightly better language) ? You should just never ignore the other side, there may be a lot to learn.
Yes, I trust the Mono guys to catch up very nicely.
How many "dialects" are there of Java?
- JDK 1.1 is still heavily in use as "PersonalJava", on quite a few limited platforms which are nonetheless important, like Symbian.
- Some of the more important J2ME dialects:
- CLDC
- CDC
- MIDP
- PersonalProfile
- Not all companies can or may upgrade to the latest Java VM. Some developers have to restrict themselves to one of the following. Bytecode produced with newer compilers is not backward compatible.
- JDK 1.1.8
- JDK 1.2.x
- JDK 1.3.x
- JDK 1.4.x
- Finally there is the glorious current JDK 5.
I call that dialects. It's quite a mess if you want to develop GUI that has to run on a handheld and on a desktop.Talking of GUI dialects. There is:
C# only has two major dialects:
- normal C#
- C# for the CompactFramework (handhelds)
The strength of Microsoft will prevent the entry of third parties. Many people will not like that at all, but there is one advantage, if you want to build professional software:You can take a decision to start today, there is a clear one-and-only choice, with little risk of discontinuation.
You can't have it both ways; it's either standardised, or it includes GUI stuff.
I think Java and SWT is a good choice.
Maybe my posting looks biased when you compare the number of pluspoints.
They are random, I just listed what came to mind.
My personal opinion is very strong towards Java.
Cross-platform outweighs everything else by far.
I wouldn't exchange Eclipse against VS.NET 2003 for one day, it feels like your left hand is cut off.
VS.NET 2005 will catch up on refactorings but the Eclipse platform is gaining a competitive advantage which can't be beaten by MS: It is becoming a crystallisation point for all kinds of open source plugin tools like database browsers (our own brandnew Eclipse plugin will go online on Monday), JSP editors, language converters, you name it, it's there.
One very important pluspoint for Java which I forgot to mention:
You get all the sources.
You can debug into them and see how Sun's professionals (try to) solve things. Yeah, sometimes (Swing) you can also see that Java does let you write awkward code also.
Pluspoints for Java
.NET languages
--------------------
+ more OS Platforms that you can run on
+ Eclipse as a terrific free IDE
+ huge number of free open source libraries
+ further away from MS (O.K. there is Mono too, but you only have one single second vendor that you can rely on)
Pluspoints for C#
-------------------
+ one single choice for UI development
+ more language features (this may be a minuspoint for corporate development, when you only want one way to write things)
+ one language standard, less dialects
+ believe it or not, it's an open standard and (on paper) less proprietary than Java, which is owned by Sun
+ easy GUI development for WinCE or windows mobile, including many mobile phones
+ possible easy interaction with other
+ easy direct interaction with Windows OS features
Now what do you prefer?
Many people in this thread have come up with alternatives to VB.NET. Here is a very strong argument for VB.NET and for the .NET platform in general, whether you want to run on Mono or on MS:
Since Java and C# are very similar, just about all the important open source Java libraries are being ported to C#. Once on C#, they are available for all CLR languages - also for VB.NET.
Some examples:
http://www.db4o.com/
http://bbooprevalence.sourceforge.net/
http://nhibernate.sourceforge.net/
http://nant.sourceforge.net/
Strong libraries is what make up the power of a programming language.
- analyse your class structure, even if it changes
- ensure everything you do is transactional
- provide fast querying functionality for you with indexes
- help you improve your memory management by allowing to unload unused objects from RAM
Here are some object database links:
http://www.cetus-links.org/oo_db_systems_1.html
http://cbbrowne.com/info/oodbms.html
http://www.db4o.com/
Prevayler may work O.K. for a small web application but you will need some grown-up features every now and then:
- fast querying functionality that runs on indices
- SQL query support, to be able to use existing tools
- automatic schema evolution in case you add new fields to classes
- memory management
- multi-user locking
- load balancing
- replication
Some available object databases already supply a lot of this functionality and I do think they are a better choice for professional products than Prevayler.
The first "object database" available - ObjectStore - did work a lot like Prevayler. It's immature technology was responsible for the bad reputation of object databases.
It seems that each of us have different ideas about what's right and what's wrong.
... can be represented by relations also
..you haven't yet understood the fundamentals of the field.
Reading your posting, this is probably very true.
Excuse me for starting my last posting off in such a negative manner. I have just had a flame war "S.O.D.A. database Query API - call for comments" in quite a few newsgroups. Reading through all the postings to this thread in Slashdot must have blown a fuse. I do consider many statements here to be wrong, but my understanding of an object database is probably entirely different to what some people here are talking about.
Reality
No doubt.
Even if objects are convenient for some programming domains, it isn't for data storage and retrieve, except if your program will never change *and* it is object-oriented.
Object databases of course don't make any sense if the programming language is not object-oriented. From my experience and from a practical point of view, *changes* can be handled much easier than in a relational database because there is only one single place of change: The class scheme of the application. The respective programming tool will automatically help the application developer find all references. I was referring to this sort of change with my point on reengineering. Errors in SQL strings will not be automatically detected if the table scheme was changed.
The issue is that these relationships are maintained physically in the database
You are talking about possible implementation details here. They are handled entirely different by different database vendors. A foreign key in a relational database is nothing else than a pointer from one table to the next. This is principally exactly the same linkage as an object to its member in an object database. I have 5 years of hardcore professional experience writing a cross-vendor framework for relational databases. I think, I know what a relation is.
The fundamental issue of OO is that is an over-extension of some simple programming rules-of-thumb.
I would consider a discussion about the advantages of object-orientation as totally off-topic in an ODBMS thread. I fully agree that it has not been proven yet, that object-orientation is the ideal programming paradigm. Personally I am extremely happy and successful with it. The need for ODBMS only arises out of the use of object-oriented languages. With the arrival of C# and VB-dot-Fred, more than 50% of the world-wide programming will take place in clean object-oriented languages. Success seems to be there, in spite of theorists that deny a theoretical foundation.
Yes, OO gets complicated if you discuss multiple inheritance and all kinds of possibilities for method invocation.
If we only look at the very small subset of OO that is sufficient to model relations, OO is extremely simple:
classname.membername
describes that "membername" is linked to classname. This is it. No keys to represent relations are necessary.
I want my data in my database, in a well defined and theoretically sound *data* sublanguage, not only in a programming language.
What for? For the fun of it? Can you grasp the data with your hands?
All that you get from your data or from your theoretically "clean" system is what SQL delivers you. We will also provide a declarative query interface with the same efficiency. Yes, you will be able to evaluate objects against eachother that are not even linked together. Yes, there will be declarative update statements.
keeping data logically organized, easily accessible and readily available to access plans created by a good query optimizer.
All of this can also be done with an object database. Internally the principle is practically the same. The advantage of current object databases for object-oriented languages: They understand inheritance.
>> Object databases also use optimizers to
>> analyze queries.
But your access paths are predefined.
Why?
And if you ever need a schema change, you will have to rewrite lots of queries.
Is this specific to one system or the other? Again, a typesafe system using objects will enforce the rewrite. A typeless string system will need to be scanned manually for possible errors.
>> Our product simply stores a superset of all
>>used schemas.
This won't fly. This is schema accumulation, not change.
This flies today. Of course a combination with declarative updates can also be necessary. A compact run gets unused space back. Where is the negative aspect in comparison to relational databases?
read also The Third Manifesto, then Database Debunkings, and then we can talk
Lee Fesperman, the maintainer of those "debunkings", is the person I exchanged about 20 mails with in the running newsgroup discussions. It is interesting to see that he also used the offensive and arrogant "Learn first and then we can talk" jargon.
each user has its own schema
"User" schemas are application schemas. They are nothing else than some added namespace for table names. We can also use one database file for every user if you find this appropriate.
Insults never are a basis for an objective discussion.
Calling someone else a "beginner" that has just devoted 15 months of his life to write a database system is a very professional insult.
Good bye.
Carl Rosenberger
db4o - database for objects
http://www.db4o.com
>> Reality is object-oriented.
:-)
/.. I think I will start a thread here soon.
> Really? When the Sun rises, does it send
> messages to the birds to tell them to sing?
A lot of OO-confusion in the past has been caused by "object gurus". Wanting too much in one innovation step, they have always pronounced the great advantages of associating data with methods.
The first benefit from using objects and object hierarchies is that you can remodel real-world objects and relationships between them very nicely by simply using the terminology mankind has developed in human language.
Reality does consist of objects.
Birds sleep in trees, not in tables.
Bringing your very nice example to a dry programming language:
The birds do not sing, because the sun *rises*. Birds poll their environment. Illumination and temperature are functions of the position of the sun.
I'm an OODBMS advocate in some ways, I think they're great when in the hands of experts.
There are many different object databases. The most friendly comments we get come from database newbies.
In my opinion ObjectStore has done a terrible job for object databases in the past 8 years, by overcomplicating things. The simplest features need to work first. Being able to store objects would have been a first step. What did they do? They tried to skip two innovation steps by attempting transparent persistency. What did they achieve? Pointer chaos and the need for highly skilled experts to understand what was going on. We are working on a system from the ground up. Before we will even think about transparent persistency, we want to provide functionality to store and query objects in the most natural way possible.
until a fully expressive ad hoc query capability is on these object systems
We are working on a common basic API to query object databases.
http://odbms.org/soda/soda.zip
This API simply is intended to provide a programmatic interface to the functionality a query parser usually has.
An ad hoc query language (possibly an SQL- or OQL-derivate) would sit on top of this API.
Again:
We try to build the house from the ground up.
I have posted a "call for comments" to various Java and database newsgroups. What happened? I was flamed down for object databases in general and for the approach to do something new in particular. I found most arguments very ignorant and simply wrong. Maybe we get some more interesting comments from
does your ODBMS have associative B-Tree indices built in?
Yes.
that work when your query is traversing over collections? etc.
No.
In fact we have not released full Java Collection support to the public yet. It will be included with the release of version 1.1 by the end of this month.
Queries for array members will already be capable of using the internal indices.
We still have some work before us for member indices. The benchmarks available with the download show this very nicely.
Carl Rosenberger
db4o - database for objects
http://www.db4o.com
Some wrong assumptions in this comment:
[but ONLY using queries and transactions that are defined up front in your modeling/design process]
We are currently designing a query API to outperform SQL - with dynamic queries.
http://www.odbms.org/soda/soda.zip
[In the real world, data can be modeled hierarchically, but often shouldn't be.]
This is no argument against object databases. You are free to choose the hierarchy that you prefer.
[Circumventing the Need for a Query Language]
Many object databases do support query languages. We currently support query-by-example, the most natural approach. "Give me all objects like this one."
[just has one 32-bit integer member. In an OODBMS, the space required for an OID is many times larger than an instance of the class itself!!]
This is dependant on the implementation of the object database. In our system a 32-bit integer needs 4 bytes, what else? Strings have a variable length. They only need this length, a 4 byte OID and a 4 byte integer. The overall advantage is strongly dependant on the datamodel but typically our database file consumes less than half of what a relational database needs.
[every lookup of an OID potentially requires a search through every object in the system, not just the primary key of one table]
Now what if the OID exactly specifies the place in the file? Then it works like a hashtable - you get immediate access. All object databases use some kind of efficient tree mechanism to cache object data, typically one tree for every class.
[Defining primary keys is one of the easier tasks in relational modeling, IMHO.]
Yes.
Defining foreign keys is like modelling objects, just more abstract and less intuitive.
Carl Rosenberger
db4o - database for objects
http://www.db4o.com
It is interesting to see that a posting with so many wrong statements receives such a high rating here.
[database best practices and theory]
Reality is object-oriented. We use objects in our modern programming languages. Why should we flatten these out to tables with unnecessary keys, if we store objects? Relations between objects can be maintained transparently within the database. Let's forget about methods for the moment: objects are nothing else than recursive links of primitive types.
This is common-sense and there is no need to write scientific papers about it.
[you should design data before your application]
Yes!
You can design data by writing classes in your respective programming language.
[independence of the logical and physical layers of your database]
Where do you need tables here?
Class members define properties.
Methods define behaviour.
[shifting the performance optimization issues to the DBMS' optimizer]
Object databases also use optimizers to analyze queries.
[any schema change do not only need an application recompilation]
There are object databases that manage schema versioning automatically. Our product simply stores a superset of all used schemas. Schema changes can occur in realtime. You can even switch back and forth between different class versions.
...without recompilation of the engine.
[you won't be able to keep several logical schemas to different users]
Wrong. Our object database is not multi-user as of today but the current mechanism will allow different schemas for different concurrent users in the future. By the way: Do you typically have different tables for different users?
[rethink the data access path]
Reengineering is a terrible problem with relational databases. Strings are not typesafe, so you have to parse the entire application for strings with no help from the compiler. We are working on a typesafe query specification.
http://www.odbms.org/soda/soda.zip
[leaving it up to the DBMS to create the best access plans]
Our query optimizer generates an access plan for objects. Simply for query-by-example.
[so OODBMSs sounds nice but offer no real improvements over RDBMSs]
5 out of 100:
- Performance. Our object database beats any relational database insert performance by factor 10 to 100
- Ease of use. Store a complex object network with one single statement:
db.set(object);
- Retrieval of objects. The database manages to put all these stored objects back together again. It controls that only *1* instance of each object is created and everything is linked the way it was stored.
- More compact storage
- No more fixed length strings.
[which should give us practically all of the advantages of OODBMSs without their cons]
We are going the other way. We want to provide all the relational functionality that you wish with our object database. We might finally end up with very similar engines.
Carl Rosenberger
db4o - database for objects
http://www.db4o.com