Java Forum / General / June 2004
Implement SQL in Java
Peter - 31 May 2004 10:00 GMT Hi Please give me some advantages for implement a database in JAVA. If we develop a JAVA-database, it must lose proformance. Almost database doesn't need cross-platform. So what is the rest of advantage?
thanks from Peter (cmk128@hotmail.com)
Andrew Thompson - 31 May 2004 10:08 GMT > Please give me some advantages for > implement a database in JAVA. .. Please give me some advantage for not checking the capital letters of 'Java' before posting.. ;-)
 Signature Andrew Thompson http://www.PhySci.org/ Open-source software suite http://www.PhySci.org/codes/ Web & IT Help http://www.1point1C.org/ Science & Technology
Chris Smith - 31 May 2004 16:01 GMT > Please give me some advantages for implement a database in JAVA. If > we develop a JAVA-database, it must lose proformance. Almost database > doesn't need cross-platform. So what is the rest of advantage? Languages are chosen for a number of reasons, including ease of development, experience of the development team, even political reasons involving relationships with other businesses. No one in this newsgroup can make your choice for you. We could suggest how Java rates in various concerns, but only if you tell us the alternatives you're considering.
Incidentally, I wouldn't be too concerned with performance of Java in a database application. The performance issue is largely a myth; Java pretty much competes with any other language in terms of performance, and you don't care so much about startup time for a long-running server application. I'd be more concerned with deciding whether Java's layer of abstraction over the I/O interface is really appropriate for a database application. I don't know the answer to that question, but you should take a serious look at Java's NIO API and decide whether you can implement a database with it before you get much into it.
 Signature www.designacourse.com The Easiest Way to Train Anyone... Anywhere.
Chris Smith - Lead Software Developer/Technical Trainer MindIQ Corporation
David Segall - 31 May 2004 16:59 GMT >Hi > Please give me some advantages for implement a database in JAVA. If [quoted text clipped - 3 lines] >thanks >from Peter (cmk128@hotmail.com) Why "it must lose performance"? Which language might you use instead of Java?
The release of the .NET framework indicates that Microsoft has accepted the protected Virtual Machine and object oriented language model exemplified by Sun's Java language and environment. The performance will be dictated by how well the vendor has optimised the language drivers and the database. It seems reasonable to assume that Microsoft's SQL Server will perform better using .NET and an Oracle database will perform better using Java because Oracle have selected Java as their development environment. You will need to select the database and the development environment based on other criteria.
The disadvantage with .NET is not only that it cannot be used on other platforms. It is subject to the whims of Microsoft and it can be rendered obsolete in exactly the same way that Visual Basic "Classic" was discarded. Oracle, IBM and Sun support Java with a Java Virtual Machine and JDBC drivers. Microsoft provides JDBC drivers for SQL Server and MSDE. In other words, Java provides the best guarantee of single (Windows) platform support in addition to being the only choice for multi-platform support.
Peter - 01 Jun 2004 03:29 GMT > >Hi > > Please give me some advantages for implement a database in JAVA. If [quoted text clipped - 24 lines] > single (Windows) platform support in addition to being the only choice > for multi-platform support. Sorry guys, i lead you misunderstand. I was asking the advantage to development a Database, not a database application in Java. If you develop a database in Java, it must have worst performance, because Java is slow then c++ at least 80%. Then should we go to make a database in Java? Does it have market?
thanks from Peter (cmk128@hotmail.com
Liz - 01 Jun 2004 04:21 GMT > > >Hi > > > Please give me some advantages for implement a database in JAVA. If [quoted text clipped - 34 lines] > thanks > from Peter (cmk128@hotmail.com I think the earth will continue to spin if you don't develop one in Java.
Yu SONG - 01 Jun 2004 10:16 GMT > Sorry guys, i lead you misunderstand. > I was asking the advantage to development a Database, not a [quoted text clipped - 5 lines] > thanks > from Peter (cmk128@hotmail.com 80% slower??? Have you tried that?
It has a market, and it depends on your DB. (Of course, this won't happen if you've made a DB without any signifiant improvements and 80% slower than these available ones)
 Signature Song
More info.: http://www.dcs.warwick.ac.uk/~esubbn/
Peter - 02 Jun 2004 04:27 GMT > > Sorry guys, i lead you misunderstand. > > I was asking the advantage to development a Database, not a [quoted text clipped - 12 lines] > (Of course, this won't happen if you've made a DB without any signifiant > improvements and 80% slower than these available ones) It is hard. Other DB are made in C++. Java is impossible to faster than c++ i think.
thanks from Peter (cmk128@hotmail.com)
Chris Smith - 02 Jun 2004 05:13 GMT > It is hard. Other DB are made in C++. Java is impossible to > faster than c++ i think. It's exactly these statements that suggest to knowledgable people here that you don't know what you're talking about. Whether Java is slower than C++ (and by how much) on average, for typical code, is a very complex question that probably won't ever have a simple answer, but it's clearly false that "Java is impossible to faster than c++".
After all, there are details of the Java language that permit optimizations that are not possible in C++, and the VM model allows for both dynamic optimizations that can be extremely helpful in some situations and also for more specialized code than can be generated by a once-only compiler that has to target a whole host of processors in a family. It's fairly well-established, for example, that CPU-bound applications with complex floating-point calculations are generally far faster in Java than C++. Facts just don't fit with your simplified world-view in which a Java application is always slower than the same application in C++.
 Signature www.designacourse.com The Easiest Way to Train Anyone... Anywhere.
Chris Smith - Lead Software Developer/Technical Trainer MindIQ Corporation
Roedy Green - 02 Jun 2004 05:35 GMT >It is hard. Other DB are made in C++. Java is impossible to faster than c++ i think. I don't understand why there are so many SQL engines. There are so many other interesting projects that have not been tackled even once.
See http://mindprod.com/projects/projects.html
The big advantages of an SQL engine in Java are:
1. it is truly portable. You don't need a separate tweak and separate install process for each platform.
2. It could potentially run in the same JVM, thus improving the bandwidth of communication between the SQL and client part.
3. It can be very simply installed, just add a reference to a jar to the JNLP spec.
One big time waster in SQL is composing queries then parsing them again and taking apart rows field by field. Data could be delivered in both directions as preparsed objects. Perhaps someone could come up with a more Java-esque SQL interface that bypasses all that packing and unpacking overhead.
 Signature Canadian Mind Products, Roedy Green. Coaching, problem solving, economical contract programming. See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.
Casey Hawthorne - 02 Jun 2004 08:40 GMT Are there any Java (open source) OODBMS engines?
>I don't understand why there are so many SQL engines. There are so >many other interesting projects that have not been tackled even once. > >See http://mindprod.com/projects/projects.html -- Regards, Casey
Roedy Green - 02 Jun 2004 09:59 GMT >Are there any Java (open source) OODBMS engines? There are more SQL engines than you can shake a stick at. Check out the list at http://mindprod.com/jgloss/sql.html to see which ones are opensource.
 Signature Canadian Mind Products, Roedy Green. Coaching, problem solving, economical contract programming. See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.
nospam@nowhere.com - 04 Jun 2004 03:49 GMT > I don't understand why there are so many SQL engines. There are so > many other interesting projects that have not been tackled even once. It could be because people work on projects that interest them, and don't work on projects that don't interest them.
Michael N. Christoff - 01 Jun 2004 23:29 GMT > If you develop a database in Java, it must have worst performance, > because Java is slow then c++ at least 80%. Where exactly did you get this information from? Do you have a link to the website or paper that says this?
l8r, Mike N. Christoff
Michael N. Christoff - 03 Jun 2004 15:08 GMT > > >Hi > > > Please give me some advantages for implement a database in JAVA. If [quoted text clipped - 31 lines] > because Java is slow then c++ at least 80%. Then should we go to make > a database in Java? Does it have market? I think you need to take an extended look at this link. You can decide for yourself whether "Java is slow then c++ at least 80%" or not.
http://www.idiom.com/~zilla/Computer/javaCbenchmark.html
I post this, but I'm 99% sure you won't read it. Ignorance is bliss I guess.
l8r, Mike N. Christoff
> thanks > from Peter (cmk128@hotmail.com Hylander - 03 Jun 2004 20:15 GMT > > >Hi > > > Please give me some advantages for implement a database in JAVA. If [quoted text clipped - 31 lines] > because Java is slow then c++ at least 80%. Then should we go to make > a database in Java? Does it have market? You mean to develop a pure java database program like Hypersonic I think. Hypersonic / hsql may have some open sources that you can use to get ideas or you may decide to contribute to it/get involved.
If you are citing an example of programming a database to harp on Java's renowned performance issues, you will find that the perceptions are often based on a small picture. To summarize, the slowness that many users experience is based on the GUI toolkit and not necessarily java itself. The next level of understanding however concerns itself with the byte code interpreter of the various JVM implementations. These vary in performance but also buy you various advantages compared to C/C++.
Often, you will find that if you were to provide the same levels of safety and robustness/cleanup in a C program, the performance of that program would come very close to java's performance. The byte code interpretation overhead is nearly nullified with the progress that has been made over the years. It is on the order of 50% or less overhead. (which is good considering that many initially saw 10x or 1000% overhead initially).
When it comes to language, we could take a look at the WordPerfect vs MSWord case study. WordPerfect lost it's market to Word *because* it was striving too hard to be performant while not being competitive with features / actual user/API developer experience. You can get to market much quicker in a language that is easier to program in. Also, given Moore's law (something about hardware performance doubling) and given that hardware is FTMP a commodity, (a non issue), you should really consider the big picture and then find out of performance figures into it. (the actual user's experience/ultimate perceived value being offered).
Roedy Green - 03 Jun 2004 21:23 GMT > The byte code >interpretation overhead is nearly nullified with the progress that has >been made over the years But Java is NOT byte code interpreted anymore except in cellphones. It is hotspotted, jitted, or natively compiled.
 Signature Canadian Mind Products, Roedy Green. Coaching, problem solving, economical contract programming. See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.
Mohun Biswas - 03 Jun 2004 22:49 GMT >>The byte code >>interpretation overhead is nearly nullified with the progress that has >>been made over the years > > But Java is NOT byte code interpreted anymore except in cellphones. > It is hotspotted, jitted, or natively compiled. Right, and these serve to nullify the byte code interpretation overhead. Like he said.
 Signature Thanks, M.Biswas
Roedy Green - 04 Jun 2004 01:03 GMT >>>The byte code >>>interpretation overhead is nearly nullified with the progress that has [quoted text clipped - 5 lines] >Right, and these serve to nullify the byte code interpretation overhead. >Like he said. He said something ambiguous that needs to be stated clearly. He made it sound as if byte interpretation technology has advanced.
It is no different. It has been replaced.
 Signature Canadian Mind Products, Roedy Green. Coaching, problem solving, economical contract programming. See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.
Mohun Biswas - 04 Jun 2004 02:13 GMT >>>>The byte code >>>>interpretation overhead is nearly nullified with the progress that has [quoted text clipped - 7 lines] > > He said something ambiguous that needs to be stated clearly. Where I come from, starting with "But ... NOT" is the way to shout someone down, not the way to clarify.
 Signature Thanks, M.Biswas
Roedy Green - 04 Jun 2004 02:34 GMT >Where I come from, starting with "But ... NOT" is the way to shout >someone down, not the way to clarify. Trolls have been driving me nuts on this issue recently. I figured he was doing the same stupid trick. You offered a different way to interpret his post.
 Signature Canadian Mind Products, Roedy Green. Coaching, problem solving, economical contract programming. See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.
Hylander - 04 Jun 2004 16:11 GMT > >Where I come from, starting with "But ... NOT" is the way to shout > >someone down, not the way to clarify. > > Trolls have been driving me nuts on this issue recently. I figured he > was doing the same stupid trick. You offered a different way to > interpret his post. Please don't associate me with trolls and treat me as such simply because you've had to deal with them. (someone by the name of Sigmeund IIRC mentioned something about "displaced anger" that seems fitting here).
I think I've dedicated enough of my waking and sleeping life to java programming to deserve more than that. Not that I'm very publically seen on it or a high contributor or anything (yet) although I do plan on releasing my ideas to sourceforge at some point in the future). Just because I don't post here a lot doesn't mean I don't productively lurk here either.
Hylander - 04 Jun 2004 16:06 GMT > >>>The byte code > >>>interpretation overhead is nearly nullified with the progress that has [quoted text clipped - 8 lines] > He said something ambiguous that needs to be stated clearly. He made > it sound as if byte interpretation technology has advanced. Hey! To someone who is pedantically knowledgable on Java, everything would be ambiguous. Whether it needs clarification is subjective. I do appreciate you indicated exactly what progress I was referring to. I'm not sure I would even limit it to just those though. I expected something more comprehensive out of you Roedy. ;)
> It is no different. It has been replaced. Lee Fesperman - 01 Jun 2004 00:31 GMT > Hi > Please give me some advantages for implement a database in JAVA. If > we develop a JAVA-database, it must lose proformance. Almost database > doesn't need cross-platform. So what is the rest of advantage? Lose performance? Not in this day and age! And, JVMs continue to improve. Better ones are coming down the pike, including some that have specific capabilities to improve Java DBMSs. Improvements in static compilation are pretty stagnant. Besides, they are limited by being static and by the nature of languages, like C & C++.
DBMSs that are implemented in static compiled languages are mostly dependent on hardware improvements to achieve better performance. Even then, they often must be recompiled to take advantage of the new hardware capabilities. Systems that depend on VMs can instantly take advantage of improved hardware, without recompilation.
A database doesn't need cross-platform? I can hardly begin to understand what this could mean. Let me just say that a properly implemented Java DBMS can run on any operating system and hardware architecture that your Java applicaton will. Also, read the comments above closely.
I shan't expend much more bandwidth on this rather large topic, but I will touch on one additional thing. Nowadays, a number of DBMSs support Java running on the database server, for UDF's (User Defined Functions), UDT's (User Defined Types) and Stored Procedures. Non-Java DBMSs must include their own JVM to provide this capability. These JVMs can never be best-of-breed. A Java DBMS, on the other hand, can use the same JVM they are running on to provide such capabilities. Thus, they can always take advantage of the best/latest JVMs available for a given platform. For more details, see my article: "Java and Database Synergy" (http://www.firstsql.com/javadbsynergy.shtml)
 Signature Lee Fesperman, FirstSQL, Inc. (http://www.firstsql.com) ============================================================== * The Ultimate DBMS is here! * FirstSQL/J Object/Relational DBMS (http://www.firstsql.com)
Hylander - 03 Jun 2004 20:25 GMT > > Hi > > Please give me some advantages for implement a database in JAVA. If > > we develop a JAVA-database, it must lose proformance. Almost database > > doesn't need cross-platform. So what is the rest of advantage? > > Lose performance? Not in this day and age! And, JVMs continue to improve. Better ones I think it has a lot to do with modernization of Java's JVMs and the lack of modernization and attention given to the corresponding C compilers and generated executables. Power of peer review and popularity.
Liz - 01 Jun 2004 02:47 GMT > Hi > Please give me some advantages for implement a database in JAVA. If > we develop a JAVA-database, it must lose proformance. Almost database > doesn't need cross-platform. So what is the rest of advantage? Why do you want to develop a database when there are some good ones for free?
Peter - 02 Jun 2004 02:27 GMT > > Hi > > Please give me some advantages for implement a database in JAVA. If [quoted text clipped - 3 lines] > Why do you want to develop a database when there are some good ones for > free? If you don't develop one, how can you really know what a DB is? If you don't develop one, all your theory that learnt from university are still rubbish.
thanks from Peter (cmk128@hotmail.com)
Liz - 02 Jun 2004 06:36 GMT > > > Hi > > > Please give me some advantages for implement a database in JAVA. If [quoted text clipped - 10 lines] > thanks > from Peter (cmk128@hotmail.com) I don't have to be able to lay an egg to be able to tell a rotten one.
Michael Borgwardt - 02 Jun 2004 09:41 GMT > If you don't develop one, how can you really know what a DB is? > If you don't develop one, all your theory that learnt from university > are still rubbish. While hands-on experience may be better than theory *in theory*, in practice it takes too much time and there are too many gritty details to distract from the essentials. Theory is often quite sufficient.
Second, if you just want to learn how to do it, performance is irrelevant, and ease of development everything, right? And that's one of Java's strongest points.
Stefan Poehn - 04 Jun 2004 08:00 GMT > > > Hi > > > Please give me some advantages for implement a database in JAVA. If [quoted text clipped - 7 lines] > If you don't develop one, all your theory that learnt from university > are still rubbish. And you have to develop an operating system to know what an OS is. Oh, and a new internet protocol. Developing a new programming language and its compiler is also much fun. In your free weekends you can develop an office suite.
> thanks > from Peter (cmk128@hotmail.com) Michael Borgwardt - 02 Jun 2004 09:43 GMT BTW, there are at least two DBMS's implemented in Java that I know of: http://hsqldb.sourceforge.net/ http://mckoi.com/database/
Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
|
|