Summary
Arguably the most important tool in a developer's
tool chest is the IDE they use -- if they can. In
this post, I talk about my favorite -- CodeGuide.
Advertisement
I've been a fan of the CodeGuide IDE for quite a
while (
http://www.omnicore.com). There's a lot to
like about it, including refactoring capabilities,
the ability to find all references to the thing you're
pointing at, and the ability to jump to where it's defined.
Then there is auto code-completion, and pop-ups that show
the available methods for an object, as well as the API
documentation for each one you're thinking about using.
I'm a big fan of their interface, as well. It's written
in Java, but looks (and runs) like a native application
-- at least on the Windows platform, where I use it.
That's because the interface runs on the Windows JVM,
which has native performance and graphic characteristics.
(At least on Windows. It's performance tends to be more like
the usual Java application on other platforms -- still an
important problem to solve for interactive programs, although
progress is definitely being made.)
But while the IDE runs on the Windows JVM, the application
you're creating can be developed using any version of Java
that you have installed. And that's where CodeGuide really
shines -- because its developers somehow manage to stay ahead
of the curve on each and every release of the Java platform.
They do that partly by sacrificing any pretensions to
doing visual, interactive GUI development. You can run your
program to try it out, but you won't be able to develop it
graphically as, say, a Visual Basic programmer would. I'll
describe a prospective solution for that problem in my next
post, but in the meantime, CodeGuide is superb for servlets,
JSP pages, and other non-interactive applications.
On the other hand, when I was using a graphic IDE (and
writing my first book on it), I found that I was always
"behind the curve". The IDE was invariably a major
revision behind the platform, which meant that I wasn't
able to explore or take advantage of the latest
innovations -- not a happy condition for a writer who's
supposed to be surfing the edge of the wave.
CodeGuide, on the other hand, has somehow managed to
support new features in the language even before
the beta version of the Java platform is released. Since
I started using it, I've never once been forced
to lag behind the curve, so I have the convenience of an
IDE, plus the ability to stay up to date. Heaven.
But perhaps my favorite reason for loving the CodeGuide
IDE is that the folks behind it really listen.
They engage in dialogue with developers, understand
what they're saying, implement solutions, and diligently
process the feedback they get on the results.
The result is an IDE that really works.
Recently, they've been improving their support for unit
testing (see my upcoming blogs and/or articles on the
subject). And coming down the pike relatively soon, they
are actually supporting a "back-in-time" debugger. In
other words, once you reach the point in the program
where you realize that things are broken, you can go back
in time to find out exactly where it broke -- instead
of starting the program over and over in an attempt to
catch it in the act.
The pre-release version of that program is available at
http://www.omnicore.com/index.jsp?page=htmls/newdebugger.html
And get this. Not only does it do back-in-time debugging,
it also does single-step expression evaluation. So you don't
have to edit the program to break expressions down into little
itty bitty pieces so you can find out which part is breaking.
CodeGuide has plenty more of features. I probably
haven't even mentioned some that I use every day. But
hopefully this post has given you enough to whet your
appetite. Then again, maybe it won't. That's ok, too
-- because I really like the fact that they always have
time to respond to my emails...
I wouldn't use any IDE that doesn't have these features. I've been using IntelliJ IDEA for the last year. I've tried JDeveloper, Eclipse and CodeGuide the last year and must say this one beats them all. The JUnit integration is great. The debugger has all your mentioned features including hot swapping classes while debugging. It would love to see a comparison between IDEA and CodeGuide. You can get an Early Access version here: http://www.intellij.net/eap/
I also have been using IDEA for a few months and I like it better than my previous IDE, JBuilder, because it's more intuitive and cleaner. JBuilder just feels clunky a lot of the time. IDEA also has the best refactoring tools I've seen. From what's written about CodeGuide above, I would say that any IDE should have at least those features, and IDEA has those and more.
Like the other posters, I've used IDEA and liked it a lot. It is also an IDE-without-the-graphical-form-builder. (I used to think that IDE meant a graphical form-builder plus fancy editor, as in VB, Delphi and the like, but now it seems to mean any souped-up and code aware editor).
I used JBuilder too, but could never get the hang of of the form-builder part. I've not seen any graphical form-building tools for Java that come close to the simplicity and ease-of-use of Visual Basic (which I used for a year or two, up until Delphi arrived on the scene), Delphi (which I used until C++ Builder arrived), C++ Builder, or Visual Studio .NET (which I'm using on a C# project now). Are there any good graphical RAD IDEs for Java?
Eric, a more couple questions for you: - Have you used IDEA? How would you compare it with CodeGuilde? - In writing your books, what writing tools did you use? Home made? FrameMaker? MS Word? vi? In particular, do you use any automation, such as some method for unit testing the code samples in the book and them automatically inserting them into the manuscript (or the reverse; extracting, then testing)?
Hey Joe, thanks for the tip, I'll check out that IDEA beta.
> Has anyone seen something like IDEA for C++ ?
At the JavaOne conference, I talked to someone from JetBrains who said they were working on other langauges, but they were a little secretive about it. They might be working on some .NET tools maybe. If so, I think it would support C# for sure and maybe managed C++ and VB.NET. If they supported the managed C++, it isn't too much of a stretch to imagine they'd also simply support C++.
Good summary. CodeGuide looks cheaper than IDEA which is a plus. (Too late for me though; I sprung for IDEA early this year). My problem with GUI form builders like JBuilder is that the generated code is invariably bad: unreadable, non-OO, non-thread safe. How many JBuilder-built GUIs have we seen hang because the developer didn't rewrite the action code to move it out of the Swing thread? And to build any complex GUI with a form-builder, you already have to know Swing well enough that you could do it (more easily?) by hand, and the form-builder still won't help you catch standard Swing gotchas (like trying to get the width of the widget before it's been displayed). Be interesting to see what IDEA 4.0 does with these problems.
Thanks for your comments, and the many others on this topic. IDEA clearly has a lot of momentum!
> - Have you used IDEA? How would you compare it with > CodeGuilde? > I took a look at it at JavaWorld a couple of years ago, and I *was* impressed with it. It clearly had more features, integrated with more tools, and had a wider range of refactoring capabilities.
But besides the price point, CodeGuide won out (for me) for fairly emotional reasons: a) Responsiveness They listen hard, explain patiently, and implement suggestions.
b) Growth They keep improving by leaps and bounds from release to release. (I figured they would catch up with IDEA eventually, because it's hard to add more functionality, after a certain level.)
c) General interface design Crisp graphics, a more visible wavy red underline for syntax errors, and what seemed like cleaner menus and interface design (which is easier when you have fewer features -- but I figured that when they *did* catch up, they'd still have the great interface to go with the functionality.
Admittedly, these are very subjective reactions. If I went for a straight "bottom-line" assessment -- especially in a group development scenario -- I might opt for IDEA. But I think CodeGuide is pretty undersung, so I decided to pipe up.
> - In writing your books, what writing tools did you use? > Home made? FrameMaker? MS Word? vi? > These days, I mostly write in DreamWeaver, although I also use FrameMaker. The latter has great indexing, cross-referencing, and PDF generation. But only single-level undo and an interface I don't really like. DreamWeaver has a really good interface, but it's quirky in many respects. (Type newline and nothing happens -- until you type a character, when the new element appears). But even though it's not good for books, I like authoring in it better than anything else I've used.
Of course, what I *really* want is a wyswig XML editor that uses an XML->Xhtml "translation key" instead of a stylesheet, and which can do outline-oriented display and manipulation, like JOE -- but it looks like it will be quite a while before I can find that (and it's pretty big to build).
> In particular, do you use any automation, such as some > method for unit testing the code samples in the book and > them automatically inserting them into the manuscript (or > the reverse; extracting, then testing)? > Ah. In development, I use JUnit for unit testing. In writing, I created a filter program that processes source code in an XML file that uses process instructions to say "add this in version X" or "remove this in version Y".
I then run the filter twice -- once to produce a .java file containing version X of the program, and one to produce an HTML fragment that highlights the added/removed code using bold/strikethrough.
That way, when I'm working on version 5 of the program, and realize that implementing version 1 somewhat differently would greatly simplify the process, I can make the change one place and have all 5 versions automatically reflect the change.
(Thanks for asking about that -- I plan to post it as a "cool tool" one of these days, when I get around to writing up a description of how it works.)
One thing I haven't done yet, but need to, is to add unit testing to that mix, so I can verify that the sample programs behave the same when a new version comes out. (At the moment, I do manual verification because it only happens every so often. If I were doing slightly more often, I would hasten to automate the task for the sake of productivity (and general laziness).
> I've been a fan of the CodeGuide IDE for quite a > while (<a href="http://www.omnicore.com"> > http://www.omnicore.com</a>). There's a lot to > like about it, including refactoring capabilities, > the ability to find all references to the thing you're > pointing at, and the ability to jump to where it's > defined.
Unfortunately, CodeGuide appears to make the same mistake as eclipse and completely ignores the package statement in the source file. The language spec is quite specific about that statement telling the compiler what package to place the class into. Unfortunately, CodeGuide appears to think that the directory where the source file resides is somehow indicative of the package. The language spec makes no such statement. It says that the environment that the compiler is used in may look for source files in different places such as a database. And that the output .class files or other representation of the compilation output needs to be represented in a way that provides package distinction of same named classes in different packages.
I find this to be a really annoying trend in IDEs. Ignoring the package statement is not a valid implementation per language spec...
> Unfortunately, CodeGuide ... > completely ignores the package statement in > the source file. .... CodeGuide appears to > think that the directory where the source file resides is > somehow indicative of the package. > Interesting. I've used it on several medium-scale projects and never noticed a problem. That sounds like a bug, but it's never bitten me. Send them a note on it. They do listen.
> > Unfortunately, CodeGuide ... > > completely ignores the package statement in > > the source file. .... CodeGuide appears to > > think that the directory where the source file resides > is > > somehow indicative of the package. > > > Interesting. I've used it on several medium-scale projects > and never noticed a problem. That sounds like a bug, but > it's never bitten me. Send them a note on it. They do > listen.
It's no bug, just someone who's frustrated about IDEs not having complete support for database-based codebases... Java DOES specify that a package==a directory (though the JLS doesn't state that that directory must be placed on the filesystem).
Hi ! I just downloaded the CodeGuide 7 IDE, its GR8.... Just have a question regarding it, How can u change the path of the output class files when rebuilding the project ?? Currently it places all the class files in the same directory as my source, i.e all my java source files and class files are together...
Also it does not seem to have a Collapse Function option, seems like a very basic feature
Previous Topic
