Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Chriss Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Which IDE (& Database) for Java-DB development? 1
- Thread starter nat101
- Start date
-
1
- #2
I hope this doesn't sound painfully obvious. The choice of your IDE kinda depends on your employer/client. What back-end database do they have? For instance, my employer is an Oracle shop, so it's pretty clear I go with JDeveloper.
In this day and age, the big software firms give the developer the application essentially for free, then stick it to the employer when they deploy. Oracle calls this version the "RI" or Reference Implementation. So you can practice at home and on the job with your RI, then when it's ready you have to get your employer to buy the regular version. They ain't cheap.
These IDE's are big and powerful and wonderful. They write a lot of code for you. And there's the rub. The code they write may or may not please you. You may want to handle things in a more OOP way, or whatever.
I haven't found a Java IDE I really like. BUT, if you play their game, I have found them to be consistent and reliable. So my advise is to talk to your employer, then get yourself an RI.
In this day and age, the big software firms give the developer the application essentially for free, then stick it to the employer when they deploy. Oracle calls this version the "RI" or Reference Implementation. So you can practice at home and on the job with your RI, then when it's ready you have to get your employer to buy the regular version. They ain't cheap.
These IDE's are big and powerful and wonderful. They write a lot of code for you. And there's the rub. The code they write may or may not please you. You may want to handle things in a more OOP way, or whatever.
I haven't found a Java IDE I really like. BUT, if you play their game, I have found them to be consistent and reliable. So my advise is to talk to your employer, then get yourself an RI.
- Thread starter
- #3
Your information surprises me in two ways (good and bad).
The bad:
Java is touted to be the one language "write once; run everywhere". Do I need to worry about the back-end db when designing/writing/debugging? If our current backend is mssql on Windows do we need to worry that my Java work will not fly on a Unix/Oracle system? As a software company ready to invest in our next app (being that we have a client now) we want to ensure that our app will run on any JVM regardless of database.
The good:
RI is FREE? Really true? But does our app then REQUIRE that vendors db or JVM (isn't that free?) or what. I did some checking of Oracle's and Sun's sites and both vendors do indeed allow free downloads BUT they also offer 'better' products that need to be paid for. Sun has a free IDE, but the 'enterprise' IDE is $1995, Oracle also has jDevolper for "FREE or $995" (you choose!). This leaves me with a feeling that the free product is sort-of restricted with its capabilities. I tried but could not come up with a comparison table as to what the free product is missing.
I also wonder since Java is platform independant, how do these vendors assure themselves that they will be needed for deployment, and what exactly do they charge the end-user for?
Thanks you much;
-Nat
The bad:
Java is touted to be the one language "write once; run everywhere". Do I need to worry about the back-end db when designing/writing/debugging? If our current backend is mssql on Windows do we need to worry that my Java work will not fly on a Unix/Oracle system? As a software company ready to invest in our next app (being that we have a client now) we want to ensure that our app will run on any JVM regardless of database.
The good:
RI is FREE? Really true? But does our app then REQUIRE that vendors db or JVM (isn't that free?) or what. I did some checking of Oracle's and Sun's sites and both vendors do indeed allow free downloads BUT they also offer 'better' products that need to be paid for. Sun has a free IDE, but the 'enterprise' IDE is $1995, Oracle also has jDevolper for "FREE or $995" (you choose!). This leaves me with a feeling that the free product is sort-of restricted with its capabilities. I tried but could not come up with a comparison table as to what the free product is missing.
I also wonder since Java is platform independant, how do these vendors assure themselves that they will be needed for deployment, and what exactly do they charge the end-user for?
Thanks you much;
-Nat
HenryMonster
Programmer
Nat101,
Java is really 99.9 % platform independent,
but not database independent.
If your Java app originally developped under
Windows has a hardcoded file name, say
C:/mydir/myfile.ext (Java handles / in Windows properly)
this program will not open this file on Unix
because they do not have drive letters in Unix.
So it's 99.9% for platform compatibility.
The reason it's not database compatible is because
when you work with databases you have to write
SQL statements once in a while
And unfortunately different database vendors have
variations in their SQL implementation.
Let's talk about outer joins - the simplest common
thing in DB-programming:
in Oracle you would say:
where t1.id = t2.id(+)
while in Sybae you would have to say
where t1.id* = t2.id
while in MSSQL you have additional syntax for that.
It's very conventient to use database build in functions
to manipulate with strings, dates etc.
They are very different between databases, alas !
So unless you stick to the simplest forms of select,
update, insert and delete you do not have the compatibility.
You can program in a smart way and create
some database classes, which will screen
your Java app from these differences;
but again these database classes will be different for
each database if you want to use all bells and
whistles of a particular database SQL.
Java is really 99.9 % platform independent,
but not database independent.
If your Java app originally developped under
Windows has a hardcoded file name, say
C:/mydir/myfile.ext (Java handles / in Windows properly)
this program will not open this file on Unix
because they do not have drive letters in Unix.
So it's 99.9% for platform compatibility.
The reason it's not database compatible is because
when you work with databases you have to write
SQL statements once in a while
And unfortunately different database vendors have
variations in their SQL implementation.
Let's talk about outer joins - the simplest common
thing in DB-programming:
in Oracle you would say:
where t1.id = t2.id(+)
while in Sybae you would have to say
where t1.id* = t2.id
while in MSSQL you have additional syntax for that.
It's very conventient to use database build in functions
to manipulate with strings, dates etc.
They are very different between databases, alas !
So unless you stick to the simplest forms of select,
update, insert and delete you do not have the compatibility.
You can program in a smart way and create
some database classes, which will screen
your Java app from these differences;
but again these database classes will be different for
each database if you want to use all bells and
whistles of a particular database SQL.
- Thread starter
- #5
Let me give my reasons for saying you should go with, for instance, JDeveloper if you had Oracle as your database. If you are an "Oracle Shop" you will find your company will want you to use Oracle tools. JDeveloper is a good product, and will write a lot of code for you. This CAN be a good thing since your boss wants you to finish your projects quickly. Now, if you take that code and try to pull it into JBuilder or Visual Cafe, you will have problems. They do stuff in THEIR way, so the IDE will have problems maintaining stuff...typically the GUI interface. So my point here is, reduce your problems in you company by using the same tool. Your company wants programmers to work in teams. Just keep the friction to a minimum by using the same tool.
Another point, you will find JDeveloper will automatically write a lot of code to help you map fields on a form to fields in a database. This WILL be Oracle specific. If everyone is using the same tool, it's okay (not great, but okay). Moving this code to another IDE may have problems. But substituting a different database on the back end WILL give you problems, because Oracle will write stuff their way, to lock you into their product.
Another point. Java IS platform independent, and it can be ALMOST database independant. Just throw away any code JDevelper (or other IDE) writes for your database connection and follow Sun's J2EE guidelines and you will be fine. If you write your code using JDBC, and write to the simplest implementation of it, you will be just fine. The problems come up when you try to use proprietary data access stuff a db might offer. They will not be transferable. Or if your IDE writes code for you. That will always be problematic. If there are specific areas of code that are database vendor specific, be sure to isolate them in easily identifiable classes, so that you can quickly change a FEW things if you change the backend. Careful planning will make it independent.
As far as finding a database access wrapper to make things easier, I'm looking around for that myself. What I have found doesn't completely please me. You might want to look into JDO. (Go to a web site like and search on JDO) This tries to do data access in an object-oriented way. That's a good thing, since JDBC is NOT an object oriented way of doing stuff. One bad thing is that there are at least two version of JDO. (Do we have standards? Yeah, we have LOTS of standards!)
One more point. HenryMonster is absolutely right. There comes a time when you absolutely MUST write some SQL, and sometimes the SQL might be a little more that plain vanilla. The way to hack around that is to get your friendly DBA to put together a stored procedure, or view (or whatever you want to call it) to have the db do the selecting for you. Have the SQL statement sitting on the machine ahead of time and just call it by name. This can go a LONG way in making your app db vendor independent!
Another point, you will find JDeveloper will automatically write a lot of code to help you map fields on a form to fields in a database. This WILL be Oracle specific. If everyone is using the same tool, it's okay (not great, but okay). Moving this code to another IDE may have problems. But substituting a different database on the back end WILL give you problems, because Oracle will write stuff their way, to lock you into their product.
Another point. Java IS platform independent, and it can be ALMOST database independant. Just throw away any code JDevelper (or other IDE) writes for your database connection and follow Sun's J2EE guidelines and you will be fine. If you write your code using JDBC, and write to the simplest implementation of it, you will be just fine. The problems come up when you try to use proprietary data access stuff a db might offer. They will not be transferable. Or if your IDE writes code for you. That will always be problematic. If there are specific areas of code that are database vendor specific, be sure to isolate them in easily identifiable classes, so that you can quickly change a FEW things if you change the backend. Careful planning will make it independent.
As far as finding a database access wrapper to make things easier, I'm looking around for that myself. What I have found doesn't completely please me. You might want to look into JDO. (Go to a web site like and search on JDO) This tries to do data access in an object-oriented way. That's a good thing, since JDBC is NOT an object oriented way of doing stuff. One bad thing is that there are at least two version of JDO. (Do we have standards? Yeah, we have LOTS of standards!)
One more point. HenryMonster is absolutely right. There comes a time when you absolutely MUST write some SQL, and sometimes the SQL might be a little more that plain vanilla. The way to hack around that is to get your friendly DBA to put together a stored procedure, or view (or whatever you want to call it) to have the db do the selecting for you. Have the SQL statement sitting on the machine ahead of time and just call it by name. This can go a LONG way in making your app db vendor independent!
- Thread starter
- #7
Thank you for a most-enlightning post! Not only did it clarify my questions, I also learned that I am on the right track with the wrapper idea. Actually I really expected it to be part and parcel of Java in the first place.
Also, is it fair to assume (I know: Don't assume!) that Sun's IDE would write the most generic (db related) code, since Sun does not market its own db?
On the other hand, if I am willing to commit to a certain db, based on the quality of the IDE, which IDE would I choose?
Thanks again.
-Nat
Also, is it fair to assume (I know: Don't assume!) that Sun's IDE would write the most generic (db related) code, since Sun does not market its own db?
On the other hand, if I am willing to commit to a certain db, based on the quality of the IDE, which IDE would I choose?
Thanks again.
-Nat
People very often buy Sun machines to run Oracle. As goes one, goes the other. Watch their stock prices. They march in lock step.
I haven't seen Forte for a while, but I don't recall any automatically written code for data access. (I could be wrong about this.) I wouldn't expect any either, since that would be stepping on the toes of their brother.
So I come back to my original point. If your company is an Oracle shop, get JDeveloper. It will have wizards that write code to access Oracle databases. If not, look into Visual Cafe and JBuilder, both EXCELLENT IDE's. But (and I guess this is my main point) get everyone on your team to agree on a single IDE. Otherwise you will have hours and hours of grief trying to share code and work jointly.
I haven't seen Forte for a while, but I don't recall any automatically written code for data access. (I could be wrong about this.) I wouldn't expect any either, since that would be stepping on the toes of their brother.
So I come back to my original point. If your company is an Oracle shop, get JDeveloper. It will have wizards that write code to access Oracle databases. If not, look into Visual Cafe and JBuilder, both EXCELLENT IDE's. But (and I guess this is my main point) get everyone on your team to agree on a single IDE. Otherwise you will have hours and hours of grief trying to share code and work jointly.
- Thread starter
- #9
Thanks for the input.
You know; it's a pity. The beauty of 'write once; run anywhere' is greatly hampered by a) incompatible databases, and b) incompatible IDE's! I mean who writes a project without an IDE these days? Why should one IDE have a problem importing a project written by another IDE? Unless one IDE is not writing clean code. (Besides db specific stuff.)
You know; it's a pity. The beauty of 'write once; run anywhere' is greatly hampered by a) incompatible databases, and b) incompatible IDE's! I mean who writes a project without an IDE these days? Why should one IDE have a problem importing a project written by another IDE? Unless one IDE is not writing clean code. (Besides db specific stuff.)
I'll tell you what I'm using right now. Textpad. ( It's shareware out of Great Britian. Cost $27 bucks American. It's a snap to install. Right away it recoginzes restircted words in Java and colors them, helps you to use and match brackets. And you can use their 'workspaces' to approximate packages in Java.
If you use your imagination, you can go a LONG way with this simple text editing package. Control - S saves the document, Control-1 compiles it, Control-2 runs it. Sweet.
I like it because it DOES NOT GET IN THE WAY. Of course, there is no WISIWYG for GUI's. No syntax completion. No code writing wizards. But, hey, it's just $27!
It's great to do simple stuff. I use it when I am working through a new book...using it today as I work in SAMS "Teach Yourself J2EE In 21 Days". Typically, that's all you need.
And it makes text files, for heavens sake. Everyone can share those!
So I use this when I am learning something new, doing a demo, doing something simple. BUT, when you start working on a project with more than three people, and the project is mission critical, and long term, you are going to be forced into using an IDE from Sun, Oracle, or IBM where you can check out code, check it in, keep track of who does what to what and when, yadda, yadda......
Java IS write once, run anywhere. It's just the way WE use it that makes it limited. Again, Sun has guidelines on how to write stuff that can be run anywhere. Go to java.sun.com and nose around in J2EE.
If you use your imagination, you can go a LONG way with this simple text editing package. Control - S saves the document, Control-1 compiles it, Control-2 runs it. Sweet.
I like it because it DOES NOT GET IN THE WAY. Of course, there is no WISIWYG for GUI's. No syntax completion. No code writing wizards. But, hey, it's just $27!
It's great to do simple stuff. I use it when I am working through a new book...using it today as I work in SAMS "Teach Yourself J2EE In 21 Days". Typically, that's all you need.
And it makes text files, for heavens sake. Everyone can share those!
So I use this when I am learning something new, doing a demo, doing something simple. BUT, when you start working on a project with more than three people, and the project is mission critical, and long term, you are going to be forced into using an IDE from Sun, Oracle, or IBM where you can check out code, check it in, keep track of who does what to what and when, yadda, yadda......
Java IS write once, run anywhere. It's just the way WE use it that makes it limited. Again, Sun has guidelines on how to write stuff that can be run anywhere. Go to java.sun.com and nose around in J2EE.
- Thread starter
- #11
Point(s) well taken. In our case, being a system's house, we outsource jobs, or modules of software. Back in the old days, with plain editors, no problems. Today, we don't want to base our outsource contracts on the developers ide! Unless we force all subcontractors to use our ide on-line, again telling em which ide to use.
BTW, would you know which ide, if any, has a good data-modeler (or integrates with one) for the db design and mainteneance? It should be able to create/edit/delete tables automatically from the design model, check for normalization errors, etc.
Thanks again.
-Nat
BTW, would you know which ide, if any, has a good data-modeler (or integrates with one) for the db design and mainteneance? It should be able to create/edit/delete tables automatically from the design model, check for normalization errors, etc.
Thanks again.
-Nat
I am out of my depth on this question. JDeveloper does an okay job. Other folks need to chime in on other IDE's.
I can't help myself. One of my favorite articles on OO design (and UML tools) is this:
Holub speaks with wisdom of experience.
I can't help myself. One of my favorite articles on OO design (and UML tools) is this:
Holub speaks with wisdom of experience.
Just gotta give you this link:
Ten reasons to dump our IDE - kinda fun.
Ten reasons to dump our IDE - kinda fun.
- Thread starter
- #14
Look this site
Guest_imported
New member
- Jan 1, 1970
- 0
using Textpad?
don't kid yourself... programming with a text editor is for dinosaurs and 1st year comp sci students.
Next time you visit java.sun.com to get J2SE 1.4 you will see that Forte 3.0 CE comes with the standard download. Free, feauture-rich, and buggy as heck. But even with the bugs, it's way better than using a text editor.
Code completion, link to source from compiler errors, and integration with CVS should be all the reasons you need.
don't kid yourself... programming with a text editor is for dinosaurs and 1st year comp sci students.
Next time you visit java.sun.com to get J2SE 1.4 you will see that Forte 3.0 CE comes with the standard download. Free, feauture-rich, and buggy as heck. But even with the bugs, it's way better than using a text editor.
Code completion, link to source from compiler errors, and integration with CVS should be all the reasons you need.
- Thread starter
- #17
You know Turncom; Weiner has a point. You don't HAVE to let the ide generate code; use it to maintain the code, at the least. As an outsider I would guess that all ide's will be able to read your code since it excludes specific features per ide. M-a-y-b-e that carries some weight. BUT, in real life, with that kind of code-generator in front of you, it might be hard to resist![[smile]](/data/assets/smilies/smile.gif "[smile] [smile]")
.
-Nat
.-Nat
- Status