Eclipse and why I continue to use it
I use Eclipse. I don't deny it. I also use Emacs and VIM. But there are some features in Eclipse that I like and as far as I know, it is not a crime to use the IDE. Here is yet another forum discussion where I describe why Eclipse is not Java.
First, I think these comments from two posters clearly define why Eclipse doesn't do some tasks as you might expect.
"Eclipse doesn't make assumptions about which JRE library you're building against. That information comes from the Build Path information in a Java Project, and while that may be a hassle for the "Hello, World" kicking-the-tires scenario, assumptions can wreck the reproducibility of problems you run across as you scale to more complex scenarios. Past the simple cases, you want this amount of control over what you're building against"
"Eclipse uses incremental builder to build the project. It doesn't matter you have one file or hundereds of files. It just compiles the modified files.And if you have one and only one file,and if it has dependencies on lots of jar files,it is still easier to manage this with eclipse, rather than setting the classpaths and use javac from command prompt." -- biju thomas
Eclipse operates (in some respects) like the squeak smalltalk environment where your code is connected not just to the syntax-highlighting editor but to the other tools that Eclipse has. Eclipse has a hierarchy tool that maps out all the subclass and super-class implementations. If I subclass the Map class, Eclipse can connect to the source code "Map.java" and I hit F3 to navigate to the constructor source code if I need to look up some of the implementation. I can go all the way up the class hierarchy. I can check other classes in the package and see the other inter-dependencies. If it is a junit test case, I can launch the junit GUI to check if all my tests passed or not. I can hover a method and see the super-classes's javadoc comment.
All of that goes away if you are just treating a java class as a simple text file.
http://www-306.ibm.com/software/awdtools/smalltalk/
http://en.wikipedia.org/wiki/IBM_VisualAge
IBM's VisualAge was written in Smalltalk. VisualAge turned into IBM's Eclipse.
I said that Eclipse was not designed around a single Java source file. The Eclipse development "environment" designers over the last couple of years and many milestones decided to couple the java dependencies like the java system classpath and user classpath and other project dependencies in terms of a project. For example, you may compile an Eclipse project with Sun's JDK or you may decide to compile your project using IBM's JDK. And, for whatever reason they decided that it is better to combine the ENTIRE java system runtime environment (rt.jar) and user classpath (developer libraries like mylibrary.jar) together as a whole.
For example, when you are using the text editor and syntax highlighting. It is probably better to know if you are using Java 1.6 version of a String or Java 1.4 version the String class. If you compile your code without knowing that information, then the text editor may highlight the syntax differently.
First, I think these comments from two posters clearly define why Eclipse doesn't do some tasks as you might expect.
"Eclipse doesn't make assumptions about which JRE library you're building against. That information comes from the Build Path information in a Java Project, and while that may be a hassle for the "Hello, World" kicking-the-tires scenario, assumptions can wreck the reproducibility of problems you run across as you scale to more complex scenarios. Past the simple cases, you want this amount of control over what you're building against"
"Eclipse uses incremental builder to build the project. It doesn't matter you have one file or hundereds of files. It just compiles the modified files.And if you have one and only one file,and if it has dependencies on lots of jar files,it is still easier to manage this with eclipse, rather than setting the classpaths and use javac from command prompt." -- biju thomas
Eclipse operates (in some respects) like the squeak smalltalk environment where your code is connected not just to the syntax-highlighting editor but to the other tools that Eclipse has. Eclipse has a hierarchy tool that maps out all the subclass and super-class implementations. If I subclass the Map class, Eclipse can connect to the source code "Map.java" and I hit F3 to navigate to the constructor source code if I need to look up some of the implementation. I can go all the way up the class hierarchy. I can check other classes in the package and see the other inter-dependencies. If it is a junit test case, I can launch the junit GUI to check if all my tests passed or not. I can hover a method and see the super-classes's javadoc comment.
All of that goes away if you are just treating a java class as a simple text file.
http://www-306.ibm.com/software/awdtools/smalltalk/
http://en.wikipedia.org/wiki/IBM_VisualAge
IBM's VisualAge was written in Smalltalk. VisualAge turned into IBM's Eclipse.
I said that Eclipse was not designed around a single Java source file. The Eclipse development "environment" designers over the last couple of years and many milestones decided to couple the java dependencies like the java system classpath and user classpath and other project dependencies in terms of a project. For example, you may compile an Eclipse project with Sun's JDK or you may decide to compile your project using IBM's JDK. And, for whatever reason they decided that it is better to combine the ENTIRE java system runtime environment (rt.jar) and user classpath (developer libraries like mylibrary.jar) together as a whole.
For example, when you are using the text editor and syntax highlighting. It is probably better to know if you are using Java 1.6 version of a String or Java 1.4 version the String class. If you compile your code without knowing that information, then the text editor may highlight the syntax differently.
Comments