Live data from Hacker News

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

news.ycombinator.com

11–20 of 53 posts

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

#11
post #8

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.

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

#12

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 ("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?

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

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

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

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

#14
post #10

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

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?

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

#15

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 ("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 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?

#16
post #8

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

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.

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

#17
post #10

Earlier 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?

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.

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

#18
post #10

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

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

#19
post #15

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 ("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…

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.

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

#20
post #13

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'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.
Post reply on HN