Project Management in Java: A Confused .NET Developer’s Perspective

When I was first introduced to workplace Java the amount of ways one could define a project appeared to be restrictive, confusing and a point of frequent friction. While those things may all be true, it’s a great deal better than I would have expected since I was coming from a world where an upgrade to a newer version of Visual Studio requires your whole team to sync up to that same version!  So how do cross IDEA teams get any work done in the Java workplace? Do Java OSS projects require everyone uses Eclipse, NetBeans, or IntelliJ?  Does every new IDE need to have import/export filters for all of the other existing ones and if it becomes popular do the already present IDE’s have to include this? Which system is the best and what matters?

To answer these questions let break down what makes a project and while doing so compare and contrast the Java perspective with the .NET one.


Java IDE’s (Intellij/Eclipse/Netbeans) – basically run “make” on the fly and pass everything to javac.

JAVA IDE (Maven, Gradle) -agnostic project systems – adding all the references contained directly to the classpath and then calling javac.

.NET (Visual Studio,MSBuild)  – MSBuild feeds all references to csc.

In summary, there is more similar than different here.

Strong Versioning

Java IDE’s – at least in the case of IntelliJ I ended up manually writing a MANIFEST.MF file.

Java IDE-agnostic project systems – still manual editing a lot of the time but usually just one line already filled out by your template that you edit.  I know NetBeans gives you a GUI to edit this.

.NET – GUI but you can manually edit an assembly.cs file.

In summary,  Java IDE’s at least in the case of IntelliJ really are using default Java by hand stuff.


Java IDE’s  – All use convention! Basically, search for jar files in your source tree, if the IDE finds them it assumes you need them and adds them as references in your project format. Works pretty nice on a whole and allows for manual tweaking in the oddball cases.

Java IDE – agnostic project systems  – requires explicit dependency reference by version, however they will download them automatically from remote locations and put them in your file-system in a specific way (defined by them unless overridden by you). Since both of these are also responsible for your compilation you have to basically run everything through them or your IDE has to be aware of them.

.NET – requires explicit reference to DLL’s on the file system.

In summary, .NET and the Java IDE-agnostic systems are VERY similar here in approach, whereas the Java IDE’s take a convention over configuration approach. I’d say there are times I definitely prefer the Java IDE approach and there are times the capabilities of the Java IDE-agnostic systems are worth it.

Source References

All Java solutions – do reference by directory structure and wild card matching.

.NET – explicit references to each class file .

In summary, this is the HUGE difference. Java takes more of a Make based approach where it’s EXPECTED this will not be the only IDE/project system ever used on this source tree, and this is where the Visual Studio/.NET experience starts to fall apart when trying to use cross-ide’s or versions. It has forced everyone to implement and keep up with MSBuild’s format to enable other IDE’s to be used, and don’t talk about actual alternatives to MSBuild. At this point even though things like NAnt and Rake/Albacore are more popular among agile .NET teams than scripting MSBuild almost all of those scripts still call MSBuild to do the compile step!

Questions Answered

Q. How do Java OSS projects deal with all the different IDE’s out there and even different project formats?/How do cross IDE teams get work done?

A. They don’t have to worry about it as much as .NET devs. A friend of mine who a lead contributor to the Apache Cassandra project in fact included a Maven file for the “enterprise types” but by and large use Ant’s to do their builds and he himself has used a number of IDE’s on that same codebase. .NET OSS development is still a bit hamstrung by MSBuild and really alternative IDE’s are keeping in sync with that project management format. There are real problems with style and code format guidelines, but there are usually workarounds or ways of solving this if code style guidelines is something you really care about ( which I don’t).

Q. Which system is the best?

A. There is no one size fits all answer here. I now know Apache Maven solves some problems for people and even though I don’t appreciate it’s approach to things, it’s done some valuable good for the community.  The IDE-centric approach really works pretty well a lot of the time for projects. Gradle, while being the closest to what I want is very young and has limited IDE support, at least it’s not easy enough for this Java n00b to figure out how to use with IntelliJ without some friction.


I hope that all wasn’t too confusing, it sure was for me to go through while I had all these options , and in a completely different environment to what I was used to. Worse a lot of the folks I talked to saw these IDE-agnostic project systems as solving problems they didn’t have. Maven, Ivy, etc was a world that was buzzword laden (I’m really looking at you Maven and Ivy), involved heavy setup time for relatively simple tasks, incomplete documentation (looking at you Gradle) and was frequently badly misused (those who know me know what I’m referring too here). In the end an IDE-centric approach in the Java world does not seem to tie you to that IDE in any way I can find, and for getting started had little friction, and for people new to Java it seemed to be the best way to get started. Besides in Java at least it’s easy to change your mind later.

About Ryan Svihla

I consider myself a full stack polyglot, and I have been writing a lot of JS and Ruby as of late. Currently, I'm a solutions architect at DataStax
This entry was posted in Ivy, Java, Maven, MSBuild. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • That was a bit Confusing :(

  • Troy

    I read your post having somewhat similar hands on experience. It seems clear. But as I read @Senthil Kumar B’s comment, my mind quickly traced my path of discovery. And I realized if I didn’t have that experience, this high-points-only overview could likely be confusing.

    Personally, I appreciated the post as a good overview. But, without personal experience, there’s several weeks of discovery in there to follow it.

    I’ve spent about a month in IntelliJ, a few weeks in Net Beans, a week or so in Eclipse. All were good experiences.

    Getting one’s head wrapped around how dependencies work is very normalized between each IDE. It is mostly a search for where to do the same thing in each particular IDE. My day job is .NET. I’d say, on the whole, that language differences and hardware differences are the biggest factors that steer my preferences. I’ve only used c# 4 experimentally, but with great pleasure. I feel lost without extension methods in java, but any non-sealed class can be extended to get fluent methods–yet, it’s a little more work. It may be my general experience, but I typically find communication between dissimilar boxes less painful in the .NET arena.

  • @Troy good comments and I appreciate the feedback. Java is nowadays my day job, so I really wanted to dive into it. I at least need to be able to “speak Java” enough to fit in and not have my ideas discounted as “oh it’s just a DotNet guy”. In the process I certainly dove into waves of competing perspectives and approaches, and most of them not in straightforward comparisons.

    Also from a purely language perspective, C# 3.5 was pretty awesome compared to the current state of Java, and from a community point of view I still prefer Alt.Net to anything I’ve found in the Java community.

    End of the day though languages are interesting it’s really the interesting people and different perspectives on solving problems that make all of this worthwhile for me .

  • Eddie Garmon

    You must not understand MSBuild at all. You can do everything you said a java IDE does, but you must understand its syntax. As far as needing a GUI to edit a build script, they (the GUIs) are only good for trivial tasks in pretty much any IDE. A specialized build file editor (not an IDE) is another story completely.

  • @Eddie
    In the article I’m in no way discussing MSBuild as a scripting language at all. You’ll note I did not make a mention of Ant. Visual studio does behave the way I have stated. Add a new class, and the MSBuild file created by visual studio aka .proj will actually add a line for that class and where it is located. MSBuild will be called for compilation.

    Open up any Java IDE with a directory structure (with no project format) and a Java project for that IDE will be created on the fly and all the libs and .java files will be referenced and added to the compile list. Do the same in Visual and you have a .proj with no files.

  • Eddie Garmon

    Truely speaking, VS project files are MSBuild files, no way around it. You can add a [Compile Include="**\*.cs"] element to do exactly what you are talking about.

  • @Eddie I understand MSBuild is a fuller scripting language, and again I’m not referring to that. Let me put it this way in any of the above things I’ve covered I’ve never had to put a [compile.**/*.java]. I have in Ant and **/*.cs in the csc task in NAnt, which again I’m not going over the scripting option but viewing these things as a Project Management format.

    Now I’m going to admit I have not used MSBuild for scripting other than the most minor items , so my question is once you’ve marked that setting will Visual Studio see all included files? For example in Intellij, it has an exclude list instead of an include list (and just a source directory location), if you can get Visual Studio to exhibit that behavior, well awesome and I wish they did that by default, then you could not bother to check in the .proj and .sln files and all and everything would be fine and you could easily have cross version IDE teams, plus it would have prevented TONS of needless source tree conflicts when two people added a different class via the wizard and it added it to the same line in .proj file.

    I understand the this is not a straight apples to apples comparison and this is in part what I was trying to highlight in the article. MSbuild is part NAnt and Project Management, and it can be used for both or either. Hence my complete confusion when I entered the Java world.