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 ;-)
Ask HN: Reasonable Java editor for heavily CLI-oriented UNIX types who hate bloat?
11–20 of 53 posts
Re: Ask HN: Reasonable Java editor for heavily CLI-oriented UNIX types who hate bloat?
#12Anybody 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 ("unnec…
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?
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...
Re: Ask HN: Reasonable Java editor for heavily CLI-oriented UNIX types who hate bloat?
#13Truth 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.
Re: Ask HN: Reasonable Java editor for heavily CLI-oriented UNIX types who hate bloat?
#14Earlier quoted context omitted.
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.
Re: Ask HN: Reasonable Java editor for heavily CLI-oriented UNIX types who hate bloat?
#15Anybody 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 ("unnec…
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.
Re: Ask HN: Reasonable Java editor for heavily CLI-oriented UNIX types who hate bloat?
#16I 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 ;-)
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.
Re: Ask HN: Reasonable Java editor for heavily CLI-oriented UNIX types who hate bloat?
#17Earlier quoted context omitted.
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?
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.
Re: Ask HN: Reasonable Java editor for heavily CLI-oriented UNIX types who hate bloat?
#18Earlier quoted context omitted.
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?
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".
Re: Ask HN: Reasonable Java editor for heavily CLI-oriented UNIX types who hate bloat?
#19Anybody 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 ("unnec…
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…
Re: Ask HN: Reasonable Java editor for heavily CLI-oriented UNIX types who hate bloat?
#20ablashov, 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,…