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.

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.

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.

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.

[1] Or some other rich IDE.

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

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

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.

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

Otherwise, you can leave your structure intact and unchanged.

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.

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

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.

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.

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

And I don't even like Java.

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.

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

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

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.

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.

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.

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.

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.