Ask HN: Reasonable Java editor for heavily CLI-oriented UNIX types who hate bloat?

Anybody who writes java code in anything outside of Eclipse, NetBeans or IntelliJ is wasting their time. It doesn't take an enormous amount of time to learn how to use Eclipse. It probably takes 15 minutes of someone showing you the ropes. You need to stop thinking of the problem as "I need a text editor" because that's almost certainly not what you need.

Eclipse in particular does nothing like what you claim ("unnecessary metadata and internal abstractions") except one or two files in the root of your project's directory tree. Upgrading your machines to support Eclipse means at worst spending $20 to buy 2Gb more memory, which doesn't seem like a lot to me.

All of the requirements you mention (plus a lot more) are available today in Eclipse. And you don't want Eclipse because of a few poorly defended misconceptions that you are clinging to. Go back and give this a second look and get someone to show you the ropes with it over lunch. You will never look back.

I have personally converted two people like you: die-hard emacs users who will never use an IDE because you tried them ten years ago and they sucked then. Neither of these two fellows would ever go back to that world now that they know what they're doing.

You won't regret the few minutes it takes to learn basics.

I have to second this. If you are building anything more complex than a very simple project, and you are not using one of the three (Eclipse, Netbeans, Intellij) -- you are wasting a lot of your time. They are not hard to learn.

The stuff you lose in a simple text editor: refactoring support, integration with version control, code-complete, debugging...etc.

I'm simply going to guess based on your post that you also don't know much about the java open-source community. It is giant, diverse, and fantastic. Everything you need is out there. Before you write it yourself -- poke around on Google and no doubt you'll find something that already does what you need.

I personally hate Ant builds. I think Ant can be done right -- but every place I've seen it used it just gets hacked, and the builds are a nightmare. This is why I prefer Maven b/c it constrains the build to a standard layout and there are a gazillion plugins to do everything you need.

The only problem of course is that when your "more complex than a very simple project" hits the size where Eclipse just can't take it any more. A project I'm working on is pretty much at that scale, and random things basically stop working if I so much as stop looking at them. Its quite amazing.

I've heard from coworkers that IntelliJ could handle it, but at the cost of agonizing slowness. So now I fire up eclipse (and reset all my project options and input from scratch) only when I need refactoring, and use emacs otherwise. Its not great, but at least I don't swear all day long.

What size projects are you using?

> So now I fire up eclipse (and reset all my project options and input from scratch) only when I need refactoring

That seems a pretty sensible approach in any case. Emacs is just a nicer environment to live in for day to day editing.

All right. So, what if I have an existing project I want to import into Eclipse and not have it lay its workspace droppings all over it? Can I do that and leave the actual source tree relatively untouched? What happens when I want to export it out of the workspace back into the external form the tree took before?

Yes. Eclipse can be flexible with where the source folders are, where your libraries are coming from, etc. You'll (usually) only have two metadata files: a .classpath and a .project, and occasionally, a .settings folder (for any per-project settings you might change such as compiler warnings, etc.)

Otherwise, you can leave your structure intact and unchanged.

How do I export the project back out to its original form once I imported it into the workspace? Or is it safe to just copy the stuff out of my workspace folder?

First of all: you are using version control, right? Please tell me yes.

Eclipse isn't going to "change" your code at all. It'll put two or three files and dirs in the root of your project. That's it. Your code is the same as it was before.

Yep, using SVN. Not sure I want Eclipse to ride it, though.

If you move a class to another package in Eclipse (using drag&drop), it will automatically issue the necessary svn move command, and synch up the import statements everywhere. That's a 20 minute job done in 2 seconds.

Eclipse won't change your file/folder structure (unless you tell it to).

In fact, you can have source code somewhere outside of your "workspace" and just point Eclipse to it, there is no requirement for the code to be inside the "workspace".

I'm guessing that's done by some method other than the "Import" facility...?

Import will just tell Eclipse where the code is located, not actually copy it into the workspace. Import is probably what you want.

You mention Vi, but as an Emacs user one of the things that eased the transition to Eclipse for me was a setting that enabled all of the commands I already knew (google emacs mode). Also Eclipse has a great set of keyboard shortcuts to do everything, I normally do my whole workflow without the mouse being on my desk.

For Java work an IDE is essential. For C/C++ I still use Emacs but having Javadocs integrated right there and a nice debugger and refactoring is key.

You might also be interested in this: http://community.buglabs.net/kgilmer/posts/114-Getting-the-f...

Eclipse's emacs mode is nothing like Emacs. For example, it binds undo to F9, leaving C-/ (the emacs binding for undo) as "comment this line". WTF. Of course, once you fix the bindings, Eclipse's undo doesn't work anything like Emacs' undo. It's not Emacs, it's Eclipse with C-a (but not M-n) and C-e.

I'm the complete opposite of the OP. My intro CS courses were taught using Eclipse, and I am constantly using it (for lack of a better, free, option) at work. I am getting more and more fed up with the bloat in Eclipse. Running in a Linux environment results in hard-to-diagnose crashes fairly often, and the memory overhead is, quite frankly, unacceptable.

I would gladly move to something lightweight like the OP asked for. Most of the features in Eclipse aren't useful to people working on relatively small projects, and the features that are useful (code completion, refactoring, nice library integrations) could probably be deployed with much less overhead.

At my company, we've had people use it on WinXP, Vista, OS/X and Linux. Nobody ever suffered from crashes. There are a few different flavors of Eclipse and it sounds like you were using the kitchen sink version. There's a smaller one which everybody I know seems to use that may be worth checking out.

That's what I'm saying.

Note that the argument isn't that Eclipse [1] is perfect, but that Java without Eclipse is impractical.

[1] Or some other rich IDE.

I agree 100%. On java projects, I don't consider myself a "java developer" because frankly, writing java in unsupported editors is a pain in the ass. I couldn't imagine writing java code with Eclipse. It would be an order of magnitude less efficient.

I have to second whirly's opinion. When you are writing some rather complex java, eclipse gives you the following:

- Enforce code style (eg: checkstyle plugin) and source formatting rules - Project Management - Java code autocompletion (works perfectly like 99% of the time) - XML autocompletion through dtd - With some plugins you get autocompletion for jsp, etc - Hard-Core refactoring (you've got an example from another guy) - VCS integration (git, mercurial, svn, even vss, you name it) - I tend to prefer to use git or mercurial from the commandline, but eclipse has a nice merge editor and it lets me compare 2 commits very very easily. The Hg plugin even shows a tree graph with the commit tree - And lots of lots of plugins (the mylyn and jira/bugzilla/trac connectors are really nice for example)

My main argument is that it's so much easier to inspect for example a class in a jar library and see the methods it implements within eclipse/intellij/netbeans than with any other plain text editor. Eclipse even lets you see the javadoc for the class.

I just installed Eclipse, and in the workspace directory, it created a ".metadata" directory, containing 9.2M. Most of it is here (output from du -h):

    8.8M    ./.metadata/.plugins/org.eclipse.jdt.core

Unfortunately, finger memory takes a lot longer to retrain than 15 minutes of learning the basic basics - it's more similar to retraining from guitar to piano. But truly, it's just a matter of time.

I would love to have automatic refactoring tools, but they often don't do quite what I specifically need (and I don't need to do it often enough to become practiced with what the tool can do.) Last time I needed a lot of boilerplate, I wrote a quick script to do code generation for me. I very rarely need it, but it was a guilty pleasure to write the tool.

The other thing I like about Eclipse is that javac is always already loaded, so you don't have that 2-3 second start-up delay. So... I wrote a little javac server - javac is sitting there in the background, and I send it the src files and switches from a client - instant compile! I hardly use this either, but again it was fun to write.

Speaking for myself, most of my programming time isn't spent in editing, compiling, debugging or looking up docs - it's mostly spent in understanding new problems - with pen and paper. Typing is the easy part!

But my projects are unusual. It's funny, in trying out Eclipse, I'm more interested in the cool ideas they've had than in actually using it. It does have some cool stuff in it.

Emacs?

For command-line folk, either Emacs or vi would probably make the most sense long-term. They often have plugins to add functionality to make them more IDE-like. Learning curve's a bit tougher though, and might require more effort than it's worth. I still haven't completely switched over to Emacs yet, but it might pay off in the long run.

I used emacs for everything and relatively recently got into the situation of having to do some java.

http://jdee.sourceforge.net/

It handles that too. I like having one editor that can follow me everywhere. Maybe Eclipse or the others work better for java or more out of the box or some such thing, but to me there's a huge benefit to having my programming editing behaviors consistent in a terminal, my desktop, PHP, perl, C, C++, java, etc. (with mode/language specific enhancements of course).

If I grew up on Eclipse I'd probably feel the same way I suppose about it.

I love IntelliJ, but if you think Eclipse and NetBeans are bloated you'll almost certainly think the same of IntelliJ. Keep in mind, though, you do get a lot of features in return for all the "bloat"-- refactoring, intentions, inspections, better navigation and too many others to mention.

Programming in Java is tedious and a good IDE makes things much less painful so maybe you'll want to reconsider. Unfortunately, there's not much middle ground between plain old text editors and full fledged IDE's so your options will be a little slim.

You may want to check out JDEE for emacs. Setting it up is a little complicated, but it's probably going to be a little snappier than an IDE. You could also try jEdit. There are various Java development plugins so you can pick and choose the features you want.

http://jdee.sourceforge.net/ http://plugins.jedit.org/list.php?category=5

I have been meaning to check out eclim: http://eclim.sourceforge.net/

Whoa! Holy crap!

The pain of Eclipse's bloat is real, but the speed with which you can learn new libraries through its features is worth it. I won't come within 10 feet of Eclipse for anything but Java, but its so great it makes Java fun because I can effortlessly zoom through definitions in multiple layers of libraries and figure out what is going on faster than in any other language/IDE.

And I don't even like Java.

I get funny looks for using emacs for Java work, but it loads and runs fast on all the different platforms I work on. I have used and support people using Eclipse, and generally I like the ability to find definitions etc, but the refactoring rarely proves essential. As for autocompletion, if you can't hold the whole core language in your head, there's something wrong somewhere ;-)

I think if you find that refactoring is "barely essential" then you are really missing out. I must use it's features about 20 times a day - from simple ones like "Rename" (seriously how would you do that easily in emacs, when the class is used in 15 places?), Extract Local Variable, Extract Method, etc.

I don't do multi-file changes in emacs, but they are pretty trivial with "perl -pi -e ...". You have a lot more flexibility with this method. I often create a new branch, spend a few commits getting the rename right, and then squash the commits and apply it to my real branch. (Sometimes I apply the changes to the index instead of applying it as a commit -- this way I can change other things in the same commit.)

Anyway, the automated tools sort of fake this workflow, but sometimes the real thing is nicer.

I've always had this nagging suspicion that I could become more productive, if only I truly learned how to use emacs. But this post has just finally convinced me that the only people who cling to emacs for large scale development are true believers who will never be swayed.

The automated tools don't fake your workflow. A refactoring tool performs code modifications that it can prove make no change to the semantics of the code. You can sort of fake this, in a painful way using perl, but as you've just stated, your system is so unreliable that you create a branch to do something I may do a dozen times in an hour when I have some time to go back and clean up.

But this post has just finally convinced me that the only people who cling to emacs for large scale development are true believers who will never be swayed.

Yes, judge thousands of people by one person. That has served society very well over the years.

Anyway, in Eclipse, every non-trivial rename "requires preivew" and often requires cleanup. If you just want to change the name of a class, the GUI is fine. If you want to do something more involved, you end up doing it manually anyway.

For trivial renames in Emacs, I have a function called "rename-this" which is mode-sensitive and Does The Right Thing for languages I actually use (Perl, Haskell, and Lisp). (Most things are non-trivial, though, as dependencies on a class name are not always in the form of the class name in the source code. "${prefix}::Foo" is hard to detect, but occasionally appears. Refactoring works well in Java because there is no possibility for syntactic abstraction, and it must be a function of your text editor. That approach is why I avoid Java.)

Edit: BTW, if you get to make a snide comment, so do I:

"Your post has finally convinced me that the only people who cling to IDEs for large-scale development are true believers who are more comfortable clicking buttons than writing software." Tool building is an important skill that IDEs actively discourage.

The java language is actually very small and easy to remember. The standard library, on the other hand, is huge. If there's any glory in remembering what the constructor arguments are for a certain class, it's lost on me.

Plus, in the real world, many of us use what we call "third party code" which could be as simple as something as a database driver or some kind of utility class. If you think you're going to remember perfectly everything all the time, then you are dreaming.

And on refactoring: if you don't think it's essential, please do yourself a favor and find someone who can give you a tutorial. Refactoring is the key feature of all of these IDEs.

Say you have 100K lines of code in a project. You want to move a class to a new package. In your world, you spend a week doing it and probably typing javac over and over on the command line. In my world, I can do it in less than 5 seconds and know the IDE is 100% correct. When you have power like that in an easily accessible frontend, you tend to use it. That benefits your code by making the big ugly maintenance tasks into afterthoughts.

> In your world, you spend a week doing it and probably typing javac over and over on the command line.

Perhaps you should learn to use the command line if you think refactoring without an IDE takes a week. :-/

How long would it take you to refactor say an entire package hierarchy in an open source project like jfreechart? Id love to see a video of how this happens as evidence.

ablashov, I have to chime in with the others here and let you know that Eclipse does so many things for you, that in direct contradiction to what you assume, it is actually difficult to set up Emacs or Vi to do the same for you. One example is whole-workspace refactoring : Let's say you decide that a function (method) needs to take an extra parameter, a boolean, but actually, that is just to cover some corner cases, i.e., the argument will be false in most cases, but true for 5% of cases. But that method is used in 326 places. Guess what : changing method signature and refactoring ALL the code that uses that method is just a few actions in Eclipse. Eclipse --> Refactor --> Change method signature --> Add new parameter, boolean isCorner, default = false. You're done. It changes all 326 references to your method and rebuilds the project.

Truth be told, Eclipse is a key reason for Java's popularity. It makes working a pleasure and helps you focus on the actual work, not on the mechanics of how-to-get-it-done.

I'll go further and say that Java is a horrible experience without Eclipse. One of my colleagues at work said today that (1) Java sucks without Eclipse and (2) Eclipse's wonderful features wouldn't be possible without all the things that makes the Java language suck.

That is Seibel's corrollary to Greenspun's Tenth Rule, no? Every sufficiently complex java program need a programmable IDE to make up for the half of Common Lisp not reimplemented in the program itself.

I had a conversation about refactoring with one of the giants of the Lisp world earlier this week about this, actually. The parts that make Lisp so powerful are the parts that also make it so hard to build reliable refactoring tools. Refactoring is something you need in any language. Otherwise, the implicit presumption is that you always get your software architecture 100% right the first time around.

I'd give JEdit a look. It's been a while since I've used it, but when I did several years ago, I appreciated how lightweight it was and it just worked. Nowadays I use Intellij on Ant and Maven based projects.

If you know emacs: http://jdee.sourceforge.net/

it seems really weird to me you find netbeans complicated. There's a reason java developers use bloated IDE's for anything more than quick edits. Spend a week in Netbeans and I bet you a lap dance you keep using it.

That said, maybe Geany is what you want... It's lightweight and somewhere in between an IDE an editor. I quite like it.

I'll second that. As a seasoned eclipse user I had another look at Netbeans recently. It seemed pretty much the same for me, and offered no compelling reason to switch. Until I poked around the profiler.

Well, let me say there's no going back for me. The Netbeans profiler gives me confidence from knowing exactly what my application is doing, and exactly what that third-party library is costing me. The coverage, allocation stack traces, and jvm heap monitoring are fantastic. Seriously. Take a look: http://www.netbeans.org/kb/60/java/profiler-intro.html

So yeah, I'll take a slice of that action and throw a pole dance in on that lap dance you bet. And it didn't even take me a week before I realised.

If you jumped from Eclipse to NetBeans, there wasn't any pain from the different plugin offerings? I don't enjoy installing two IDEs for the same language, but that's what I end up doing, unhappily.

No pain at all. I don't rely heavily on plugins though. The important bases were covered: refactoring, vcs integration, and the usual javadoc/outlining.

Perhaps the only things I missed were getting a method's signature when you hover over it with the mouse, and the live variable value when you hover in debug mode. But these are so minor that I feel if they're not already there and I somehow haven't set them up, they'll be in the next release. But as I said, I get so much more confidence by being able to charge in to my code's runtime and poke around that it's worth it.

I was in the same situation a while ago and ended up jumping to netbeans with the free and excellent jvi plugin. However, I feel your pain and when I recently started using scala on a hobby project I was really happy to be able to just use vim again -- partly because the netbeans support isn't so good for scala and partly because the language "feels" like it doesn't need an IDE.

All right, you guys convinced me to give Eclipse another shot. So, I'm going to really try to get into it this time before I knock it.

Eclipse,emacs and maven works for me. I use the emacs for making quick changes and often end up working within it. Still couldn't go without having eclipse along side though.