Slashdot Mirror
Java IDEs?
Billy the Mountain asks: "In the startup company I'm in, we just got a new president and she asked us about ways of increasing developer productivity. We develop Java applications, servlets and JSP. I don't use an IDE. I use an enhanced text editor, EditPlus, because I like its color coding of keywords. I guess what I'm asking is what Java IDEs do you use and what features do you like best?" If you were to build a Java IDE from the ground up, what features would you include?
I've also used Codewarrior for Java, and have been pleasantly surprised. It's a top-notch environment. Metrowerks has done some fine work.
Forte/NetBeans has a way to go. What a pig. 3.0 has some nice speed and stability increases...
If you don't need a really fancy setup, try jEdit. It's an open source text editor with syntax coloring(60 file types!), and the plug-ins avaliable give you plenty of project management features.
And a dark horse: IntelliJ. I really like it. Lots of "enterprise" features bundled in a relatively cheap package.
What does a Java IDE need?
/. waiting for Netbeans to download updates as I wrote this.
;^D Without a 1.8 GHz machine, it's still a little slow.
* Open source -- I want a new feature, I add it. I see a bug, I fix it.
* Code completion -- As much as you might hate M$, there ain't no faster coding that Visual Basic, and most of that is due to Intellivisio -- ur, Intellisense. If the IDE finishes my lines for me, that's half the battle right there. (Thanks, Mr. Ness)
* GUI RAD -- Look, I want to program the nuts and bolts, not spend tons of times making a beautiful set of buttons. A RAD lets me WYSIWYG my way to a great UI.
* Syntax highlighting -- as stated in the post, I like to see what's a string, what's a comment, and what's code. And see it quickly.
* The exact same UI cross platform -- When I go from Windows at work to a UNIX workstation down the hall to my iBook at home, I want to use the same tool to program my "write once, test -- ur -- run everywhere" code. My code's crossplatform, why shouldn't my IDE be too?
Hey, lookit there, I just described http://www.netbeans.org !
Sun funds much of the development team, so I know I have support. But before Sun gets their hands on the code to turn it into Forte, I've got full access. Was actually reading
Only drawback -- I sure wish this was written in assembler.
It's all 0s and 1s. Or it's not.
oy. UML is nice for meetings and sketching things out, but the diagrams can (and should) be generated from the code, so any particular developer doesn't need to use it.
All developers should be versed in reading UML and drawing out pseudo-UML on a whiteboard or a sketch page or whatever. But it's a needless step (for some developers, not all) in the development process when it comes down to a developer writing out the code for his/her component.
So, I like Emacs+JDEE (for myself) and Eclipse (as a suggestion for others that don't like emacs). ArgoUML is becoming a decent free UML tool. UML diagrams should be generated from the code for new developers to be able to understand a developed system. High level architectural docs should be UML or better yet, simpler pseudo-UML.
MRSH-Recording device, corned beef sandwich with kraut, seafaring bird, and the foamy top of a beverage.
I am surprised at how few comments IntelliJ IDEA is getting here. It is very good. The refactoring features (hence the Fowler connection) are so useful that I think it's likely that most major IDEs will copy them in the new few years.
I've also had good results with JBuilder, with VisualAge (for projects where I have no need for source code in files, which is not many of them...), and with plain old text editing.
It's a cron-job type of thing and you'd have to write some elisp to integrate it with the lxr output (or hook into the fragment database), but it could be done:
;-). (actually I'm using Galeon and kind of like it better than IE, so scratch my bitching about Mozilla)
http://sourceforge.net/projects/lxr
It looks like they're nearing a 1.0 release and have got the database integration and CVS integration cleaned up a lot lately. You'd still have some work to do if you wanted a fully-automated in-editor version of what you're asking for, but it would be fun stuff to implement, I think most of the drudgery is taken care of by now. Wow LXR has come a long way!!!
When I was a full-time Java/C/C++ developer I often used DDD + XEmacs + the combination of LXR and CVSweb to keep my wits about me and could therefore point other developers to whatever I'd done recently, how it worked, and what it involved. Now I'm more of an admin/loose cannon...
Haven't used LXR in a while and it seems like all my code has degenerated into componentized Perl, C, and Bash lately, but I still use CVSweb, JavaDoc-style docs (POD, JavaDoc, PHPdoc, Doxygen, whatever works), and a syntax-hilighting editor (Vim or XEmacs) whenever I write anything that'll be deployed for more than a week.
I know that the Gnome and Mozilla projects use LXR integrated with CVSWeb, but don't judge it harshly just because of that
Remember that what's inside of you doesn't matter because nobody can see it.
I use EditPlus for general programming & text editing - it has syntax coloring files for everything (httpd.conf files even).
I have used Together, and I usually dump new lumps of code in to get a handle on them. I don't use it for day-to-day editing.
For straight Java that winds up being packaged as a JAR, I use VisualCafe. The JAR packaging tool is very nice. I'm a "real coder" and don't use the debugger really, so I can't comment for those who have had problems.
I have been investigating NetBeans and believe that for machines that are 650MHz+ it's fine.
Finally, the most revolutionary tool we use, which has radically improved our development is Macromedia DreamWeaver UltraDev. For our JSP work, I can't say enough nice things. It does an amazing job of parsing existing code and adding new code without reformatting or destroying custom tweaks. We have done a few things, like standardizing on a JDBC-driver level connection pooling mechanism, and it works great.
Regardless of your tools, I cannot recommend adding memory to your development machine enough. No matter what you are doing, it's a lot more productive to be an alt-tab away from your other tool than having to go through a disk grind to load another app. 256MB would be a minimum. And before you squawk, it's cheap! Damn cheap!
As a final note, we use CVS for version control. We mostly do development on Win2K and deploy to Linux and Solaris. Finally, we are really looking at Mac OS X closely as MySQL, Postgres and Apache look better there than on Win2K.
All in all, it's a bunch of tools, but I feel about as productive as I have since THINK Pascal (bonus points if you remember that one).
than a good IDE should have good debugger support...
I'm not saying that there shouldn't be a debugger at all. In fact, I think I said that occasionally one is useful (particularly for analyzing core dumps). I'm mostly taking issue with the AC who ignores the advice anyone who doesn't use a debugger, which is absurd.
I know I'll never convince people who use debuggers, because it sounds so counter-intuitive, but I have to put out the seed every now and then. I used to go through it with my employees all the time. It used to drive me crazy watching them stare blindly at the debugger, when all they had to do was put in some printf statements and then analyze the program flow to see the problem.
And that's the big advantage of printf-style debugging. It lets you see the flow of your program at a higher level, rather than micro-watching it at the line-by-line level. It lets you selectively output what's important, rather than having to deal with all the trivial details. Also, when you leave in all the tracing, you get a debug log everytime you run it to see what happened when something else blows up.
Oh well, I know from experience that this is one of those debates that you can't win. :)
Sometimes it's best to just let stupid people be stupid.
What I have found is that if you mandate one IDE, whatever it is someone will loose productivity. Personally the approach I've generally taken is that people are free to use whatever IDE they like, we have a good ANT setup for building and groups of people who use non-ant aware tools like JBuilder set up those configs which we also maintain in source control. I use Emacs, but other people on my team use Vim, SlickEdit, NetBeans (which I also use for debugging), JBuilder, and Textpad (sigh). The only way you can loose is that you can't buy many bundles usually, but most of the tools people like turn out to be free for the most part (except of course for JBuilder and TogetherJ, which is useful for design but can be hnady other times as well).
.bashrc (defines environemnt variables needed to run ant along with ant shortcut alias)
.bashrc under name setenv.sh)
What is good to standardize is directory structures and locations of projects, which helps you define the environment for the build a little easier.
The setup that seems to work well for us is something like this (some things are new elements I've not quite tries yet):
<DIR - project root>
build.xml (ant build script)
setEnv.sh.default (keep this one in source control and people can modify it locally once for odd setups - called by
runAnt.bat ( does all of the stuff the bashrc does, but in the way only a batch file can. Ick! Used by those poor souls without Cygwin)
<SUBDIR build> - generated by ANT (compiled class files go in here)
<SUBDIR source> - holds all source code
<SUBDIR other...> any other subdirs you might need (resource, deploy, etc.)
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Most of the highly moderated comments have consisted of info about IDE's that are quite traditional: development is editing .java files. Visual Age for Java is significantly different. It is an incremental compiler which means that every change you make is immediately compiled when it is saved: you immediately know Everywhere you have made a mistake. As well, instead of working at a class level, you work at a method level. You edit methods not .java files. It has support for some basic refactorings.
The really amazing thing is the debugger: you can change the code while debugging! If you find a mistake, you don't need to stop the process, you just change the code, save, and continue. The debugger, appropriately unrolls the stack (and whatever else it needs to do), and continues as if the change you made had always been there. Talk about making the code-compile-run-debug cycle efficient!!!
IBM has a free trial download (its only a little crippled - limit of 700 classes). I strongly recommend trying it out. You have to work with it a little bit to see just how powerful these things are. I can't stand using anything else now. JBuilder sucks in comparison!
Helping with organizational effectiveness is our job.