Related
I am looking for a free Java code analysis/metrics tool that I can use to see class dependencies, method execution times, etc, and possibly to print out a diagram that shows them. I am currently using a jdepend task in ANT to achieve this, but I'm thinking there must be a better tool for that sort of thing. I would also prefer if it was integrated with Netbeans, since I'd rather not port all my projects to Eclipse for the task of analyzing. I have tried to play with the community version of Visual Paradigm, but I got sick of it really fast when it didn't offer code synchronization in the community edition. Although I can give it another shot if that is indeed the way to go. I also tried BOUML, but it seems to be more of a UML design tool than an existing code analyzer. So, my question is, what do you guys use for Java code analysis? Thanks!
EDIT: For instance, JDepend measures a few metrics and can draw a nice little dependency graph, but it doesn't exactly have a UI or anything. I guess I'm looking for a tool that can draw out all my classes and their dependencies on each other (jdepend only does packages AFAIK) as well as the methods that are called between the classes and provides a metric number of "how good the code structure is". I apologize if the question is vague, I'm just looking for a variety of options and I don't exactly have a lot of experience with code metrics tools...
As #Victor has mentioned Sonar is a very good tool for static code analysis. It produces graphs, charts, and generally allows you to slice and dice your Java code analysis in multiple ways.
However, it does run as a server, which can require privileges on your machine/network that you might not have. I use it myself, and I recommend it, but it's not always practical. So let's take a look at some of the tools that it uses underneath the hood.
First, there's FindBugs. As the name implies, it helps you find bugs in your Java source code.
Next, there's PMD. It helps find bugs in different ways from FindBugs.
Third, there's CheckStyle. It helps ensure that your code conforms to certain style guidelines.
Finally, there's Cobertura, which instruments your Java bytecodes and analyzes which source code lines are exercised by your unit tests (you do have unit tests, right?)
This is not an exhaustive list of the tools that Sonar employs, but it covers what seem to be the highlights. Inside Sonar, these are all 100% configurable. Outside Sonar, they're still configurable, but you better like XML.
Sonar. Though, personally I've never used it, so I can't answer questions about details. However, I know that our conitnuos building tool is integrated with it to make pretty pictures :)
I was just about to include the HtmlUnit library in a project. I unpacked the zip-file and realised that it had no less than 12 dependencies.
I've always been concerned when it comes to introducing dependencies. I suppose I have to ship all these dependencies together with the application (8.7 mb in this particular case). Should I bother checking for, say, security updates for these libraries? Finally (and most importantly, actually what I'm most concerned about): What if I want to include another library which depends on the same libraries as this library, but with different versions? That is, what if for instance HtmlUnit depends on one version of xalan and another library I need, depends on a different version of xalan?
The task HtmlUnit solves for me could be solved "manually" but that would probably not be as elegant.
Should I be concerned about this? What are the best practices in situations like these?
Edit: I'm interested in the general situation, not particularly involving HtmlUnit. I just used it here as an example as that was my current concern.
Handle your dependencies with care. They can bring you much speed, but can be a pain to maintain down the road. Here are my thoughts:
Use some software to maintain your dependencies. Maven is what I would use for Java to do this. Without it you will very soon loose track of your dependencies.
Remember that the various libraries have different licenses. It is not granted that a given license works for your setting. I work for a software house and we cannot use GPL based libraries in any of the software we ship, as the software we sell are closed source. Similarly we should avoid LGPL as well if we can (This is due to some intricate lawyer reasoning, don't ask me why)
For unit testing I'd say go all out. It is not the end of the world if you have to rewrite your tests in the future. It might even be then that that part of the software is either extremely stable or maybe not even maintained no more. Loosing those is not that big of a deal as you already had a huge gain of gaining speed when you got it.
Some libraries are harder to replace later than others. Some are like a marriage that should last the life of the software, but some other are just tools that are easily replaceable. (Think Spring versus an xml library)
Check out how the community support older versions of the library. Are they supporting older versions? What happens when life continues and you are stuck at a version? Is there an active community or do you have the skill to maintain it yourself?
For how long are your software supposed to last? Is it one year, five year, ten year or beyond? If the software has short time span, then you can use more to get where you are going as it is not that important to be able to keep up with upgrading your libraries.
It could be a serious issue if there isn't a active community which does maintain the libraries on long term. It is ok to use libraries, but to be honest you should care to get the sources and put them into your VCS.
Should I bother checking for, say, security updates for these libraries?
In general, it is probably a good idea to do this. But then so should everyone upstream and downstream of you.
In your particular case, we are talking about test code. If potential security flaws in libraries used only in testing are significant, your downstream users are doing something strange ...
Finally (and most importantly, actually what I'm most concerned about): What if I want to include another library which depends on the same libraries as this library, but with different versions? That is, what if for instance HtmlUnit depends on one version of xalan and another library I need, depends on a different version of xalan?
Ah yes. Assuming that you are building your own classpaths, etc by hand, you need to make a decision about which version of the dependent libraries you should use. It is usually safe to just pick the most recent of the versions used. But if the older version is not backwards incompatible with the new (for your use case) then you've got a problem.
Should I be concerned about this?
IMO, for your particular example (where we are talking about test code), no.
What are the best practices in situations like these?
Use Maven! It explicitly exposes the dependencies to the folks who download your code, making it possible for them to deal with the issue. It also tells you when you've got dependency version conflicts and provides a simple "exclude" mechanism for dealing with it.
Maven also removes the need to create distributions. You publish just your artifacts with references to their dependents. The Maven command then downloads the dependent artifacts from wherever they have been published.
EDIT
Obviously, if you are using HtmlUnit for production code (rather than just tests), then you need to pay more attention to security issues.
A similar thing has happened to me actually.
Two of my dependencies had the same 'transitive' dependency but a different version.
My favorite solution is to avoid "dependency creep" by not including too many dependencies. So, the simplest solution would be to remove the one I need less, or the one I could replace with a simple Util class, etc.
Too bad, it's not always that simple. In unfortunate cases where you actually need both libraries, it is possible to try to sync their versions, i.e. downgrade one of them so that dependency versions match.
In my particular case, I manually edited one of the jars, deleted the older dependency from it, and hoped it would still work with new version loaded from other jar. Luckily, it did (i.e. maintainers of the transitive dependency didn't remove any classes or methods that library used).
Was it ugly - Yes (Yuck!), but it worked.
I try to avoid introducing frivolous dependencies, because it is possible to run into conflicts.
One interesting technique I have seen used to avoid conflicts: renaming a library's package (if its license allows you to -- most BSD-style licenses do.) My favorite example of this is what Sun did when they built Xerces into the JRE as the de-facto JAXP XML parser: they renamed the whole of Xerces from org.apache.xerces to com.sun.org.apache.xerces.internal. Is this technique drastic, time consuming, and hard to maintain? Yes. But it gets the job done, and I think it is an important possible alternative to keep in mind.
Another possibility is -- license terms abided -- copying/renaming single classes or even single methods out of a library.
HtmlUnit can do a lot, though. If you are really using a large portion of its functionality on a lot of varied input data, it would be hard to make a case for spending the large amount of time it would take to re-write the functionality from scratch, or repackage it.
As for the security concerns -- you might weigh the chances of a widely used library having problems, vs. the likelihood of your hand-written less-tested code having some security flaw. Ultimately you are responsible for the security of your programs, though -- so do what you feel you must.
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 12 years ago.
Firstly, in my opinion, this question is relative to programming, as much as the answers (and the question itself) is subjective, I would like to see some of these subjective opinions, and other ideas that come from it.
My company is deep in bed with oracle. They are making a strong move towards java, and well forcing JDeveloper down on us (me) as the 'best tool' for the job. Now, dont get me wrong, JDeveloper looks amazing, it has all these nice trinkets that would make anyone smile when unwrapping. But...
I tend to always end up having to investigate some tiny problem that the IDE suffers to do right. Essentially bugs. Like at times when for no reason EJB's do not deploy anymore. Or the ADF front end stop calling data controls for action buttons. Then I have the times that It crashes out completely when editing persistance information. In the end, I spend more time figuring out what is wrong with it, to no avail. And well, my company is not about the take out money to get support for the development tool. I end up sitting with problems that take hours up to days to resolve, which should be taking 10 minutes.
I have seen and experienced similar productivity killing problems in IBM's websphere products too. And not It's not just me, I have seen teams unable to work for days because of issues.
My solution to this has always been to use the eclipse j2ee set. It allows me to be more in control of everything that's being used. And so, even if eclipse gives me problems, I can resolve these issues. And well, personally, I would prefer my company accepting that as a preferred tool, as solving problems would be easier, and there would be more 'professionals' arround, as our problems would more likely be j2ee related, and server related rather than IDE related (We get tons of server side support). I feel the 'abstraction' that larger IDE's provide can cause lots of headache's and tend to be a project killer.
Why do I struggle so much with JDeveloper. Am I alone?
Is it wrong of me to take a stand and recommend going against JDeveloper as the core development tool in our company?
Because well, this is the 'campaign' I would like to walk into now, up to the point of demonstrating the flaws, as the video's only show the perfect moments.
You are not alone! I could rail against JDeveloper but i'll restrain myself.
Unfortunately, JDeveloper is the only IDE that supports all the Oracle-centric technology. So, while i'm sorry for your pain, and, trust me when i say, i understand more than you know, but, in an Oracle house, no other IDE will do. It's a real shame that you don't have support though. You'll likely need to file lots of bugs.
It's really unfortunate that Oracle seems insistent on continuing with JDeveloper even now that they own NetBeans. JDeveloper is far behind Eclipse and NetBeans. They'd have far greater developer acceptance of their technology if they actively supported Eclipse and/or NetBeans, at the very least, in parallel with JDeveloper. There's actually quite a nice, extensive set of technology in ADF that is being hidden behind and hampered by such a horrendous development tool.
And as a means to try and help you solve all the problems you'll encounter with JDeveloper, try this. Use two local mercurial or git repositories. One for your JDev system folder (init in the parent of system/) and a repo for your application/project. Before finishing (or starting) any wizard, add and commit (hg com -Am 'savepoint' or git commit -am 'savepoint') both repos. This'll give you a way to rollback and also diffs of how JDeveloper broke a working project which might give you clues about how to fix things.
Also, you might want to keep a log for your managers to show how much time you spend managing JDeveloper instead of progressing on your projects.
Good luck.
Note: Version control on the jdev system folder is a little questionable for rollbacks since it seems jdev buffers some writes and keeps some files open. Which means you might take a snapshot of an inconsistent or incomplete state. It's better to use that repo as an ongoing view of what is changing.
EDIT: Also see Oracle Enterprise Pack for Eclipse
I've just started to work in a new place, and I see several things they do that I find really terrible, and I want to know if they are indeed so wrong, or I am just too strict. Please let me know if my criticism is in place, and your opinion on which problem is the worst and should be fixed first. The developement is all in Java.
Not using svnignore. This means svn stat can't be used, and developers forget to add files and break the build.
Generated files go to same folders as committed files. Can't use simple maven clean, have to find them one by one. Maven clean doesn't remove all of them.
Not fixing IDE analyze warnings. Analyze code returns about 5,000 warning, of many different kinds.
Not following conventions: spring beans names sometimes start with uppercase and sometimes not, ant properties sometimes with underline and sometimes with dots delimiter, etc.
Incremental build takes 6 minutes, even when nothing is changed.
Developers only use remote debug, and don't know how to run the Tomcat server internally from the IDE.
Developers always restart the server after every compilation, instead of dynamically reloading the class and saving the server's state. It takes them at least 10 minutes to start checking any change in the code.
Developers only compile from command line. When there are compilation errors, they manually open the file and go the the problematic line.
A complete mess in project dependencies. Over 200 open sources are depended on, and no one knows what is indeed needed and why. They do know that not all dependencies are necessary.
Mixing Maven and Ant in a way that disables the benefits of both. In one case, even dependency checks are not done by Maven.
Not using generics properly.
Developers don't use Subversion integration with IDE (Eclipse, Intellij Idea).
What do you think? Where should I start? Is any of the things I mentioned not really a problem?
I'd look at it like this:
Anything that affects productivity should be solved first
Things that affect profitability solved second (most productivity fixes are profitability fixes too)
Nitpicky stuff last
Therefore, you should have the following (in order of my opinion):
7 - Restarting the Server after Compilation
5 - Incremental Build Speed
6 - Remote Debugging only
8 - Compiling from command line
12 - Subversion Integration (kind of in the same league as 5. above)
2 - Generated Files
11 - Not using Generics Correctly
Then
1 - svnignore
9 - Project Dependencies (this will take a great deal of time i'm sure)
10 - Mixing Maven + Ant
3 - IDE Warnings
4 - Conventions
The reason I have the ordering in this sense is time vs. benefit. If it takes a user 16 minutes to compile and check their code, it's bloody well insane to be honest. Say a developer compiles 5x per day, we're taking about 80 minutes, doing nothing.
After that it's productivity. If you speed up the rate at which your developers can do their work, the turnover of work completed will rise substantially. (Profitability++)
After this is the "nitpicky" things. I say this not as to infer that they're not important, but the fact is from the looks of things you have much bigger fish to fry, so get those done first before correcting casing in code.
Not being a maven user, I can't comment on some of the above but most things in your list look like good areas for improvement. I think the best advice I can give is:
Take it slow. They've probably been doing it this way for ages and may resist change.
Get the team (and possibly the manager(s)) involved in the changes. Hold a meeting to discuss what improvements you see (keep it simple, just a few), what they think of them, and if they think its sensible to implement. Then, if agreed, pair with someone to get the improvement in place.
Offer presentations on working practices which are easily changed. E.g. show them in a live setting the difference of dynamic class loading during a debugging session.
Prioritize the list above and focus on a few at a time.
Be gentle. Change is hard! To much at once will potentially alienate or disengage folk.
Start with quick wins that will make an immediate and positive difference to the developers in the team. This will build their confidence in accepting more difficult changes.
Best of luck...
Comments to the issues
1) Not using svnignore. This means svn stat can't be used, and developers forget to add files and break the build.
Doesn't sound very critical to me - I assume from the above that you have a CI or nightly build (if not, that would be a major issue indeed). The purpose of the CI build is to catch such problems, so IMHO it is not a catastrophe if it is broken every now and then. Of course if it happens daily, that's a different story :-(
2) Generated files go to same folders as committed files. Can't use simple maven clean, have to find them one by one. Maven clean doesn't remove all of them.
This is bad, and is fairly simple to fix (under normal circumstances :-)
3) Not fixing IDE analyze warnings. Analyze code returns about 5,000 warning, of many different kinds.
This is bad, and it takes a lot of time to fix. However, skimming through the analysis results to spot really critical issues could be a high priority task.
4) Not following conventions: spring beans names sometimes start with uppercase and sometimes not, ant properties sometimes with underline and sometimes with dots delimiter, etc.
Not a catastrophe, OTOH easy to fix.
5) Incremental build takes 6 minutes, even when nothing is changed.
This is bad, and (considering cases 9 and 10 below) may be a rather daunting task to fix.
6) Developers only use remote debug, and don't know how to run the Tomcat server internally from the IDE.
A short demo and mentoring should not take a lot of effort. However, there may be cultural issues, and old members of the team might not be willing to learn new tricks. So a sensitive approach is required.
7) Developers always restart the server after every compilation, instead of dynamically reloading the class and saving the server's state. It takes them at least 10 minutes to start checking any change in the code.
Same as above.
8) Developers only compile from command line. When there are compilation errors, they manually open the file and go the the problematic line.
Same as above.
9) A complete mess in project dependencies. Over 200 open sources are depended on, and no one knows what is indeed needed and why. They do know that not all dependencies are necessary.
This is bad, and is a huge task to fix.
10) Mixing Maven and Ant in a way that disables the benefits of both. In one case, even dependency checks are not done by Maven.
Same as above.
11) Not using generics properly.
Do you mean they are still programming the Java 1.4 way using non generic collections et al? If the code is otherwise stable, this can be fixed (and developers educated) gradually.
12) Developers don't use Subversion integration with IDE (Eclipse, Intellij Idea).
See case 6.
Priorities
I would try ordering tasks based on cost vs benefit ratio. My order would be:
First, tasks to simplify and speed up day to day work, and build up your credibility and authority within the team: 7, 6, 8, 12, 2
Then the fundamental, but difficult and time-consuming tasks, for which you need more support from the team: (continuous integration in case there is none yet), 5, 10, 9
The rest can be introduced gradually: 1, 3, 4, 11
You don't mention continuous integration, but one good thing to start with is to give developers a rapid feedback if the build is broken. Once you have it you can add code quality metrics to encourage them to correct warnings or bad use of generics.
Only with all that in place you should start working on their productivity by showing them how to hot deploy, debug, use an IDE and so on...
And good luck :)
In general, I think that stuff that wastes time for developers should be taken care of first. The less idle the developer is, the greater the benefit.
1) This together with 12) should be prioritized higher, as broken builds take time.
3) IDE warnings aren't that important, as they are just warnings and could be as simple as unused imports.
4) Lack of naming conventions doesn't break anything and can be enforced gradually. That will take a lot of time however you do it. This shouldn't be highly prioritized.
5) I assume you have a separated build server that takes care of the builds, six minutes doesn't sound like a very long time. If you don't have a build server, that would be a good investment.
7) Sounds like a lot of time is being wasted for all developers, this should be highly prioritized.
11) These could cause a lot of the warnings in 3), should be fixed, but not highest priority.
12) Subversion integration with IDE should help out a lot, I think the developers would see this as very useful.
First of all, I totally agree with you list of problems since I have been on projects that have basically the same issues.
If you start with the places where you think you can gain the most productivity.
I would think that you can save considerable amount of time with:
Get tomcat running in the IDE.
Fix any build script, maybe also test, issues to make the builds run fast.
Compilation within the IDE and hotdeploy (hotswap/jrebel) will also save you a lot of time.
As already posted, get a continuous build server up and running for the project.
And if you have an issue tracker, add these issues to it so that everyone is aware of what needs to be done. When the high priority stuff has been completed try to push for time to get the other stuff fixed as well, its really annoying with all the small problems and even though they seem small now they can cause considerable headache after a while.
First of all, since you are new, you need to be careful not to be considered very annoying.
I would suggest you start by talking to your own boss, and say that you may have some experiences that might be useful to your new company. Management backup is essential if you want something done rather quickly.
You will need to demonstrate to your boss and coworkers that your suggestions are immediately beneficial to them, in their daily work. Hence select just one pain-point and fix it good (but reversible as going back is a nice option to have when trying things out). Be prepared to do a lot of work yourself and a lot of mentoring.
Based on your description, I would suggest a quick demonstration of a proof-of-concept web application being run inside the IDE with hotspot editing and instant redeployment of changed files would be very eyeopening. Do NOT go to fast - be certain that everybody understand what you do. Then as a final demonstration, do it again but in normal speed.
I am working on a solution that aims at solving problems that newbie programmers experience when they are "modifying code" while bug fixing / doing change requests, on code in production. Eclipse, as we all know is a great IDE. Features such as Code Completion, Open Declaration, Type Hierarchy, Package Explorer, Navigator, Finding References etc aids people in fixing things quicker compared to say using something like Textpad.
If you are a newbie java programmer and you are using Eclipse IDE, what areas of the Eclipse IDE do you think were less helpful/ less intuitive? If you are a seasoned programmer, what are the common issues that newbies look up to you to solve for them?
Please ignore issues related to : Domain Expertise (Business Knowledge), Infra( where to test your change etc), performance related (eclipse search being slow,etc), Skill level in a particular language (think of the developer as a noob) ... and think one language - Java
I did a local survey in my small team and here are some:
Newbies using Eclipse to handle code that is written to interfaces where the implementation is supplied at runtime. Doing a 'Open Declaration' will always show you an interface. This could be confusing at times.
Eclipse is not intuitive while developing EJBs. Sure, you know all you have to do to create a new bean is to right click and 'Create Bean', however, once created it shows no contextual help to what the next step should be. For instance, generating stubs.
When Data Source Mapping with entity beans, changing something screws up the entire flow of things and eclpise never complains / hints.
Developing applications that make use of Struts, eclipse doesn't tell you that when you change struts-config.xml, particular web flow would get affected.
At this point, to me, as someone who is interested in collecting opinions for my research, it appears as if Eclipse could use more 'contextual runtime hints'.
I am sure the community would have a lot more to add... Please add more of your negative experiences (just from the code change perspective).
EDIT:
I guess, my question was too lengthy and confusing. I am gonna rephrase it a bit and keep it short:
While "making a code change" (not analogous to code formatting, infra related activities, CVS etc... say something like refactoring), what feature(s) of eclipse IDE did you not like / hate the most? Here are the examples:
When modifying code that has been written to interfaces: 'Open Declaration /F3 on an object instance shows you the interface when the implementation is supplied at runtime'.
When changing apps using EJBs: No contextual help
When changing apps using MVCs(Spring / Struts) : No warnings about change impact.
Missing in Eclipse are:
Software visualization, as for example System Complexity View [Lanza 2003]
And also by Lanza, the Class Blueprint [Ducasse 2005]
Post Scriptum: Software visualization in Eclipse: X-Ray provides System Complexity View of Java projects, http://xray.inf.usi.ch/xray.php (via #anjaguzzi and Paul Lammertsma)
And then collaborative filtering "other developers that edited this method before also edited" [Zimmermann 2005]
And the collection of browsable examples, and autocompletion at the level of these examples. That is, for example if your write
ByteBuffer buf = file.
and hit autocompletion it should search the codebase and the interwebs for examples that convert files to bytebuffers and insert that 10-20 lines there.
Parseweb supports developers by recommending method invocation sequences that yield a required
destination data type from given input parameter types. http://doi.acm.org/10.1145/1453101.1453129
Prospector supports developers by recommending method invocation sequences that yield a required
destination data type from given input parameter types.http://doi.acm.org/10.1145/1064978.1065018
Strathcona provides source code examples and structural con-
text for the code fragment under development. http://lsmr.cpsc.ucalgary.ca/papers/holmes-icse-2005.pdf
Rascal recommends how and when to call the methods of objects from common libraries such as Java Swing, based on an analysis of existing classes. It uses collaborative filtering. http://dx.doi.org/10.1007/s10462-005-9012-8
And of course also the feature that I can write a Unit test and then the IDE searches the interwebs for classes that pass the test. Yes, this can be done!
CodeGenie is an Eclipse plugin that allows you to write unit tests and then uses the Sourcerer source code search engine to find passing classes. http://doi.acm.org/10.1145/1529282.1529384
CodeConjurer which is based on Merobase also offers that feature, see http://dx.doi.org/10.1109/MS.2008.110
This list could go on and on, good starting points for more work are the proceedings of past
Conference on Mining Software Repositories (MSR)
Workshop on Search-driven Software Engineering (SUITE)
Workshop on Recommendation Systems for Software Engineering (RSSE)
which are all under the umbrella of the ICSE conference.
"newbie issues" I've seen myself (I've used Eclipse for a good while, but it keeps "surprising" me occasionally) and helping colleagues just starting to use Eclipse:
It's large and complex enough to be very intimidating to some at first. Seems people consider netbeans easier to use initially. One colleague took refuge with the VI editor for a god while...
Installing plugins can be tricky (finding site URLs, awareness of plugins, why is "install"+"update" under the Help menu???)
Updates are still slow (but much better than before) with Eclipse 3.5/Galileo. It's difficult to understand which plugins to install just by their name sometimes.
Any platform besides Mac - preferences under the Window menu seems illogical?
Understanding how to set the project class path neatly. Setting the right project JDK version.
Lack of or unexpected interaction between ant/maven build tools' classpath and that of eclipse's (ant/maven clean causes Eclipse compiler errors when classpath is shared etc.).
Views and (large number of) perspectives are confusing/overwhelming at first. Which are useful when? How to drag views to the desired location or restoring closed ones?
Some JDK/Eclipse version combinations required too much PermGen space than available by default, took a while to diagnose.
For me, most of the newbie problems in Eclipse come from one of it's strengths, its configurability & plugin structure.
When I need to change a property in Eclipse, I always seem to have to spend a few minutes working out where to change it. Example: changing the Java editor to insert 4 spaces instead of a tab. The search bar in the properties is always welcome :-)
That and the lack of documentation for some of the plugins always makes for fun when I'm setting up a project.
EDIT: You can always show the classes that implement an interface using ctrl-T.
One thing I would add is that when I have a complex project, I tend to use Refresh & Project->Rebuild All *a lot". And I use TortoiseSVN to maniuplate stuff outside of Eclipse, because a lot of times this is easier (some refactoring for instance). However, if I'm modifying the project outside of Eclipse, I *always" quit Eclipse, and do a full refresh and build when I restart it. Otherwise Eclipse gets very confused sometimes.
I think the biggest problem I faced (and still face) with Eclipse is that it isn't particularly aware of standard technologies that surround modern Java development. If I'm developing an application, it might include the following:
Spring
Maven
JSF/Struts 2
Subversion
JUnit
I think Eclipse handles those technologies in increasing levels of awareness: (so JUnit will be fine, it works out of the box; Subversion requires Subclipse, and it's a little ropier than the CVS support; JSF needs some WTP tooling to be installed; Maven...you're probably best off setting up your own external tools commands rather than trust M2Eclipse, unless it's become dramatically better in recent times; and Spring, well, as you say, try ctrl-clicking on a method and you'll almost certainly get an interface, because the implementation is hidden away behind a Spring config file).
Getting all of that to play together and check out/compile, then later compile/run tests/check in is the difficult bit. The code change itself is probably easy :)
For me, the biggest hurdle to learning to use eclipse effectively was understanding where to set the classpath and also how to figure out exactly what is included on the classpath for various stages of development (compile, build, test). I was confused for a long time about the difference between compile time, debug configurations, and run configurations classpaths. Then if you throw ant into the mix (which automatically creates a run configuration ) it makes it even more confusing for newbies.
As a beginner, I didn't do EJB or Struts stuff. Or even data source mapping. So I think the question's title may be a little misleading.
I would have appreciated having something like JadClipse built in to "look at" library code when I hit it in debugging or such. But it should be made VERY clear that this is "reconstituted code" and not meant to be hacked around in.
Second, noobs need to be made much more aware that Shift-F2 will get them the API documentation for whatever class/method they're looking at. I know too many novice Java programmers who explore their APIs with nothing more than code completion; they're missing many valuable hints provided by the library authors.
A mindreader which generates code on the fly, so that a single click is sufficient to complete a project.
I found Visual Studio easy to pick up, I tried clicking on each button at least once, and figured out what the whole thing does. It's thought out by a single design team at the highest level, and everything follows the standards top to bottom, more or less.
Then, I play with Eclipse. In technical terms, it's janky at best. Look at the preferences dialog; it's an overwhelming trainwreck, unless you already know exactly what you're looking for, and what the developer working on that feature decided to call it.
Eclipse's configurability relies on the fact you already know how to configure it. The learning curve there is awful, and the only saving grace is that most of the defaults are okay to begin with.
I was a noob to eclipse recently, mostly doing Android and BlackBerry stuff. And one thing that eludes me to this day is the massive multitude of options and settings and various places they can be found in. For instance, if you have a plugin installed (say BlackBerry plugin), the setting might be found in the general prefs or BlackBerry prefs or the project prefs.
It's always a hunt.
Here are basic missing features as far as I know :
Show the beginning '{' when you are at the end '}' where beginning '{' is out of the view
Automatically synchronize the editor with package explorer
Go to different view (package explorer, outline, etc) with keyboard
Inline find, which does not open a dialog.
Go to next error location with keyboard
Go to next/previous structure with keyboard
More stability in general.
These features work great in IntelliJ. Especially #1 and #5 are really useful.
VCS integration - typically the developer is also new to merging changes, keeping working copies in sync, resolving conflicts and so on. There are often several ways of achieving the same thing in Eclipse and I've seen this cause confusion on several occasions (actually, I've seen this with experienced developers too; they know Subversion but not Eclipse, and the latter tries to 'hide' the underlying repository operations).
I think the issue with all IDEs for beginners is the disconnection from the tool chain: how the compiler takes some source and compiles it to bytecode which I then run using the VM with a correctly configured classpath.
As a dev I love the fact I don't need to deal with this - and I've never found myself unable to do what I want concerning more complex build configurations - but it's too important for beginners to understand what's happening when you press that Play button to be ignored.
when i first tried using eclipse i absolutely hated it's coplexity.. you had to do a whole bunch of things befor you were able to start working. furthermore you have way to many options to check and it's not always selfexplaining what each button does.
instead i started using netbeans. way more intuitive and easier to handle. check there gui.. not to much buttons and most of the time you know what the button does even if you have no clue of java (as i had at that time).
when i changed back to eclipse (due to some features not supported in netbeans) it seemed far easier to work with it. so some part of the gui might just be added in a not intuitive way and beginners will definitly have a hard time with it.
simplicity
clearness
consistency
I might write it much more in detail, but i think, that eclipse is overweight and much too much oriented on features - instead of ease of use. IMO, this concerns beginners as well as professionals.
Eclipse has no visual designer for Swing components.
Compare that to Visual Studio, where:
click 'new form'
drag buttons and text boxes onto the form, move them around, add some labels
double click on a button, add some code
done, one quick application, show it to the boss, get paid/promotion/coffee break
In Eclipse you either have to use Netbeans instead (ie not Eclipse...), or use IBM's SWT, or code the Swing forms by hand.
I feel it would be very nice to have a great wysiwyg forms designer in Eclipse for Swing forms.
The other confusing part is that for web development there is a separate version that needs to be used! Well I didn't like this at all and I know that a lot of people just don't about this.
Eclipse is missing Maven Embedded in standard distribution , Maven would help any user in getting their program all the jars and better library management .
Netbeans already has this tools.
Also eclipse misses integrated tools for hibernate , spring , xfire and tomcat deployment using maven.
Check this site http://maven.apache.org/
All of my other problems with Eclipse have already been mentioned except one: It's slooooooooow. Was their goal to prove the "Java is slow" people right? I'm guessing this is related to the "Eclipse does everything", but I stopped using it because it lags every time I click on anything. Change tabs? Lag. Open preferences? Lag. Change tabs in preferences? Lag. It's like using Photoshop with 32 Mb of memory.
Oh and it's incredibly ugly. I wish I could get it with real GTK+ integration.
The android SDK integration is full of jank. xml layouts don't render correctly. Code completion doesn't work well. IBM needs to fix the jank for sure.