Jedit, Jext & J: Java-based Editors Compared 97
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."
jEdit rules! (Score:2, Interesting)
gvim ? (Score:1)
Re:gvim ? (Score:4, Informative)
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
Re:gvim ? (Score:3, Informative)
Re:gvim ? (Score:2, Redundant)
Re:gvim ? (Score:1, Interesting)
But even if it didn't, nobody who likes "vi" as much as most of its users do would settle for anything else.
I am making the bold assumption that JEdit and friends do not have a vi-like interface.
Re:gvim ? (Score:1)
A few comments about jedit (Score:5, Informative)
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.
Re:A few comments about jedit (Score:2)
I've read that the problem is that Mandrake uses lesstif and anything above version 0.93.18 doesn't really work with nedit. Haven't tested if this is true. You could also download statically linked version from nedit.org [nedit.org].
i am not compelled (Score:5, Insightful)
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
Re:i am not compelled (Score:4, Informative)
To highlight a few things:
Understandably, people are biased against java client software. However, Jedit is worth the 10 seconds it takes to launch it. Aside from emacs, I don't think there are many editors which are that extensible and have that many extensions.
Re:i am not compelled (Score:4, Informative)
jEdit also has a plugin-architecture with quite a library of plugins, including a mini-console, CVS integration, save over FTP, and a slew of Java-centric ones that look as though they would be useful.
In short, jEdit isn't an IDE but it will help you out in terms of "CVS integration, code style enforcement, and automation of repetitive build tasks." And it's not just for Java.
Re:i am not compelled (Score:3, Informative)
Get the WhiteSpace plugin through the plugin manager. It lets you pick separate colors for spaces, tabs, other whitespace, space from folds, and paragraph separators.
Re:i am not compelled (Score:3, Insightful)
jEdit has plugins that do just about anything you might want in that area: CVS, jUnit, Ant, java parsing, coding standards, in-process compilation, XML parsing, XSLT transformations. It's "hypersearch" capabilities are the best I've seen.
You can script jEdit in Beanshell or Jython. The "Commando" feature is as amazing as it is hard to decribe (you define XML to present GUI wizards for launching commands).
I would use emacs or vi, whiach are FAR better than this j* stuff.
BS. I'm so tired of hearing how great emacs and vi are. Both SUCK. Both have a completely unacceptable learning curve and are examples of the kinds of of arcane user interfaces that should be *ridiculed*, not advocated. Many people making fun of MS for clicking "Start" to shutdown had to hit shift-ZZ to save their file. And that's as console applications.
Hello, it's time to get with-it and edit text in a GUI. And don't talk to me about "when I telnet into a box I can't use a GUI". Freaking learn the -X option on ssh or better yet, use an editor that supports remote editing. And don't talk to me about gvim.
People that like them have some kind of desparate psychological need to justify the endless hours of torment they spent years ago learning them. To these people I suggest using jEdit in VI key-binding mode (oh, and pocket protectors are no longer in style).
Re:i am not compelled (Score:1)
For me, vi will always be the way because I can accomplish anything I need to do in the editor without touching the mouse or auxiliary keys on the keyboard. My hands mostly never leave the home rows. Heck you can even use ctrl-[ for escape and avoid that reach.
These editors of today with their slick GUIs and syntax completion are nice and all, but what frickin' good is it if it reduces your ability to produce by 1/3 or more? Most times I am faster just typing everything out.
I do realize I'm an exception - I type >100wpm, something most people don't. I learned vi young, and use it frequently. If you can internalize its usage, it is MUCH faster than using anything where you must take your hands off the keyboard at routine intervals to go hit arrow keys or use the mouse.
Why I gave up Emacs... (Score:4, Interesting)
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.
Re:Why I gave up Emacs... (Score:2)
With all my love to Emacs (I use it for both program coding and system administration), I also gave up on Emacs XML-mode. Recently I've tried Eclipse as well as some other (smaller) editors. But all time I come back to Emacs again and again - Emacs environment in general is too attractive, if not addictive. I just edit XML as a regular (plain) text file. Otherwise it complains all time about DTD (the stupid assumption that there cannot be XML file without DTD). Perhaps I should write my own XML mode at some day :)
By the way, HTML mode in Emacs is just perfect.
Re:the best of Java for Linux ? (Score:1)
If you avoid bloated things like Swing in Java you will do fine.
And platform independence has been getting a lot better over the past few years
Re:the best of Java for Linux ? (Score:4, Informative)
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.
Windows has better editors/IDEs (Score:5, Interesting)
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?
Re:Windows has better editors/IDEs (Score:1)
For Linux/Solaris/*BSD I use gvim
But under Windows its jcreator, its very lite and sits right on top of the DK
Re:Windows has better editors/IDEs (Score:2, Insightful)
Selection margin with line numbers. JCreator gives you the option of viewing line numbers in the selection margin.
When the feature list starts with this, I start to get worried. Looking at the rest I see that was justified. There is no mention of refactoring tools, and though of course I can't really comment since I haven't used JCreator, from the feature list it seems very similar to Gel [gexperts.com], which is also free and windows-only.
The idea of an IDE is not just a nice Java-oriented editor. You're right to switch from vi to JCreator and not to Eclipse or NetBeans, cause those are far more than editors. I hate the way Eclipse is so slow and unresponsive compared to my good old KDE apps, but "as-you-write" compilation, the refactoring tools, JUnit tests integration, seamless and easy integration of jars for code-completion even if you don't have their sources, etc... all these make IDE's come out miles ahead of straight editors or "editors+IDE-like-frills".
I'm just waiting for the time when I have a faster computer so that Eclipse runs a bit more smoothly (P3 550 sucks), but I've tried many other methods and proper IDEs are definitely tops.
Daniel
Re:Windows has better editors/IDEs (Score:2)
Re:Windows has better editors/IDEs (Score:1)
Emacs is small, fast, extensable, easy to use, efficient, and runs on both Linux and Windows.
It is basicaly everything you said you want. It beats the socks off Visual Studio, or can be made to emulate it. Your pick. Once you learn emacs, you will constantly become more productive as you tweak it and learn new little corners you never knew about before. The motto of every emacs user:
"I have used emacs for many years, but have not yet reached its full potential".
On the other hand, emacs is very simple for the new user. You don't have to know anything fancy at first. Just learn a few simple commands from the built-in tutorial, and you'll be on your way. Pick up new tricks as you go along.
Emacs is everything you want in an IDE.
Re:Windows has better editors/IDEs (Score:2)
Speak for yourself, emacs is definitely not what I want in an IDE
You don't know jedit (Score:4, Informative)
Text editors (Score:2)
Re:Text editors (Score:2, Funny)
You mean that software developers need to edit text?
Re:Text editors (Score:3, Interesting)
We have much better ways of storing and editing structured information these days.
Re:Text editors (Score:1, Insightful)
Re:Text editors (Score:2)
Re:Text editors (Score:2)
Re:Text editors (Score:2)
Re:Text editors (Score:4, Insightful)
And I think I'd rather use a text editor to type "for(int i=0; i<10; i++) {
Re:Text editors (Score:1)
Re:Text editors (Score:2)
But in the first two pages of Google results for "Executable UML", I can find no concrete information about it. Lots of claims of "100% code generation" and that sort of thing, but very little that says how you actually define your UML-described behaviors, though there are lots of books, and lots of products for sale.
The best I can find is a quick reference in a PDF to a "set of archetypes" and this: "you'll use a CASE tool to develop detailed UML diagrams, and then supplement them with specifications written in a formal language." (Google cache [216.239.37.100]) That sounds a lot like
Come to think of it, this is a lot like the results I got searching for a completely different software engineering fad, Aspect Oriented Programming. Of course that had an entire issue of the Communications of the ACM filled with claims and no actual demonstrations.
Re:Text editors (Score:2)
So what's wrong with text? (Score:4, Interesting)
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.
Re:So what's wrong with text? (Score:2)
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.
Hm
Third, text is well understood by now.
Ok, lets try it:
define Thing:
Leg left = new Leg(length=0.85m);
Leg righ = new Leg(length=0.85m);
Corpus corpus = new Corpus(weight = 55kg);
Head head = new Head(haircolor = new Color(red));
end;
Text is stored in a standard format, and there are extremely powerful tools available to process it.
Could you name one tool?
I mean
But can you transform any text in any other format? Just simply with some easy scripting?
E.g., can YOU, not some hypotetical person, transform a C program into a Java program, with a tool, of course? In a reasonable amount of time?
Nope you cant. You need to write a compiler like tool for every sinlge transformation problem you may think off.
You can only ease that burden if you add your own coding style on top of the language structure you use
E.G. opening and closing braces allways on one single line
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.
Oops, since when? Ever heared about internationalisation? Ever had a problem with attachments, uuencode, uudecode, splitting or concatanation? Or simply end of line styles? Ever used text mode accidently by a binary ftp download?
Hm
What is that "Thing" I described above? I mean, I used text
No? Why not?
Simple: a picture says more than 1000 words. I'm pretty sure you realize the perfect mating partner in a fraction of a second by a simple look. He/she just looks perfect
The human mind can understand graphics/pictures/diagramms 10 to 100 times faster than text.
And you can express everything you express with programming languages with graphics at least 3 times faster.
Unfortunatly "writing programs" in UML needs as much practice as writing porgrams in C. You did not learn your favorite programming language in a year
What I want to say is: use UML for a year. With the same enthusiasm you learned your most favorite language. As long as you did not do that you are simply not qualifying to give a statement about UML.
BTW: I let it open if the above 'code' is a human, a male, a female, a robot or my girfriend
angel'o'sphere
P.S. before the anonymous coward who allways answers to my UML/OO posts is encouraged again: YES, I'm an UML/OO Consultant. You can hire me for $1000 a day plus hotel and traveling. In the last 4 years only one person(company) was not pleased with my job conduction
Re:So what's wrong with text? (Score:2)
Let's look at that again, in pseudo-UML...
(Imagine this as a pretty box. This is the best I could do with the lameness filter.)
==========
Thing
==========
Leg left(length=0.85m)
Leg righ(length=0.85m)
Corpus corpus(weight = 55kg)
Head head(haircolor =red))
==========
Oh, yes, well *now* it's obvious what it is...
Re:So what's wrong with text? (Score:2)
And funny as it is, it indeed will look like a wall and a human than
[Thing] -> [Head]
|-> [Corpus]
|-> [Leg]
You have to connect Head with Corpus and Corpus with Leg as well, of course
angel'o'sphere
Re:So what's wrong with text? (Score:2)
Well at least I now know why you bothered to reply. KnightStalker is clearly an undereducated perl hacker who has never had the joy of picking up someone else's code or thought about the long term effects of writing reams and reams of source code that he figures will be stop being used before the end of his lifetime (but actually will probably outlive the companies that made the machines that it was written for). So why bother talking to him? If he was truely interested in what I had to say he would have took the hint I gave him and gone and learnt something about it before he exposed his ignorance.
What you say about pictures is reasonable, but what I think is more important is that UML is a way of representing models. Whenever you read or write software (that textual format stuff you talked about), you buy a model of what the software does in your head. Often you don't build the right model or you revise that model a dozen times as you experience more of the software. Communicating your model of the software to someone else is next to impossible because it is not formalized and communicating with someone about the software is difficult because you both probably don't have the same model of the software in mind. So why the heck don't people document the model before they write the software? Because it's pointless 99% of the time. The source code you write is no better represented by the formal model you constructed than it is represented by the mental model. This is because source code causes software models to drift into implementation details. What we need is a system of transforming the model into the software (note: not the source code, the software) and stop people from building incorrect mental models. Then maybe we can get the job done.
Text is fun (Score:2)
Leg left = new Leg(length=0.85m);
Leg righ = new Leg(length=0.85m);
Corpus corpus = new Corpus(weight = 55kg);
Head head = new Head(haircolor = new Color(red));
end;
I don't see how this relates to text being well understood or not. I was referring to how people have good tools for looking through and processing text (like the UNIX text utils and perl and emacs), and there's broad familiarity with how to deal with problems that come up. There is broad support for it. Moving to UML (which, incidently, *still* does not have a universal interchange format, despite attempts) doesn't help at all on at least that front.
Could you name one tool?
grep. I'd go bonkers without it when doing development.
I mean
*shrug* I wasn't really referring to compilers, though there seem to be more implementations for any given language than there are for EUML -- that isn't really an issue, as long as the EUML implementations are good. The problem is with the transformation and analysis stuff.
But can you transform any text in any other format? Just simply with some easy scripting?
As for "easy scripting"...I think your terms are a bit loaded here. Scripting is, well, pretty powerful.
E.g., can YOU, not some hypotetical person, transform a C program into a Java program, with a tool, of course? In a reasonable amount of time?
Well...technically yes, using a VM, but I suppose the answer you're probably looking for is no. I'd ask...why would I want to do so, and why would EUML offer me anything in this field that an equivalently high-level text-based language could not?
Nope you cant. You need to write a compiler like tool for every sinlge transformation problem you may think off.
For C and Java, perhaps. C and Java are rather different from EUML or a very high level text-based language -- they're a real-world, here *now* (not in ten years when compilers get smart enough to make their use viable).
You can only ease that burden if you add your own coding style on top of the language structure you use
Oh, I see what you're saying. No -- I can just ram the thing through indent or another source code formatter.
Oops, since when?
Uh....the introduction of ASCII?
Ever heared about internationalisation?
Yup. Ever heard of all the software written in text-based languages that provides internationalization support?
Ever had a problem with attachments, uuencode, uudecode, splitting or concatanation?
Umm...not that I really remember. How is uuencoding going to be less of an issue for a non text-based language? The only way I can see it being relevant is if you're talking about encoding source, in which case (a) ASCII is 7-bit clean and all the programming languages I use are ASCII-based, (b) EUML, which could be stored in God-knows-what binary format, *is* going to run into uuencoding problems. As for splitting or concatanation, I don't see why there would be any more or less problems for ASCII than binary files.
Or simply end of line styles?
My dev tools and editors seem pretty happy with both CRLF and LF, though I haven't tried crossing over to a Mac.
I really think that data interchange is more of an issue with UML than ASCII.
Ever used text mode accidently by a binary ftp download?
Christ, the last time I manually specified ascii or binary for ftp transfers was, I think, on an ancient VAX.
Hm
I must not.
Simple: a picture says more than 1000 words.
Well...a picture *can* have more content than a thousand words. But in the case of UML diagrams, there's hardly a pixel's worth of entropy per pixel. I don't stare at raw bitmaps to get an idea of what's going on.
Plus, as I pointed out earlier, there *are* times when it's convenient to graphically visualize parts of a software package. Text can be transformed into a picture for that brief visualization quite easily, though as I've said, I've only needed to do so a handful of times.
I'm pretty sure you realize the perfect mating partner in a fraction of a second by a simple look. He/she just looks perfect
Sure -- but that's an area where the end data *is* stored and processed in essentially a visual format. If I want to deal with *images*, it's frusterating to transform images into text, and then back into images again. Code, however, is not natively an image.
The human mind can understand graphics/pictures/diagramms 10 to 100 times faster than text.
That's a ridiculous statement. There's no kind of reasonable metric that you can use to make a claim like that. If I want to convey what a river looks like from above, sure, it's a lot faster to show an image. If I want to make an argument about languages (as I am now), then text is far more effective. It's why Slashdot doesn't consist of a series of little pictograms.
And you can express everything you express with programming languages with graphics at least 3 times faster.
Again, I claim that you cannot provide reasonable grounds for making such a broad and essentially meaningless claim.
Unfortunatly "writing programs" in UML needs as much practice as writing porgrams in C.
If EUML provides the level of detail necessary to fully generate machine code, that's one thing. I haven't used EUML. However, I can decidedly say that UML is nowhere near that level of detail. You can generate the structure of a program, but you have nowhere near enough data to "write a program" in UML.
What I want to say is: use UML for a year. With the same enthusiasm you learned your most favorite language. As long as you did not do that you are simply not qualifying to give a statement about UML.
That is ridiculous, and an argument from authority -- an attempt to avoid having to defend your claims. I cannot simply leave for a year, study UML, then return to the argument. Instead of saying "I am experienced with UML (or, in this case, EUML), and I say it should replace text-based languages, so that *must be the case*", you should say "I am experienced with UML (or, in this case, EUML), and I say it should replace text-based languages, and *this is why*". So far, you've taken a number of stabs at text-based languages, many of which are definitely wrong, and then made an argument from authority. That's hardly convincing.
Do I think UML is a useful tool? Yes, in some circumstances. It's the only standard way of graphically modeling OO program structure. That's reasonable. It might even be useful for generating skeletons to work with. However, I find major fault with a few of the things it lacks. It does *not* have a implemented-by-all interchange language -- I cannot swap data between Visio, Rational Rose, and Dia. In its attempts to be completely abstract, it takes a least-common-denominator approach, and throws out a few language features that *I* find very important -- there is no standard way to model a typedef, for example, even though just about every language I can think of supports something like aliasing or typedefing. Now, that doesn't make UML useless -- just has a few warts. It doesn't appeal much to me from my stint with it. Granted, some of that may be because the UML tools I used are very poorly designed, which is hardly UML's fault. Creating a UML diagram in Visio is a painstaking, carpal-tunnel-inducing series of opening and closing dialogs and flipping through tabs. Dia is somewhat better, but still not perfect. So perhaps I'm a bit biased by my tools.
However, I'm very much dubious when you claim that EUML is the future. You've taken two ideas, and interwoven them -- and yet I feel that the two are very different. First, that very high-level languages are the way of the future. I agree with you, though I don't find them currently viable for real-world use. Second, that UML (or this EUML thing) is an ideal base to provide said high-level functionality. *That* I do not agree with. I have a hard time thinking of benefits that a UML-based system would provide that a (high level -- not like Java or C) text-based system would not provide, and I can definitely see drawbacks to the UML-based system (not good tools to analyze UML code, much UML-related software is priced more highly than I feel that it's worth, graphs tend to break down sooner than text when you're working with very large scale systems, it's easier to change text-based systems (at least with the present interface in Visio and Dia)). I can see making a high level text system that can be converted to UML's semi-standard XML representation, but not just using UML alone. I like to write with the keyboard, not the mouse.
P.S. before the anonymous coward who allways answers to my UML/OO posts is encouraged again: YES, I'm an UML/OO Consultant. You can hire me for $1000 a day plus hotel and traveling. In the last 4 years only one person(company) was not pleased with my job conduction
*shrug* I don't have a problem with that. If you really feel that something is a good idea, then it would seem a bit hypocritical if you *avoided* working in the field -- I'd expect a Java fan to use Java.
I just have somewhat different feelings about whether next gen languages and compilers should use UML or a derivation thereof.
Folding in jEdit (Score:2)
Re:Folding in jEdit (Score:2)
I was skeptical of folding at first, but a little bit of exposure really convinced me. A great example of how to do it is the jEdit source code.
Your idea about a toggle for "hide all comments" seems like a great idea. I'm not aware of anything that does it know for jEdit, (but I could be wrong). Perhaps you should suggest it on the jEdit mailing list.
Re:Folding in jEdit (Score:2)
Perhaps you should suggest it on the jEdit mailing list.
I suppose I should, after all, ye must ask before ye can receive. But I am full of ideas and they would probably get tired of reading them all before I got tired of writing. :)
Re:Folding in jEdit (Score:1)
if (document.URL.indexOf("_FT")!=-1) {
Comment lines. This function saves the world.
Comment lines. This function saves the world.
Comment lines. This function saves the world.
Comment lines. This function saves the world.
Comment lines. This function saves the world.
*/
document.write('<img src="/images/shim.gif" width="13" border="0">')
}
When folded, it looks like this:
if (document.URL.indexOf("_FT")!=-1) {
document.write('<img src="/images/shim.gif" width="13" border="0">')
}
Note that Jedit puts the number of hidden lines in brackets at the end of the top of the folded section.
Other good things in Jedit are:
Hypersearch, which returns a clickable list of all the search hits in a file
Good auto-completion
Folding, with brace-based folding coming in the next release
Simple plug-in architecture
Basic project management
Very configurable
Integration with code management tools like CVS.
Faster to learn than Emacs. Didn't take any appreciable time to learn at all, actually. I just looked in the menus and was doing eighty percent of what I needed to do after twenty minutes. I had to look around longer for a few other things.
There are a lot of Emacs-style key commands, and they can be changed to your own preferences.
It does grab memory, but just click the memory command on the bottom right periodically and you can free up big chunks. (Insert your own joke about vomiting here.)
It is not the snappiest editor I've ever used, but it's plenty fast enough.
Finally, it is actively being worked on. What you see now is less than what will be available in a few months.
Re:Folding in jEdit (Score:2)
Sweet! I'll be waiting.
Hypersearch is very cool. :)
It is not the snappiest editor I've ever used, but it's plenty fast enough.
I wonder if anyone has compiled jedit with gcj?
gcj (Score:2)
Re:Folding in jEdit (Score:2)
What a weird concept, having to control the memory usage yourself. You'd think that they could automate that or something.
Re:Folding in jEdit (Score:2)
Re:Folding in jEdit (Score:2)
That would seem like it would be easy enough to implement. I could see that being useful if you do the javadoc style comments where you comment all the methods and such. You don't really need to see all of that while you are coding, you know (or should know) what your methods do.
forte / sun one studio (Score:2)
I've only dabbled with Java, so I'm curious why Sun's own offering is so disparaged.
forte is an IDE (Score:1)
forte is an IDE; probably, that's why it's not mentioned.
Application-specific editor? (Score:2)
Editors written in Java? (Score:2)
The result was that the main development server, a not inconsiderable machine, was brought to its knees. As a result the daft buggers have been ordered to use Nedit, unless they agree to replace Windows with Linux and run Jedit on their desktop machine.
None of them have elected to run Jedit locally, as Nedit is the dogs bollocks as a programming editor, regardless of the language.
Chris
Re:Editors written in Java? (Score:3, Informative)
Setup the server in such a way that client computers can easily access files on it (e.g. by running samba). Running stuff locally is almost always faster so there must be something preventing the developers from doing so effectively (I suspect an overzealous attitude towards windows clients). Remove that cause and your problems are gone.
The sysadmins are costing your company money at the moment because they prevent a development team from working with the tools they need in an effective way.
Re:Editors written in Java? (Score:1)
Re:Editors written in Java? (Score:2)
It seems that your sysadmins need to get a clue
And how do our sysadmins stop them installing a JAR file in their home directory (which is exactly what they did)?
Chris
Re:Editors written in Java? (Score:1, Informative)
Uh (Score:2)
What has Linux got to do with JEdit? Why the requirement to replace Windows with Linux? JEdit runs on Windows too - obviously, as it's a pure Java program.
Fonts for Programming (Score:3, Interesting)
Do people really use proportional fonts when writing code???? I use andale mono or Lucida Console, myself. I love that the code looks cool with proportional fonts, but nothing ever lines up properly.
Re:Fonts for Programming (Score:2)
I like Komodo (Score:1)
http://www.activestate.com/Products/Komodo/
What About Joe (Score:1)
I love it. why didn't it get reviewed?
JEdit rules... but (Score:1)
Some spaces in the printed files are eaten, which makes them barely readable...
If anyone know a solution to this, I'll take it, because I'm planning to use it for a PHP course I will give next month...
Quentin
IntelliJ IDEA (Score:2, Informative)
CodeGuide ... Re:IntelliJ IDEA (Score:1, Redundant)
Not related in any way to the company
InelliJ IDEA, however, is also cool
Check both if you are looking for an IDE with refactoring support.
angel'o'sphere
Re:CodeGuide ... Re:IntelliJ IDEA (Score:1, Informative)
Code folding
syntax hilighting and auto-suggests correction, extracts code into a method
inlines code
inspects for common errors (like public defintions that could be private)
integrated with JUnit
has an Ant integration
works as a debugger as well as an editor.
easily renamed variables, method, classes, etc.
Auto-generates accessor functions
live templates (type iteritervariable and it expands out a for loop for the interation)
and bunches more...
It seems like about once a week I run across a new feature and go "IntelliJ is just so freaking cool!"
I need vi keystrokes (Score:1)
It'd be nice to have all the features in these editors, but the one thing that puts me off is that I like the vi keystrokes. Does anyone make an IDE (not Emacs) that also has a mode where vi keystrokes are allowed?
jEdit is still rough around the edges (Score:3, Informative)
- 100% Java
- Nicely done Win32 laucnher
- Tons of plugins
- Nice and easy way to install/update plugins
- Concise, Java-based installer
- Configuration is extensive
Not so nice:- No javaWebStart link available
- Icons are ugly
- Toolbars/docking is very fixed and wasteful
- No hex editor! (not even a decet plugin)
- Configuration organized haphazardly
Disclaimer: I use jEdit as a text editor, not an IDERe:jEdit is still rough around the edges (Score:2, Insightful)
I wanted to add "scripting support" to my application, but I wanted to have syntax highlighting (so it looked more professional
I had to change 5 lines of my code and I had my syntax highlighting editor.
A really useful component and an excellent example of "component-based reuse".
P.S.: maybe it's just a bit off-topic, but since we're developers I guess it's still an useful info.
Re:jEdit is still rough around the edges (Score:2)
Why is that nice? Come to think of it, what's the whole point of this article anyway? Is using an editor written in Java just another bullet point to bolster your Javahippness? Does it earn you points at your local JUG meetings? "Oooh! Look at me, I'm using a Java text editor! Won't you congratulate me?"
Who give a fsck what language a text editor is written in? I hate lisp. Hate it with a passion. But I still use Emacs.
Re:jEdit is still rough around the edges (Score:1)
IDE comparisons? (Score:1)
Jext is great, but has lost momentum (Score:1)
As I saw it, Jext's advantages were:
-Extremely easy to use (compared to Jedit)
-Supports the idea of workspaces, which allows you to switch between projects w/o having to close all of the files or lose your place
-Uses a tabbed open file interface - Jedit offers this as a plugin, but its not as good as the 'native' feature in Jext (less intuitive)
Since then, Jext development has stalled somewhat. There have been some long-standing bugs (particularly in using plugins w/ Web Start), and Jedit has continued to add features. I would really like to see Jext development continue, fix some Web Start issues, and start adding some of the features of Jedit.
Conversely, Jedit could really improve by making the UI more approachable, taking some lessons from Jext. One suggestion for Jedit would be to limit menus - possibly allowing the interface to switch between different modes for different purposes.
Vim rules all the way! (Score:1)
For those of you who're going to read all these comments here and decide to move to some j* editor, hold on! Vim is still the best choice IMHO. It has Java syntax highlighting and with the help of JTags [fleiner.com] you can also navigate through the sources very easily. You'll miss the intellisense (or, really? [vim.org]) but there's a whole lot of common editor features that you simply can't find in other java-only editors.
I'm speaking from experience -- I worked on a java project for a year and was able to beat the shit out of any of my co-developers using jedit/textpad/jext/jblah. At the end of it, I had 3-4 vim converts in my team.
Lead by example.