Slashdot Mirror
Jedit, Jext & J: Java-based Editors Compared
An anonymous reader writes "There are times when I want a lean, mean editor and times when I enjoy a good, bloated editor packed with wizards. We compare the programming editors Jext and J to Jedit and offer a revised opinion of the best Java for Linux."
I was reluctant to try out a java based editor (I'm a C++-er all the way :), but nedit was acting strangely as packaged in Mandrake 9.0, so I gave it a shot.
I really like the hyper-searching and the tabbed windows. There are a few annoyances such as the order it uses when you switch to the next buffer (uses opened order rather than Z order), but my main complaint lately has been speed. It has become quite a hog, probably due to too many cool plugins. I'm using the latest java from Sun. Perhaps I'll try one mentioned in the article.
All in all, I've been using it for about a month and I don't think I'll give it up.
Summary:
J: interesting and--Oh look! shiny php object!
Jext: tricky installation, but nothing interesting in the five seconds I spent reviewing it.
jEdit: reviewer liked this one the most, but was biased from the beginning.
Whatever. Why waste the time to even write a review if you are not even going to take the time to go into depth? The reviewer complains about bloated IDEs like eclipse or netbeans and then does not even point out why ANY of the reviewed editors are a compelling choice over an IDE. Eclipse and Netbeans make enterprise deployment, unit testing, and building a lot easier because they were created with that in mind. They only implement editing functions to the extent that they support iterative development cycles and integration with software engineering tools. Do the editors support automatic code copmletion based on classpath and in-scope variables? If I wanted souped up text editor I would use emacs or vi, whiach are FAR better than this j* stuff. An editor is great when you are developing alone, but when you are part of a team of developers, things like CVS integration, code style enforcement, and automation of repetitive build tasks are essential. How do any of these editors fare in that respect? You'll never find out in this review.
-a
"The plural of anecdote is not data." -- Roger Brinner
But! That's the only reason I use it. When I need to write Java code I still go with Emacs and the JDEE package from Paul Kinnucan which gives me everythign IDE-like I could ever want.
www.HearMySoulSpeak.com
JCreator is small, fast and has all I want in an IDE. It is written in C++ and behaves very much like VisualStudio, which is great if you're a windows programmer. Personally, I run dual boot CRUX 1.0/WinXP and if I'm gonna write a good amount of Java code, I choose XP and JCreator, because JCreator feels so much faster than any Java-written IDE/Editor. JCreator is freeware (there is a Pro version for as little as US$35) and I'd love to see a Linux version - I have emailed them about it and it's not gonna happen anytime soon. Damn.
But anyway, there is a big difference between JCreator and Java editors for Linux. I'd like to see a JCreator-like project at SourceForge or something, because I'd definitely use it. (I'm not gonna contribute myself - I'm already working 60+ hrs a week). Does anyone else feel the same way?
This sig intentionally left bla... dammit!
Who's got the whiteout?
...there are NUMEROUS plug-ins for ANT, JUnit console, editing macros, and even EMACS emulation. YOU should know what your are talking about before you open your fingers. JEdit is well one its way to being a fantastic programmers editor. The editor is EXACTLY the same on a MAC, Linux box (any type), or Windows. Just get the latest version and try for your self. It is especially snappy with the 1.4_01 jvm, and go to the plug-in manager and BAM, tons of stuff. Have fun!
Hm. You can draw pretty lines in UML all day long, but at some point the behavior that UML is representing has to get turned into ones and zeros that your processor can execute. Even if you have large libraries of predefined modules, you still will not have any sort of flexibility -- unless you whittle those libraries down to the level of source code.
... }" than drag a "Loop" module into my diagram and fill out a dialog box.
And I think I'd rather use a text editor to type "for(int i=0; i<10; i++) {
* And remember, it's spelled N-e-t-s-c-a-p-e, but it's pronounced "Mozilla."
Okay, I had to look this one up. It seems that EUML is pretty much what it sounds like -- some companies trying to build a really high level language -- fine, that I'll understand -- using UML, which comes off as a bad idea. Frankly, the whole thing smacks of a "solution without a problem" being aimed at corporate purchasers who think "UML == good, so EUML == good".
First, I'm not a tremendous fan of UML. While the next generation of languages may hit within a decade, I'm not holding my breath, and I rather doubt that they'll be based on UML.
Second of all, I don't see why you dislike text so much. You can have the benefits of EUML without going to some mouse-based development environment. A text-based system would work fine as well.
Third, text is well understood by now. Text is stored in a standard format, and there are extremely powerful tools available to process it. Furthermore, it survives interchange fairly well, deals well with different output devices, and can be printed easily. There are a number of excellent, extensible text processing systems like emacs.
May we never see th
It's not java based, so you either have to go through no end of hassle to make it work on your windows box, or get used to "one editor for *nix, one editor for *blows".
JEdit, on the other hand, runs fine and exactly identically on both linux and winblows. No need to get used to having one set of feature under one OS and another under the other.
Daniel
Carpe Diem
Ummm, you can get Vim for Win32. I use it all the time just as in Linux. It's not a cygwin port, either, it's a legitimate Windows program. See here.
A 'Hello World' applet run using appletviewer. Ok cpu usage is at 0.0% which is to be expected since the applet doesn't do anything once it's painted the display, but look at RSIZE. 13.4M.
Yeah, that's the VM overhead, so?
And you can expect that number to blow out pretty quickly as the code is extended to make it do something useful.
I assume that adding features in your favorite language actually causes memory use to shrink?
Hello World in C has a resident size of 304K. Granted that's just using printf to output to a console but it's still a dramatic difference.
Actually, 304K seems like a hell of a lot of memory to lose for a Hello World in C.