Related
Just wondering out of curiosity, if one exists ?
I found a project called java-lli on GoogleCode that seems to be trying to do this. It is not clear how much progress has been made though. (No downloadable artefacts, and nothing in the Wiki. Just stuff in SVN with the last commits in May 2011.)
FWIW, you get more results if you search for "interpreter" rather than "emulator".
Just for further information, David A. Roberts put together LLJVM (#Github). This project is also for executing LLVM-derived bitcode on the Java JVM.
Please refer to my SO answer regarding this, as some other community members had furthered his code/created patches.
[Update] - LLJVM has seemed to have been dead for somewhile, however Howard Chu (https://github.com/hyc) looks to have made LLJVM compatible with the latest version of LLVM (3.3). See Howard's LLJVM-LLVM3.3 branch at Github, here
I'm setting up a Java development shop, currently just for myself as the only developer, but with hopes of needing to hire others as the business grows. Obviously I'm hoping to set it up right so that as more people come in, they can be productive right away. Please help suggest things I want to do, and tools to do them.
Here's what I think I need:
Distributed source code/revision control (Subversion?)
Bug tracking (does Trac do this?)
documentation (both internal and customer facing)
team communication
frequent automated building
maybe something to make sure automatic tests pass as part of the check-in process?
I like Hudson for Continuous Integration builds, and I like JIRA for issue tracking. Eclipse has plugins for both.
Hudson can watch software repositories and rebuild those projects that use the changed resources.
If you need more documentation than javadoc can cover (which is quite a lot) then consider a Wiki. Easy to use, and with a bit of structure you can massage it into a PDF.
Source control is a bugger. Too many to choose from. For a small development team start with either subversion or CVS (which is old but has supreme IDE support) and when you outgrow that and know your needs, then migrate to a better one. Most have migration tools from svn or cvs. It is harder to move from e.g. git to Mercurial, and you defintively want one with more than one implementation. Remember to have good backups of the source control repository - it IS your business. Frequent rsyncs, often tapes.
EDIT: You also want decent hardware. For the Continuous Integration server, the fastest build machine you can afford. For yourself the largest monitor you can afford (not in size, in resolution) for your primary monitor and as many extra monitors as you can afford to have (including adapters to your computer). I have found that Mac's use the pixels better than Windows, so that might also be a point.
My primary monitor is pivoted 90 degrees. This allows me to see many lines at once instead of a few long lines. (For some reason tradition says that editing areas should be wide and short, which may work in word but not in code where lines should not be wider than 72 characters)
Note on Eclipse: Use the source repository to have a single workspace per project! Use the Java Editor Save Function to reformat your code everytime you save - this makes it more readable up front, and goes better with the source repository as changes are marked in the correct version.
Edit: The reason for the CI server needing to be better than your development machine is because it will run all your tests every time you check stuff into your source repository. After a while, that WILL take time.
Personally I have found tests working well for library routines. They specify what works and what doesn't. It is harder to write good tests for whole applications, but you may want to look into that from the beginning, as it allows you to ensure that everything works for every check in. Write a comment if you are not familiar with the concept.
Whatever you choose for the individual parts, you will be glad if they can work together. Hudson knows how to talk to JIRA for instance. JIRA knows how to look in CVS.
To see what a big amount of people thinks to make a good software development environment read this article on the 12 points of joels test
This list does not include the things more important for you. Getting clients getting them to pay and manage legal stuff and taxes.
Most important, the right staff:
get great people who find work and handle customers (aka sales)
get software engineers who are smart and get things done (http://www.joelonsoftware.com/items/2007/06/05.html)
get someone who knows about accounting and the local legal and tax regulations, so you don't get any surprises
Tools / Processes:
use a distributed version control system like git or mercurial
jira or the like for bug/issue tracking
continuous integration with hudson or cruisecontrol
wiki system to share the teams tangible knowledge
unit tests, clover, checkstyle, findbugs, ...
From a managerial point of view i would try
daily standup meetings (checkout scrum) to keep the team updated members to commit by saying what the did, do, and will do
timeboxed meetings, everything else sucks.
plan iterations/sprints
let team do task time estimations
pair programming (gets you better code)
code reviews (builds trust)
weekly in house "techtalks" to build a strong sense for the team
twitter like communication tool to keep all insync and informed with minimal distraction
develop team towards dynamic languages (groovy, scala, ...)
yourself, listen to what the guys at http://manager-tools.com/ have to say...
good luck!
We have been using:
version control:
subversion - Its not distributed but it is accessible over a few different protocols if firewalls are an issue. I'm not sure if distributed version control is necessary for us and reading Eric Sink's take is entertaining at least
issue tracking :
Fogbugz - You get some team discussion and communication for free with it because of the built-in wiki and discussion boards.
continuous integration:
CruiseControl - we had been talking about switching to Hudson, but Cruise is working really well right now - it runs our unit tests.
dev environment:
Netbeans and Eclipse - There is really no reason to pay for a Java IDE. An import point for getting going fast is that Netbeans and Eclipse both store all of their project data as text files which version control nicely. See this question. We had giant headaches when using an IDE which used binary project files.
profiler:
JDK VisualVM - Its free and it works. I used to really like YourKit, but VisualVM does so much now.
documention:
Combination of javadoc and fogbugz wiki pages plus the cruise dashboard for internal. For external we are using RoboHelp and we dislike it.
other tools:
Findbugs - huge help in catching things that are sometimes really stupid and sometimes amazing quirks that you'd have never realized. PMD is good for some of this as well.
We find chat tools to be really helpful for communication. We used to have access to Sametime and it had a giant conferencing feature that was really great. That was taken away for an unknown reason by the overlords though.
Here is what development stack our team of five developers is using over a year now:
Eclipse IDE (worked better for us than NetBeans)
Maven as a project comprehension and build tool -- simply a must tool!
Nexus: The Maven Repository Manager -- serves as a local Maven repo for proxying, and for managing internal and 3rd party libs; simple in use and is really necessary if you're going to use Maven
Subversion for source versioning -- was chosen mainly due to very good IDE support (Subclipse for Eclipse IDE)
Trac as a bug tracking and requirement management tool -- it nicely integrates with Subversion, has very useful plugins including blog and discussion plugins; also it can be integrated with Eclipse Mylyn.
Hudson as continuous integration, which nicely integrates with Subversion, Maven and Trac -- very valuable even for a small team.
Sonar code quality management platform -- a tool which integrates a large number of code quality matrix with intuitive web interface supporting code review and drill-down facility for analysis of the problems; integrates with Maven.
In our case this development stack is running under Ubuntu (workstation components: Eclipse IDE, Maven) and CentOS (server components: Maven, Nexus, Subversion, Trac, Hudson, Sonar).
As for the documentation, LaTeX (TexLive and Kile under Ubuntu) works just great supporting high quality PDF generation. The documentation source can be managed by Subversion the same way as the application source. Allows making of simple several page document and large multi-chapter books.
Hope this helps.
Distributed source code/revision control (Subversion?)
Subversion is good enough unless you want to use this as an opportunity to learn Git or Mercurial.
Bug tracking (does Trac do this?)
Trac works fine if you don't mind CamelCaseTurningIntoWikiWords. JIRA is fancier but (as noted) not free, and I find its data-ink ratio annoyingly low. Good once you learn which parts of the UI to ignore, though.
documentation (both internal and customer facing)
Internally, I would prefer communication over documentation unless you're really willing to commit to spending time keeping internal documentation updated. Javadoc your integration points (internal/external APIs), but try to keep your code and build scripts as self-documenting as you can.
That said, requirements docs are useful. I'd suggest using one tracking system for bugs and requirements. JIRA lets you create hierarchical issues, but I wouldn't bother with that till you need it.
Trac includes a Wiki, which can be handy although too much content will get stale.
Customer-facing docs are all over the map -- depends a lot on what you're doing. If you need big fat manuals (either printed or HTML or on-line help) FrameMaker + the DITA Open Toolkit is a nice combo, but a FrameMaker license is going to set you back $1000.
At a certain point this shades into corporate communications (marcom and PR), which are kind of a different animal.
team communication
Google Talk (or the instant messaging framework of your choice), email, and the occasional Skype teleconference are probably all you need.
An internal wiki and/or internal blogs might be nice but you probably don't need them right away, even once you've added a few more developers. Trac includes a wiki.
frequent automated building
Switching from CruiseControl to Hudson has made everyone here much happier -- two teams made the same decision independently and both are pleased with it. Hudson's flexible, easy to configure, and shiny.
I have yet to be convinced by Maven. I suspect its value depends on how much you want automated downloads of the latest versions of all your open-source libraries.
Edited (Feb. 2010) to add: Several months of Maven 2 experience now and I'm still not convinced. I think (like many frameworks, e.g. Rails) it may work well if you're starting from scratch and structuring your project according to its conventions, but if you already have your own structure in place it's a lot less advantageous.
maybe something to make sure automatic tests pass as part of the check-in process?
I'd advise against it. Most of the time the tests will be passing (or should be, anyway) As long as continuous integration notifies you quickly of failures, and you also have stable automated builds (a couple of days' worth of nightly builds, tagged iteration builds, etc.), you want more and faster checkins, not fewer and slower.
Subversion is not a distributed approach -- go for Mercurial, Bazaar or git instead!
Yes, Trac does do bug tracking (among other things -- check it out!).
Documentation is indeed a must but I'm not sure what you're asking -- tools for it? Why not just javadoc?
For communication you can have many tools, such as skype, email, IM of many kinds, and so forth -- you need to express your specific issues better to get specific advice, I think. Google Wave once it matures may be just great, but it's not production-ready yet.
For continuous build check out CruiseControl -- of course it also run tests &c.
You can write "triggers" for any of the build systems I've mentioned (and even good old svn;-) to run some test suite and reject the commit if it fails.
A few more items:
IDE
Billing Software - will you be charging by the
hour? If so you might want to track
what your time is going towards.
offsite backup of some kind.
Each one of your bullet points is probably worthy of a community wiki by themselves. Though in the end you might not care so much about best of breed in each area, but care more about how well they all integrate with your IDE or with each other.
Also, if you really want to get new teammates up and running quickly, consider putting as much of your dev environment into source control as you can, so you can just checkout your "dev-env" project onto a new computer and be up and running instantly!
One of your specs (in your question) says:
maybe something to make sure automatic
tests pass as part of the check-in
process?
I would suggest this is essential. Check out this matrix of continuous integration servers to see which one fits your requirements.
If you're starting off with just yourself as the only developer but scaling up at some point, depending on what it is you're developing, it might be worth to check out a Platform as a Service (PaaS) offering, like https://www.openshift.com or https://www.heroku.com/, both which offer developer accounts, but you can scale up to paid accounts as and when needed.
OpenShift have CI cartridges for Jenkins so you can spin up DVCS (git), CI using Jenkins, and an app server like JBoss AS or WildFly all in one go in a matter of minutes... depending on your needs and how much time you want to dedicate to setting this up yourself locally, I'd be more inclined to look at using a PaaS.
Rather than use Trac, consider Redmine. It allows you to have multiple projects stored in the one issue tracking system. You can then use the same setup for each project, rather than having to have N instances of Trac.
For starters, SVN will be enough for you. Definitely get a bugtracker. JIRA is good but isn't free. Enforce a rule "No commits without a bugtrecker ticket". This way you will be able to track the development. Do a cruise control and run a build + unit tests after every checkin into the main branch. Bigger changes should be made on a separate branch and then merged into the main branch.
Invest in a good IDE (I recommend intelliJ IDEA) and a good profiler (I recommend JProfiler). They're not free, but they are definitely worth their price.
Just wondering if any of you are using Git or Mercurial for your Java projects, or is Subversion still the most popular choice? I've been looking at github.com and bitbucket.org lately, but because the repositories might be private, I can't get a good indication of actual usage.
Be careful.
Do you remember how you felt about CVS after you used subversion?
You'll feel exactly the same way about subversion if you use git/mercurial.
Yeah, sure, you drop in for Christmas and the odd weekend,
but you can never go home again.
I don't think language should come into the equation. Both Mercurial and Git are functionally similar and conceptually very different than Subversion. It's more important that you select the right flavour of version control for the way you want to work.
As it happens, I use Mercurial with Java. I use Netbeans as my IDE which has built in support for both Mercurial and Subversion - both work well. I can highly recommend Bitbucket too.
After being fed up by the useless Subversion ignore filters my company moved one project to Mercurial. A couple of months later we'd moved all our code (mostly Java) over to Mercurial repos. Every second weekend we're now dancing naked around burning .svn folders chanting and screaming. Branching and merging is so much smoother than with Subversion. And it's really nice to work against a lightning fast local repo.
I suspect that there are more projects out there using Subversion than Git and Mercurial, but the trend seems to be going towards distributed version control systems.
Github also sells private hosting and it works really well. To view the available packages, go to your account page and click on Change Plan on the top right (In the Your Plan box). Github is often times the reason people try out and eventually stick with Git.
If you would like to see how Git compares to other version control systems, there is no better suited site than this one: Why Git is Better than X (Coincidentally, that site's source is on GitHub; there's a link to it at the bottom of the page).
I don't think that the language you are using for your project matters much. I've recently switched to Git and I'm still pretty new to it, but it really seems to make a lot of sense. I'm really liking the whole idea that every repository is a clone of each other, instead of having one central repository which would not allow you to work while offline (As is the case with Subversion). Despite the fact that most people nowadays always have internet access, it's also nice to know that there really isn't a single point of failure (Unless there is a single point to begin with, which there wouldn't be if you had hosting at Github for example, or as long as you had two repositories).
In the end I don't think it should be about choosing what is most popular (Which recently seems to be Git) but what works for you. I think most developers are beginning to move to a Distributed Version Control System like Git or Mercurial, and it seems like more are joining the Git camp, which will most likely mean that you will find more guides, tools, etc. for it, especially as more and more people continue to switch to it.
The crucial point for us is IDE support which needs to be rock solid. We are a small shop and do not have resources to deal with little annoyances (which is also why we are still on CVS, as we need as good IDE support as CVS before switching).
I believe others feel the same. The source repository is so crucial that any migration must be painless AND give benefits.
Personally, I believe the Sun endorsement of Mercurial will benefit it enormeously, perhaps into being a new defacto standard
Subversion is the best solution when it comes to solid IDE integration as every Java IDE supports it and Mercurial should be well suited for Netbeans users as the dev team of NB uses it as its source control.
Git just doesn't offer any advantage over Mercurial, only lack of Windows support and less tool support in general.
We're doing development for both .NET (Using VS 2008) and Java (using eclipse)
Currently, we're using CVS, but there isn't really a good plugin for Visual Studio 2008, so I'm looking at changing to something that has better support for VS 2008 and Eclipse.
My initial thought was SVN, as it is really close to CVS, but I'm a bit tempted to use something like Mercurial. I'm looking for something that is simple to use, and has good plug-in support for both platforms.
I can tell you that there are really nice plugins for Subversion for Eclipse and Visual Studio 2008 (AnkhSVN for Visual Studio).
You have to make sure to download the daily builds of AnkhSVN if you plan to use it with the most recent subversion version.
Additionally there are tools (http://cvs2svn.tigris.org/) to migrate your data from CSV to SVN.
For Mercurial oder Git - I don't have got any experience with those.
I think SVN will give you the smoothest transision - but it won't give you the "big revolution" (if this is what you are after)
We're a .NET, Java, and Rails shop
We used Subversion for years and its a fantastic system, did everything we thought we needed from an SCM. About 9 months ago we started playing around with Github.com whilst developing a Rails application (unavoidable in the Rails community).
Since then we've shifted over to Github.com completely using private repos for our closed-source commercial software developments.
Git has made us not break a build or clobber code in months - something that used to happen from time to time and made us loose a day's work trying to rectify the problem. Subversion doesn't provide you with the flexibility in your working methods that Git does. If you're in trouble (a broken build or a hot fix), Subversion won't help you it'll even work against you. Its branch/merge mechanism is very difficult to use because it doesn't keep track of the origin of the branch. Also when you merge back, your change history is modified such that all changes by the team in a particular branch are attributed to the user performing the merge. Git is also lightning fast as the whole repo that you work on is local, something that is very noticable when you're working from remote locations.
That said, Subversion will take you a week or two to get proficient in, Git takes at least a month, especially if you're coming from Subversion or CVS. If you pretend its just a more modern SVN or CVS, you'll get frustrated by the lack of improvement in your coding workflow and you'll become annoyed by the multitude of commands.
We have a 3-branch setup: hotfix<->master<->development. In normal conditions the dev team will work in the development branch. For each user story the developer will create a branch off development: development<->user story. When the story is finished the user story is merged with development and the user story branch may be deleted. This goes on and on, and master stays stable and unaffected until the build manager decides its safe to merge all the changes in development back into master. If in the mean time a customer phones and requires a hotfix, that too is done in isolation from master and can be merged into the rest of the codebase (master&development) at a suitable point in the future.
Now wrt to GUIs and SCM. We avoid them like the plague. GUIs are bad for working with SCMs. I know - controversial, but hear me out. The command line will slow you down more than a GUI does and when you're working with an SCM and there's a high-chance that you're going to do something bad or destructive to your central repo, slow is a good thing. Slow makes you think about your actions. All the typical GUIs that I've seen (EclipseSVN, TortoiseGit/SVN) all preselect your recent changes as being part of the commit you're about to make, whether those changes are ready to be committed or not. BAD!!!! You need to think about your commits and how lumpy or granular they need to be - command lines do a better job than GUIs in this regard.
All our .NET coders, who are naturally drawn to performing tasks via GUIs, use command line Git and used command line SVN before that, just for those reasons outlined above. It gave them a greater sense of control.
VisualSVN client for Visual
Studio
SubClipse for Eclipse
VisualSVN Server for the server
Having used svn with both Eclipse and Visual Studio, I find that the eclipse plugins (especially subversive) are generally more seamlessly integrated into the IDE. Ankh and VisualSVN both do a very good job, but I tend to prefer ToirtoiseSVN when working with .net. In Eclipse I almost never resort to ToirtoiseSVN.
To be honest though, I think the IDE plugin shouldn't drive your decision too much.
We use both VSS (and now subversion) for both J2EE and .NET on different projects. Both seem to work OK.
Why are you so hung up on IDE pulgins? Personally, I could take'em or leav'em... I put them in the "kitch which doesn't add any real value" bucket.
Cheers. Keith.
There is an ongoing debate between AnkhSVN and VisualSVN, if you decide to go with SVN.
Personally, I like Ankh. It is free, more intuitive for me, and provides more useful feedback on my project's state. I have had some corruption issues, though, but nothing that cost me more than a few minutes.
I use Vault from SourceGear. It's simple to use and has great IDE integration with Visual Studio and Eclipse. It's also fully tested on Linux using Mono.
It's free to use for single users, so you can try before you buy.
Check it out and see what you think. http://www.sourcegear.com/vault/
Personally, I like Perforce. Not free, but cross-platform and very good.
I'm no expert on this, but I have been woefully underwhelmed at GUI, or IDE SCM extensions. I've been using SVN, and GIT fairly nicely with projects hosted on sourceforge. My 2 cents worth. CHEERS!
Try Plastic SCM working on Linux, Mac and Windows. GUI based replication, branch explorer, efficient branching and merging (merge tracking included, move and renames too), ACL based security...
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
Is Eclipse the best IDE for Java?
If not, is there something better?
I want to know and possibly try it out. Thanks.
Let me just start out by saying that Eclipse is a fantastic IDE for Java and many other languages. Its plugin architecture and its extensibility are hard to rival and the fact that it's free is a huge plus for smaller teams or tight budgets.
A few things that I hate about Eclipse.
The documentation is really lacking. I don't know who writes the stuff, but if it's not just flatly missing, it's incomplete. If it's not incomplete, then it's just flat out wrong. I have wasted many precious hours trying to use a given feature in Eclipse by walking through its documentation only to discover that it was all trash to begin with.
Despite the size of the project, I have found the community to be very lacking and/or confusing enough to be hard to participate in. I have tried several times to get help on a particular subject or plugin only to be sent to 3 or 4 different newsgroups who all point to the other newsgroup or just plain don't respond. This can be very frustrating, as much smaller open source products that I use are really good about answering questions I have. Perhaps it's simply a function of the size of the community.
If you need functionality beyond the bundled functionality of one of their distros (for instance, the Eclipse for Java EE Developers distro which bundles things like the WTP), I have found the installation process for extra plugins excruciatingly painful. I don't know why they can't make that process simpler (or maybe I'm just spoiled on my Mac at home and don't know how bad it really is out in the 'real' world) but if I'm not just unsuccessful, oftentimes it's a process of multiple hours to get a new plugin installed. This was supposedly one of their goals in 3.4 (to make installation of new projects simpler); if they succeeded, I can't tell.
Documentation in the form of books and actual tutorials is sorely lacking. I want a master walkthrough for something as dense and feature-rich as Eclipse; something that says, 'hey, did you know about this feature and how it can really make you more productive?'. As far as I've found, nothing like that exists. If you want to figure out Eclipse, you've got one option, sit down and play with it (literally play with it, not just see a feature and go and read the documentation for it, because that probably doesn't exist or is wrong).
Despite these things, Eclipse really is a great IDE. Its refactoring tooling works tremendously well. The handling of Javadoc works perfectly. All of features we've come to expect of an IDE are their (code completion, templates, integration with various SCMSs, integration with build systems). Its code formatting and cleanup tools are very powerful. I find its build system to work well and intuitively. I think these are the things upon which its reputation is really built.
I don't have enough experience with other IDEs or with other distros of Eclipse (I've seen RAD at work quite a few times; I can't believe anyone would pay what they're charging for that) to comment on them, but I've been quite happy with Eclipse for the most part. One tip I have heard from multiple places is that if you want Eclipse without a lot of the hassle that can come with its straight install, go with a for-pay distro of it. My Eclipse is a highly recommended version that I've seen all over the net that is really very affordable (last I heard, $50 for the distro plus a year of free upgrades). If you have the budget and need the added functionality, I'd go with something like that.
Anyway, I've tried to be as detailed as I can. I hope this helps and good luck on your search! :)
IntelliJ IDEA was awsome. Now it is just "better than Eclipse". You can code in IDEA several times faster than in Eclipse in my experience (I moved from being an Eclipse early-adopter to IDEA and haven't looked back) but IDEA has a number of flaws:
Full version is not free.
It hogs memory
Project management is not great
Jetbrains keep bringing out minor
enhancements and calling them major
releases. IDEA is now slower and
buggier than it was a few years ago.
And you get charged for the
pleasure! (IDEA now has a free Community Edition)
I still wouldn't go back though; the code refactorings and intentions in IDEA are just too good.
A major version of Eclipse came out a while back and it took me about an hour of searching on the website to figure out what was actually contained in the release which might persuade me back into the fold. Visit JetBrains to see how to sell an IDE!
There is no best IDE. You make it as good as you get used using it.
Eclipse can't remotely be called an IDE to my opinion. Okay that's exaggerated, I know. It merely reflects my intense agony thanks to eclipse! Whatever you do, it just doesn't work! You always need to fight with it to make it do things the right way. During that time, you're not developing code which is what you're supposed to do, right? eclipse and maven integration: unreliable! Eclipse and ivy integration: unreliable. WTP: buggy buggy buggy! Eclipse and wstl validation: buggy! It complains about not finding URL's out of the blue even though they do exist, and a few days later, without having changed them, it suddenly does find them etc etc. I Could write a frakking book about it. To answer your question: NO ECLIPSE IS NOT EVEN CLOSE THE BEST IDE!!! IntelliJ is supposed to be MUCH better!
Eclipse was the first IDE to move me off of XEmacs. However, when my employer offered to buy me a Intellij IDEA license if I wanted one it only took 3 days with an evaluation copy to convince me to go for it.
It seems like so many small things are just nicer.
IntelliJ is good one but its not free!!Then NetBeans is also a good option.Also if you are IBM suite WSAD is good
I'd have to vote for Netbeans as the best one currently. Eclipse is decent, but right now Netbeans is better.
I used IntelliJ for almost 5+ years (from v1.5 to v7) and around 8 months ago I migrated to IBM RAD (which is built on top of old eclipse platform) and around 3 months ago I settled down with Eclipse (Ganymede).
I used IntelliJ on a mid size projects (with 10k classes) and I'm using Eclipse on one with just few hundreds of classes.
I found both of these IDEs (IntelliJ and Eclipse) to be good. IBM RAD is just a waste of money (ofcourse one could be stuck in an IBM shop without choice).
IntelliJ has far superior refactoring capabilities and keyboard shortcuts for most of the features compared to Eclipse. It supports importing projects from Eclipse. It has better built in xml handling capabilities (with refactorings applicable almost like for the java code). Built in Intelli Sense is also very good.
Eclipse is a great tool and its free. It took me around 1-2 months to get used to Eclipse from IntelliJ (lot of unlearning of shortcuts), but I got hang of Eclipse, it has been pretty smooth. I havent used Eclipse on mid size project.
Both IntelliJ and Eclipse have active plugin communities and both integrate well with version control systems, unit test frameworks, application servers and profilers.
IntelliJ started becoming slow and bloated starting from v4.0. It was slow with mid size projects. I would not use IntelliJ unless its performance can be improved.
I havent used these two IDEs for anything other than java development.
If you are a java developer and your company pays for IntelliJ and if your project is not too big, go for it. Otherwise, dont despair: Eclipse is always there.
I gave Eclipse a 3 months ride at my new work, but after that I found out that normal Maven project can be run in IntelliJ IDEA too (unless it's Eclipse plugin/EMF/something of course ;-)). 3 months are not enough to compare it with 8+ years with IDEA, but it's enough to claim I gave it a fair try. I decided to live with its perspectives (other IDEs don't need them), with its poor debugger (doesn't show date values unless you click on them! etc.), with its comparatively worse completion than IDEA has.
Now after all those years IDEA is also free (community edition) and I use it without much trouble. Of course I miss some of those "Ultimate" features of paid version, but it's far better than Eclipse. Biggest difference is the whole mindset needed for both of these IDEs. But after you master the mindset of either I can't understand what can anyone hold to Eclipse - unless you need its plugin ecosystem or you have some serious investments there.
Example of "mindset" differences: You have to save in Eclipse, not in IDEA, and I don't care what is better or worse - but you have to save in Eclipse to let him clean up underlined errors that are not errors anymore, etc. ;-) You have to save there in order to get rid of errors in other files too, because other file doesn't see the changes otherwise.
I blogged much more about this topic - and yes, I'm biased, though I tried to be as little as possible. But after some time it wasn't simply possible: :-)
http://virgo47.wordpress.com/2011/01/30/eclipse-vs-intellij-idea/
http://virgo47.wordpress.com/2011/02/22/from-intellij-idea-to-eclipse-2/
http://virgo47.wordpress.com/2011/03/24/from-intellij-idea-to-eclipse-3/
http://virgo47.wordpress.com/2011/04/10/from-intellij-idea-to-eclipse-4/
And no, not even IDEA is perfect, I know it. Because I use it a lot. But it is the best Java IDE if you ask me. Even the Community edition.
[This is not really an answer, just an anecdote. I worked with guys who used emacs heavily loaded with macros and color coded. Crazy! Why do that when there are so many good IDEs out there?]
if you know you way around emacs you can code 100x faster then an IDE. And it can handle bunch of diffrent languages so you do not need to change your coding enviroment if you need to code in another language. Works on all operating systems, you can custimize/add anything you want. Even edit files half way across the world over ssh.(no downloading or uploading).
Before calling them crazy you gotto use it first. i am sure they are calling you crazy for using an IDE :).
It is often said that there are better IDE's for various languages (eg Java) than Eclipse.
The power of Eclipse is that it's basically the same IDE for many languages, meaning that if you know you'll have to code in several programming languages (Java, C++, Python) it's a huge advantage that you only have to learn one IDE: Eclipse.
Eclipse! It can be slow at times and uses a lot of memory but it works well.
I don't know if Eclipse is THE BEST Java IDE, but it is definitely very decent and my favorite IDE. I tried IntelliJ briefly before, and found that it's pretty similar to Eclipse (IntelliJ might offer some nicer features, but Eclipse is free and open source).
I never really tried NetBean because I know Eclipse before I know NetBean.
Eclipse is my favorite because:
Free
Extensible (to a point that you can turn it in to C++ IDE or DB Development IDE)
Open source
I know how to write Eclipse plugin
You can develop a product easily with Eclipse (exp. Lime Wire is Eclipse under the hood)
If you are used to using conventional Java IDE like JCreator you might need some time to get used to Eclipse. I remember when I first learned Eclipse, I didn't know how to compile Java source...
I would suggest that in order to find the best IDE FOR YOU, try what people recommended (NetBean, Eclipse, and IntelliJ), and see which one you like the most, then stick with it and become an expert of it. Having the right IDE will boost up your productivity a lot in my opinion.
I am going to have to recommend Oracle JDeveloper. I personally thought that Eclipse was the best Java IDE too at one point. Then I was introduced to Oracle JDeveloper by my job. I find the UI design much better than Eclipse. Also it comes with an incredible amount of features built in including great support for EJB3, JSF, WebServices, etc. It is essentially an IDE for the entire JavaEE stack (and the Oracle ADF framework as well). - All of the tools you will (probably) need for JavaEE development come with this IDE right out of the box, no plugins required (unless you download the minimalist version).
Talking about java Ide it is better to go for NetBeans.In My opinion it is better and provide great advantage over other ide but it has disadvantage over Eclipse that it grabs more more while working but do to its features and support i suggest Netbeans than any ide
Agreeing with the others. Netbeans is a pretty good IDE which also caters for other languages (PHP, Ruby, C/C++) if you're prone to using any of those. Then you get the added benefit of knowing your way around the IDE when deciding to pick up a new language.
To be fair however, I haven't had much time with the eclipse IDE.
This is subjective... I find it to be a good tool.
It depends what kind of development you're doing - for EJB stuff, many folk would favour Netbeans. It also depends how much you want to spend - I assume you're talking about free IDEs?
In my opinion if you got the resources to use, then go with eclipse. NetBeans which is awesome like eclipse is another best option, these are the only 2 I've ever used (loved, needed, wanted)
Eclipse is hands down the most popular, and for good reason!
Hope this helps.
I'd agree with some of the others out there saying that NetBeans and IntelliJ are both good IDEs. And I'd say that in using all three (Eclipse + other two), that Eclipse is by far my favorite. I found some of the documentation out-dated, but also found the support community very helpful. I started using Eclipse by jumping into the deep end of the pool: writing an RCP before ever learning the IDE. The IDE was intuitive to use, and when I found the right news groups to post to - most of my questions were already answered. The hardest thing for me (and frustrating, admittedly) was knowing how to phrase my search terms in order to get to the answer that was already posted.
Remember that Eclipse is still "relatively new" as an IDE player, though given that - it's pretty darn robust.
My only complaint about Eclipse is that with each new release, it seems to hog up more resources. With a mid-sized project/workspace, it takes seemingly forever to build (or rebuild) the project. Compared to IntelliJ, it's faster and more intuitive to use.
Don't forget that Eclipse Platform was started by IBM. There are few platforms out there.
IBM Websphere Application Developer
(WSAD) and/or Rational Application
Developer (RAD) which is a
Eclipse-type IDE from IBM (actually,
that's Eclipse with IBM specialized
libraries/plugins).
MyEclipse (never used it but it's another Eclipse-type IDE)
Sun Microsystem's
NetBeans. It's too Java-centric as
it's designed to create applications
purely in java (NetBeans runs in
Java).
IntelliJ (to name but a few)
Oracle JDeveloper (I never really liked the directory structure layout JDeveloper creates).
The advantage with Eclipse is that it can be customized to your development pleasure, plugins can be written for Eclipse to conform to your needs (e.g. The Eclipse "Easy Explorer" plugin for browsing the directory of your source in Windows Explorer).
Eclipse allows you to also incorporate other languages/SDK's, such as C++, Silverlight projects, Android Projects for development. You can also easily manage resources in Eclipse.
In my experience NetBeans are resource intensive. Oracle JDeveloper and IntelliJ aren't free though.
Oh yes, If you have issues or bugs with Eclipse, Eclipse has the ability to restart and submit the crash to Eclipse servers.
This is not really an answer, just an anecdote. I worked with guys who used emacs heavily loaded with macros and color coded. Crazy! Why do that when there are so many good IDEs out there?
I have experience with using JCreator LE. I like it because it is easy to use and it is free. Give it a try if it interests you.