Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
Java Programming IT Technology

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."
This discussion has been archived. No new comments can be posted.

Jedit, Jext & J: Java-based Editors Compared

Comments Filter:
  • jEdit rules! (Score:2, Interesting)

    I luve jEdit. When you get a set of plugins for it you really like, there's no beating it. of course... I haven't used one since i started using jEdit, so there may be something better these days.
  • What's wrong with good ole' (g)vim?
    • Re:gvim ? (Score:4, Informative)

      by KDan ( 90353 ) on Tuesday February 18, 2003 @03:23AM (#5324275) Homepage
      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
      • Re:gvim ? (Score:3, Informative)

        by Anonymous Coward
        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 [vim.org].
      • Re:gvim ? (Score:2, Redundant)

        by cyb97 ( 520582 )
        gvim exists for windows, and it's a native version... Works like charm no trouble to get it workin' either!
      • Re:gvim ? (Score:1, Interesting)

        by Anonymous Coward
        Vim runs fine on Windows.

        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.
    • I agree, vi is the only true editor!
  • by sosedada ( 97525 ) on Monday February 17, 2003 @10:22PM (#5323215) Homepage
    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.
    • edit was acting strangely as packaged in Mandrake 9.0

      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)

    by amorico ( 40859 ) on Monday February 17, 2003 @10:27PM (#5323238)
    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
    • by jilles ( 20976 ) on Tuesday February 18, 2003 @04:53AM (#5324488) Homepage
      You really should check out Jedit. It has plugins for all the things you mention and much more.

      To highlight a few things:
      • syntax colouring for at least 60 languages built in (could be more by now)
      • Plugin support for nearly every programming related task you can think of (debugging, style checking, refactoring (was not finished last time I checked)?, code completion, code fragment insertion, project management, catching output from console, testing, ant integration, ...).
      • Even without plugins it is still a good editor that can support various keybindings of other popular editors (vi and emacs I think)


      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.
    • by Mr.Ned ( 79679 ) on Tuesday February 18, 2003 @07:30AM (#5324888)
      For my meager and small perl programs, I've switched from vim to jEdit. Just a really nice program. Syntax highlighting is very good but not quite up to par with vim. Little things are still missing, like coloring newlines/tabs differently than text. Bracket auto-completion/auto-formatting that highlights which bracket is being closed lets me work more efficiently. There's a nifty collapsable blocks setting that will 'minimize' a block, enabling me to get a better overview of what is happening.

      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.
      • by Anonymous Coward
        > Little things are still missing, like coloring newlines/tabs differently than text.

        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.
    • by bwt ( 68845 )
      Eclipse and Netbeans make enterprise deployment, unit testing, and building a lot easier because they were created with that in mind.

      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).
      • You ignore those of us to whom the concepts a particular editor uses just come naturally and make sense. If I can moded text editing with vi key bindings that hook into the editors functionality and provide complete vi compatibility, I would care less what kind of editor I use. It simply wouldn't matter.

        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.
  • by dmorin ( 25609 ) <dmorin@gmail. c o m> on Monday February 17, 2003 @10:43PM (#5323303) Homepage Journal
    XML. I was never happy with the XML modes I could find for Emacs. And, as a Java geek, I'm doing alot with XML these days. So I decided to give JEdit a try when I heard that it had good plugin extendability. It's XML support is quite nice.

    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.

    • Most of Emacs code is written on Lisp (Well, Elisp). Most of lispers think that S-expressions are much better than XML-tags. Don't expect good XML support from people who hate XML.

      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.

  • by kruetz ( 642175 ) on Monday February 17, 2003 @10:47PM (#5323318) Journal
    Unfortunately, I dislike all three of the above editors in favour of JCreator [jcreator.com] - a Win32 IDE for Java. I KNOW this article is about editors for Linux, but hear me out on this one.

    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?

    • I have to agree with jcreator for Windows.

      For Linux/Solaris/*BSD I use gvim

      But under Windows its jcreator, its very lite and sits right on top of the DK
      • First feature from their site's "Features" section:
        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
    • I used JCreator for about 6 months. Even got work to chip in for a license (until I got laid off). I liked it, but I've been since forced to use eclipse 2.x, and I like it even better. Yeah, it lacks some things, btu now that I've got a faster computer and tons of memory, its not an issue.
    • You should give emacs a try. No, really.

      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.
  • You don't know jedit (Score:4, Informative)

    by xagon7 ( 530399 ) on Monday February 17, 2003 @10:57PM (#5323350)
    ...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!
  • The fact that we still use these beasts to develop software says a lot about our industry.
    • The fact that we still use these beasts to develop software says a lot about our industry

      You mean that software developers need to edit text?

      • Re:Text editors (Score:3, Interesting)

        by jilles ( 20976 )
        I'd have to agree. Using ascii to store highly complex structured information is rather foolish. It results in all sorts of problems with respect to consistency, correctness, etc.

        We have much better ways of storing and editing structured information these days.
        • Re:Text editors (Score:1, Insightful)

          by Anonymous Coward
          prove it. seriously... what is better? And why can't that better tool export it's data in text that can be edited, to have the best of all worlds? binary formats are opaque, I still think that's a bad thing in general, unless, of course, you need the increased efficiency of parserless loading.
        • I agree. I'm working on a new programming language with better-than-Eiffel contracts (preconditions, postconditions, etc.), and the plan is for it to store all code in a database with consistency triggers. Of course, that means it'll have to handle the loose equivalent of CVS/Bitkeeper-style revision control by itself, but that's doable.

    • What would you prefer?
      • Executable UML
        • Re:Text editors (Score:4, Insightful)

          by KnightStalker ( 1929 ) <map_sort_map@yahoo.com> on Monday February 17, 2003 @11:38PM (#5323539) Homepage
          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.

          And I think I'd rather use a text editor to type "for(int i=0; i<10; i++) { ... }" than drag a "Loop" module into my diagram and fill out a dialog box.
          • Sigh, you could have actually learnt what Executable UML is before you replied.
            • Ah... Fair enough. Didn't realize it was an actual thing... I thought it was just wishful thinking. :-)

              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 .... traditional programming. Something you'd perhaps use a text editor for. Perhaps you can enlighten me.

              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. :-)
              • As much as the Internet is a useful resource, knowledge is still best gained through the pages of a book. I would recommend Executable UML. A Foundation For Model-Driven Architecture by Stephen J. Mellor and Marc J. Balcer and Executable UML. How To Build Class Models by Leon Starr is also good.
        • by 0x0d0a ( 568518 ) on Tuesday February 18, 2003 @12:52AM (#5323791) Journal
          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.

          • 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 ... only your opinion, so there is a chance you learn and change your mind, I hope.


            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 ... sure there ARE compilers .. I've heared there are compilers :-) I even have used one ... and there are text editors ... fine.

            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 ... then you can use sed/perl or similar for scripting.

            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 .... seems you do not get the point aboput UML at all if you get down to things like EMACS.

            What is that "Thing" I described above? I mean, I used text .... so you surely know what it is and ... erm ... who it is?

            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 .... I'm pretty sure you are not even able to describe in TEXT what you are looking for in such a situation.

            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 ... instead of that you are still learing it(I hope at least you are not that ignorant to believe you can't learn any new thing anymore in your favorite language).

            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 ... if you would see the picture instead of the text you at least knew the former for sure :-)

            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 ... but that was guy who himself allready thought he was a UML expert, all other companies still hire me from time to time.
            • What is that "Thing" I described above? I mean, I used text .... so you surely know what it is and ... erm ... who it is?

              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... :-)
              • If you like to do it in pseudo UML, you need at least 4 boxes :-)

                And funny as it is, it indeed will look like a wall and a human than ... of course that part was intended as a joke, however.

                [Thing] -> [Head]
                |-> [Corpus]
                |-> [Leg]

                You have to connect Head with Corpus and Corpus with Leg as well, of course ...

                angel'o'sphere
            • YES, I'm an UML/OO Consultant. You can hire me for $1000 a day plus hotel and traveling.

              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.

            • 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;


              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 ... sure there ARE compilers .. I've heared there are compilers :-) I even have used one ... and there are text editors ... fine.

              *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? ...I'm not sure what you mean by "in any other format". "To any other format"...yes. I've used generated graphs to visualize control flow and interfile depdendencies, though it's true that I rarely translate text to a non-text format when developing. However, I don't see the problem there.

              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 ... then you can use sed/perl or similar for scripting.

              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 .... seems you do not get the point aboput UML at all if you get down to things like EMACS.

              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 .... I'm pretty sure you are not even able to describe in TEXT what you are looking for in such a situation.

              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 ... but that was guy who himself allready thought he was a UML expert, all other companies still hire me from time to time.

              *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.
  • I had been planning on writing an editor that did this, collapsing a section of code based on brackets or braces but jedit says it can do it. However in the few minutes I've spent trying I can't seem to make it work in 'explicit' mode but indent mode worked first try. Another feature I wanted to add to an editor is to hide all comments at once. I hate having to scroll up and down to find bits of code I am working with that are logically close to each other but separated by copious comments. I would probably document better if I could do this. Is there a plugin for jedit to do it?

    • 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.
      • 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. :)

    • I hide comments in Jedit with a sort of awkward use of the folding feature. I just indent the second through last lines of multi-line comments. That way I see only the first line of a comment, if I fold it up. Here's an unfolded sample:

      if (document.URL.indexOf("_FT")!=-1) {
      /* Comment:
      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) {
      /* Comment: [6 lines]
      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.
      • Folding, with brace-based folding coming in the next release

        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?

        • by ReinoutS ( 1919 )
          Last I heard, gcj / Classpath project didn't support Swing, so probably the answer is no. :)
      • 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.)


        What a weird concept, having to control the memory usage yourself. You'd think that they could automate that or something.
        • Garbage collection has been automated ever since Java 1.0 - but (in the traditional model at least) it only runs infrequently to avoid inconvenciencing the user. Clicking on the memory command allows you to invoke a garbage collection cycle is explicitly.

    • Another feature I wanted to add to an editor is to hide all comments at once. I hate having to scroll up and down to find bits of code I am working with that are logically close to each other but separated by copious comments.

      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.
  • Is it that bad that it doesn't even merit a mention? Why?

    I've only dabbled with Java, so I'm curious why Sun's own offering is so disparaged.
  • The whole idea of using an application-specific editor seems bizarre to me. I use emacs for just about all editing, and while I can understand not using emacs programs to replace *all* programs (mutt knocks the socks off of vm), it'd be a very difficult argument to say that one should give up all the incredibly powerful features and familiarity with one's normal editor to using an application-specific one.
  • My current employer has started switching all interface work from C and curses to Java and Swing. Most of our developers have Windows machines, and run VNC sessions on the Linux server where they do all their work. One bright spark decided to install Jedit, and his team all used it on the server ...

    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
    • It seems that your sysadmins need to get a clue. Don't blame their victims.

      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.
      • Indeed. And whether or not samba gets installed, the programmers can run jedit locally and use the FTP plugin to remotely edit the files. The FTP plugin is probably the one I use the most. The only disadvantage, really, is that if you are working on something like scripts you will have to chmod the files before you run them.
      • 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

    • by Anonymous Coward
      Maybe you guys should have run jEdit in server mode?
    • by greenrd ( 47933 )
      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.

      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.

  • by n3bulous ( 72591 ) on Tuesday February 18, 2003 @09:49AM (#5325743)
    Fortunately, the Verdana font looks fine in Jext without anti-aliasing, so that's what I use

    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.
    • I use a font called ProFont. It's fixed width, very clear at small sizes, and has great differentiation between l and 1 and 0 and O. Also, the punctuation seems larger and more distinct. It's not the prettiest thing, but it makes coding much easier. You can find it for Win, Mac, Linux, or Atari!?! here. [tobias-jung.de]
  • I tried it out and was really impressed with it. I started using it for Java stuff, but now I really like it for Perl as well.

    http://www.activestate.com/Products/Komodo/
  • Joe was one of my very first text editors on any Unix box.

    I love it. why didn't it get reviewed?
  • Printing (at least on windows) is kind of a pain:
    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)

    by zjbs14 ( 549864 )
    If you've got some money to spend, the best IDE for any language I've used it IntelliJ IDEA: http://www.intellij.com/idea/ [intellij.com]. After using it, nothing comes close.

    • Or CodeGuide from omnicore.com.

      Not related in any way to the company ... we only reside in the same town. And CodeGuide *IS COOL*.

      InelliJ IDEA, however, is also cool ...

      Check both if you are looking for an IDE with refactoring support.

      angel'o'sphere
      • by Anonymous Coward
        I used to be an emacs fan (I still like it), but IntelliJ just kicks ass for Java editing.

        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!"
  • 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?

  • by Trinition ( 114758 ) on Tuesday February 18, 2003 @09:06PM (#5331594) Homepage
    I've been using jEdit off and on for a year now, most recently very seriously. jEdit is still quite ugly in some areas, but quite nice in others: Nice:
    • 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 IDE
    • May I add that they've created an excellent "stand-alone syntax highlighting text editor JavaBean." (jedit-syntax at sourceforge)?

      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.
    • 100% Java

      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.
      • Let me educate you on Java. It runs on many popular platforms without modification. No need to track down an implementation of emacs, vi, whatever for your platform. Run Linux at home and Win32 at work? Us jEdit on both with the exact same settings!
  • Incidentally, anyone here knows of good detailed Java IDE comparison reviews?
  • When I compared the out-of-the-box Jext and Jedit about a year ago, I thought Jext easily won as a simple to use editor. The user interface of Jext is particularly strong, where-as the long menus and terminology of Jedit is confusing - I *never* heard of folding prior to Jedit.

    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.

  • 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.

On the eighth day, God created FORTRAN.

Working...