Discussion on:

Why Java and .NET will continue to compete

In my experience maintenance costs have far outweighed acquisition costs. I'm sure I share this point of view with many others out there.

For me .NET is too tied up to the OS and too tied up with Microsoft's upgrade path to be cost effective. I moved away from the Microsoft development platform a few years back. After seeing the amount of work needed to keep up with changing OS versions I moved to web development. ASP provided some help, but then changes and more changes and orphaned projects made with Microsoft's Java tools left me thinking. Is it worth the trouble to keep investing my time in learning these tools?

Microsoft's tools are very "now" oriented. They focus on rolling something out fast. They're very graphic and very drag and drop. When I started with Java there was nothing like this. It was a strong learning curve, but it provided me with a long term platform. Then came the VB6 to .NET change and I could see the problems unfolding. I realized that the time invested in Java was a good investment.

Over time I've concerned myself less with the language itself, more with the tools and even more so with project management and developing tools (centered around continuous integration). I'm happy I don't need to change my IDE every time a new update is made and that I can roll back to older versions and that old code can be easily maintained and utilized in new projects.

Maybe I've been out of touch with .NET development tools for too long, but my impression is that I can create more synergy with Java than .NET. I'm under the impression that every new release from Redmond forces a upgrade hop not seen in Java. Adding those hops due to Windows releases, .NET releases, Visual Studio releases and what not sums up to a bigger cost than switching to Java.

One of the things that I hear time and time again against .NET is that it moves too quickly. I agree that .NET moves too quickly if your intention is to always be fully leveraging the latest features. You'd spend more time learning and trying out new things than actually working. That being said, there is nothing *forcing* people to do this. The fact is, you can continue to upgrade the .NET CLR without development pain. In fact, .NET 3.0 and .NET 3.5 both use the .NET 2.0 CLR! They are really just massive library upgrades laid on top of .NET 2.0. In addition, changes to the base OS really do not require any changes to .NET code, unless you are doing something which is suddenly more restricted in the new OS, which will be a problem for you regardless of platform.

Java has the same problem, with the zillions of different frameworks and such out there, it just does not feel like as much of a problem because the base system does not change as often, and the changes are coming from third-parties. If you take a long-distance view of each system though, they are both changing at breakneck speeds and it is very difficult for a mere mortal developer to keep up with either one, other than doing giant leaps every few years.

J.Ja

I have never done web programming with Java, but I first programmed in it in 2005, 3 years after first using vb.net and c++ .net (2002/3 version).

While there is no inherent drag & drop in Java, there is in development tools like NetBeans. I had a college project where I used NetBeans to design the layout, then went back to TypePad and used the layout code. (TypePad was leaner for use on my home pc than was NetBeans.)

And there's always the way you use a tool that matters. I have never used the drag and drop feature for ASP.NET because 1) I don't believe in exact positioning with so many browsers and 2) it's too difficult to use the drag and drop interface to create a flow layout. If you know and understand the underlying html and know how asp.net controls are rendered, then you know how to construct a page using the .aspx source.

If you are referring only to a drag and drop interface for Windows apps, then yes, Visual Studio is nice enough to allow drag and drop and repositioning capabilities. But again, you need a development tool (IDE) to do this. The design-time rendering information is contained in the .NET Framework, but not the drag and drop functionality. If you use Notepad to code, for example, drag and drop is non-existent for the GUI.

And as Justin said, there is no requirement to upgrade. .NET 2.0+ runs on platforms from Windows 2k on, and all of the "upgrades" so far have been extensions which allow you to run in backward-compatibility mode. If you have .NET 3.5 installed on a server, it can run .NET 3.5, 3.0, 2.0, and in most cases, .NET 1.x code. Believe me when I say that .NET 2.0 is a welcome change from the way web stuff was done in 1.x, and the library upgrade was good for Windows programming, as well.

As for development tools, it is still possible to use Visual Studio .NET 2005 to program with the 3.5 framework, with a few modifications to the configuration files so that it uses the new 3.5 compiler.

Microsoft is even nice enough to provide us with upgrade tools for *when* you decide to upgrade. IIS 7 has a new integrated mode so no manual configurations are needed, and it has a tool that you can use to upgrade your old web.config to work in this new integrated mode.

For Windows apps, there is no need to upgrade unless the app now uses code from the new extension libraries.

.NET 2.0+ is a very good platform, and the improvements to the Visual Basic language have been well worth the upgrade (especially from VB6!).

I have not used any Java IDE tools other than Netbeans (minimally) and TypePad, so forgive me if there is something out there similar to Visual Studio's Intellisense. This is another area that makes the coding a lot easier through ease of reference navigation.

I do not intend to convert anybody to .NET, since I enjoy the Java language and its capabilities. However, readers do need to know that your assumptions are incorrect.

First I'll make clear my point is around cost of development using a Java solution compare to .NET and not about the pro and cons of both language (I'm using both a regular basis to develop complex solution and really a debate on which one is better really come down to: does blue a nicer color than orange).

So regarding cost, I've work with 5 Java shop companies in the past 10 years ranging from startup (5 employees) to super big (1000+) and none of them where using commercials software for their Java environment. I'm not kidding. So software cost (for Java tools, I'm excluding here database or OS license) was 0$. So I'm sorry but thats cheaper than Microsoft solution. And here again I'll not go into the topic of which one is better because again I'm using both on a regular basis and they simply have: temporal advantage.
Like you said it's just a matter of time before one implement the goodies of the other. If you try to argue on this topic it's going to be again a discussion on the topic of: does blue a nicer color than orange.

An organization where I recently did a project opted for .NET because it was easier to hire developers who were guaranteed to be familiar with the development environment. They found that not all Java developers were equal -- a developer who worked in a shop with different tools than the hiring organization would take a long time to come up to speed. They felt it was less expensive with faster time to market to go with .NET.

I was talking to Rod Johnson, the GM at SpringSource last week, and one of the things that we discussed was how the plethora of Java frameworks, tools, etc. hampers developer productivity. It's great in terms of innovation, but if you just want to sit down and learn Java, it's a mess. Not to mention that it dilutes the skills that people have, because they end up either learning a zillion frameworks for the same thing, or just know one, and it probably isn't the one your shop is using.

J.Ja

Your are right that .NET is highly consistent. It is consistent with what's out in the current Visual Studio. Which can be inconsistent with the not-current Visual Studio.

Which takes me back to the point of support and maintainability. If everyone is consistently using todays tools, who's using yesterdays tools to support and maintain yesterdays applications? If the current Visual Studio tools are the same as the not so current Visual Studio. Then where is the improvement? Did they [Microsoft] get it right the first time? Hardly so. No one does.

So there are changes in the tools. Changes to which .NET developers need to consistently adapt to so they remain relevant. Which makes their prior knowledge irrelevant and software support uninteresting. But what is important? The tool by which you achieve the goal or the essence of the goal, the understanding of the problem?

If understanding the problem is more important then the amount of tools and frameworks is of no concern. The problem will be solved regardless of the tool used and more so, the optimal tool can be selected from the pool of available tools. Because we understand the problem and can discriminate among the various options.

If the tool is more important than understanding the problem. Then the problem will be solved faster, but with lesser understanding. Probably leading to the existence of more solutions to many more problems that existed out there. Which were probably less understood, but solved faster.

What happens when the tool changes and you have a lot of quickly developed solutions? Solutions done with a tool that no longer exists or at least isn't consistent with today's skill set. Who is going to maintain them when everyone is interested in being consistent with tomorrow's Visual Studio?

Visual Studio is almost always QUITE behind! Visual Studio 2008 was released a full TWO YEARS after Vista introduced WPF. But what's VS2008's WPF support like? Miserable. That applies for a lot of other things too. The reality is, while Visual Studio is a fine IDE, particularly as far as things like IntelliSense go, it is usually at least 1 release behind .NET in terms of functionality that it supports well. Sure, it might "support" it in the most basic sense, but it really isn't "there" yet. That's one of the (many) reasons that .NET developers tend to take 3+ years to catch up to any given release.

J.Ja

Justin I think you've indirectly made my point and raised another one I had overseen. As I understand your post there is a lag between the introduction of certain features in Windows and their support in Visual Studio.

That for example is unheard of in Java. Having a toolset laying around for two years without a mainstream usage? Two years is the time it would take it to upgrade a whole version and no usage in that time means extinction.

This raises the question. Was nothing done with WPF in the meantime? Didn't Microsoft or anyone release anything using WPF? And if so what tool did they use given that VS 2005 didn't support it and VS 2008 wasn't out yet. Is there a mechanism for gradual upgrades? A means to support new Windows functionality as it comes out?

For example in Java if a new framework comes out all I have to do is download it and include it in the project. I don't need to upgrade to the next IDE release to support it. When Java FX came out all I had to do was add it as a plugin. As I understand from your post that can't be done with VS2005 and WPF. So modularity is another point to add which I seem to have missed.

Now regarding your point. Although VS is as you say "at least 1 release behind .NET", it is so across the globe. And being VS pretty much the defacto standard for .NET development it pretty much places the whole globe 1 release behind .NET. Adding the close source nature of VS to all this places us in a situation in which we are aware that there could be something better, but can't really do anything about it until the next release. So even if we can hypothesize of a soon to come improvement (as the MS marketing team will have us believe) the fact is we are stuck with today's release to get the real work done.

This pretty much drives my point. With "now" I mean getting today's work done now. I didn't mean getting it done with today's frameworks. As you clearly explain, getting it done with today's frameworks will happen "tomorrow" when the IDE catches up to .NET.

Today's work gets done with the well supported frameworks that took "3+ years to catch up" by the .NET developers. "Tomorrow's" work will be done with "tomorrow's" well supported frameworks(aka "today's" poorly supported frameworks). But "tomorrow" will find that "today's" work was "yesterday's" legacy. Legacy apps that were built with frameworks that took 3+ years to catch up to and would take some time to "catch down to" if those legacy apps need support. Leading to the maintenance issue I mentioned.

See my point and how you seem to support it? I is irrelevant that VS lags behind .NET by a year. For all practical purposes what VS supports is what .NET is. Because all other features are not generally usable. But when they are they spawn a new generation of applications that use those new features. And that defines the "steps" I mention which correlate with the 3+ year steps you mention.

.NET development is consistent across space, but not across time. At any given point in time .NET will be consistent across the globe because of the consistent usage of VS and the predominant supply of frameworks by Microsoft rather than third parties(like you mentioned in your other post). And this is perfectly understandable because Microsoft is in the business of providing a product and not a service. Thus it needs to sell more next year than it did this year. A good way to do that (as others have noted) is to redesign things like this.

From Microsoft's perspective as well as companies that crank out software for other companies this is great. As it ensures a healthy cash flow. But what benefit does it provide me as an end user who is trying to make money out of a service supported by said software. Unlike software companies that will want to crank it out and get paid as fast as possible. I want long term stability and long term "low costs".

The short term cost of being late to market is diluted over the long term cost of staying in the market. If I need to retouch, redevelop or remake my key applications every few years(because Microsoft says so) I'm loosing(repeatedly BTW). Because the resources invested in getting that version up to speed with the current development tools and frameworks could be put to better use developing the next major release.

By using .NET I can get developers which are consistent in their skill set, more available and thus cheaper. Thus leading to lower costs in doing those upgrades. But if I don't need to "upgrade to the next best thing" at all my savings are even greater.

... as interim updates, but it is usually quite spotty.

One thing you really need to keep in mind, is that in "enterprise development", the "latest and greatest" is rather feared. For example, it was only a year or two ago that many .NET shops moved to support generics, which were introduced in .NET 2.0 and supported in VS 2005. Likewise, cutting edge WPF adopters used a combination of the rudimentary update for VS 2005 (and the tools in VS 2008), hand coding (which is quite possible with WPF), and the Expression Blend tool, which is on a much faster release cycle than Visual Studio. So it isn't like no one can use the new functionality. But, you are quite right that for the *typical* .NET developer, if Visual Studio does not support it, it doesn't exist. Which many, if not most, shops don't see as a bad thing.

Most shops like to wait for a technology to shake out a bit, have the bugs and kinks worked out, and so on before commiting to it. They like to see if the system really lives up to the hype. And you know, this is not exactly a bad thing. Enterprise development prizes stability over innovation for the obvious reasons. It doesn't matter if your stuff comes from Microsoft, other vendor, or the open source community, corporate development is going to be cautious about new technologies.

By the by, this trend of Microsoft releasing frameworks and not having quality Visual Studio support until much later, that is something that started with the release of Vista and .NET 3.0. The gap from .NET 1.0 to 2.0 was long, roughly 4 years. That's a nice period of stability. .NET 2.0 to 3.0 was *not* long, 1 - 2 years. .NET 3.5 was even quicker. In the last two years since 3.5, we have been bombarded with all sorts of stuff, like 3 versions of Silverlight, the Entity Framework, ASP.NET MVC, and more.

Visual Studio 2010 is a giant "catch up" release that looks like it will actually support all of these items, and support them very well. Hopefully, VS2010 will be the foundation for the VS series to be able to be much more agile. For one thing, it is a substantial rewrite of the application. My beleif and sincere hope is that many of the issues you've mentioned with VS and .NET (like the need to "convert" VS projects in newer versions) are addressed, and that they are better able to support new frameworks more easily. The foundation of the previous VS was laid around 1999 or 2000 (remember, the first Visual Studio was released in 2001 or 2002!). The first was a different place then, particularly around release schedules. I think that the shift to Agile development really caught Microsoft off guard, and as some portions of the company (like the folks working on .NET frameworks and libraries) got it very quickly, other parts (OS teams, Visual Studio team) did not have products architected to work like that.

J.Ja

It's just a matter of time before the same thing happen in .NET.
C# like Java at the beginning were "bare bone" in the sense that both companies sponsor them are not providing too much frameworks. The community does it.
So give 5 more years to C# and this argument of "confusion of too many framework" will applied to C# as well.

Java frameworks don't differ so much and maybe there are zillions of frameworks, but how many of them are really important ...?
The main frameworks that come to my mind are: Struts, Hibernate, Spring and JSF.
Hibernate is extremely easy to use and the others have many things in common.

.Net is full of inconsistencies and many of them are in the CLR which has tons of trial classes that make it a pile of unnecessary and badly designed interfaces thzat do not even work correctly together.
What is worse is thet .Net developments do not even work as expected and without problems in the next version of .Net.
Even the whole naming stategy of .Net's CLR is inconsistent: too many capitals are used for things that are not types, and even some types have lowercases. This makes the sources unnecessarily difficult to read without having to always refer to the documentation.
In addition, the .Net development tools and IDE do not offer the same level of assistance to navigate in the giant and inconsistent CLR APIs.
I use both, and really I feel much more productive with the JVM (in addition the same code performs much beter in the JVM than on a .Net VM, and it is easier to deploy).
All the .Net really looks like a toy to play with to work on isolated niches within specific applications that don't support anything else.
Yes, may be there are some syntaxic sugar in .Net's languages (within them only C# is useful, C/C++ developement for .Net is really not C/C++ and the syntax is in fact more complex than traditional C/C++, and there's nothing to ensure that your code will be really safe: in C/C++ all is unsafe by default and does not work within the VM without lots of efforts, and too long debugging sessions.
In .Net, each time you think that you've done something right, the next version comes and you realize that the fundamentals for making your .Net classes secure have changed: even the most basic concept related to System.Object have failed several times: this is mostly due to the poor level of documentation made by Microsoft, which does not help making the concepts clear: even the examples given in MSDN are full of bugs for the most basic concepts: there's no consistancy for handling the persistance, integrating classes in fundamental bricks like Collections.
And finally, when you'll have to deploy your code, you'll only have one option: deploy to a Windows host, and experiment the difficulties when deploying to a server that does not have the same version of the VM!
This never happens in Java, which has stockpiled now two decenials of well-written and strong code that you can still reuse without changes: in .Net, what you did 4 years ago can be dropped, and debugged once again.

But a language is not everything: you have to also be productive in various frameworks. And frameworks for .Net are still very experimental (once again because of inconsistencies and instability of this platform across its versions: that's why tou need now to host several versions of .Net VMs on the same system, and why it's difficult to have several packages work together if they don't live in the same VM with the same .Net version).

If you look back at his post, he isn't talking about consistency within the .NET Framework or the CLR itself. He is very specifically talking about consistency *in the skillsets of programmers*, and his point is quite valid. Take ORM as an example. With Java, there are a large number of different ORM tools with significant market share, which makes it harder to find someone with experience in the ORM tool that your environment uses. In the .NET world, there are only one or two (usually just one, whatever Microsoft provides, for better or for worse) frameworks or libraries to do any given task, which makes it a lot easier to find someone experienced in what you are using.

You're remarks about the need to host different versions of the CLR are... well... mostly baseless, and certainly less true than the need for various JVMs has been in the past. The reason why different versions of the .NET CLR are needed is because code is compiled against a particular version (1.X or 2.0). 98% of code (if not more) that works on 1.X will recompile against 2.0 and run just fine with zero modification. But there are enough apps that no one ever recompiled/deployed to need both. Honestly, it is rare that I deploy .NET 1.X on machines now, and .NET 3.X are really just library supersets of 2.0.

J.Ja

Don't make me laugh. They prefer "consistent" developers?
translate: button-clickers, drag&droppers who cost $10/h and who have no idea what the FF00h means?


Java vs .NET is as democracy vs dictatorship.

Yes, it is easier to survive in dictatorship environment (I used to...)
You don't have to think much, you just have to follow the given directions.
No risk taking, no choice pain, etc, etc, i.e. no freedom.

Lets consider a simplest case for any real world developer juggling several projects and constantly experimenting -
Can you have several .net applications running in all versions of .Net at the same time on same computer?
And after that are you able to remove all stuff and make sure no leftovers and the computer is as clean as it was before?
Any application, once installed under the Windows, does irreparable changes to the OS.

Java is really flexible. Have a "zillions" of frameworks/libraries is really good. You are not tied, you have a freedom of choice.
Yes, it may be a bit of pain, you have to understand things deeper to make good choice.
Making a choice consciously is always more difficult than following the leader.


I do recall old time when VB6 first appeared and many people told that the rest of languages are destined to perish, because of drag&drop etc...
Where the VB6 now? Ha-ha! Let alone dead-born zombie like MS J++

It is very easy to create quickly an simple application using Microsoft technologies.
But its much harder to finish when the app gets really complex. It may get unmanageable even if designed well.


In Java it is vice versa. Very hard to start and create even simple app but much easier to finish and maintain when it grows huge.


C# is a new language embedded into old Microsoft philosophy. Where the marketing hype is always dictates.

Did I mention the irrefutable fact that a lot of ideas for .NET were just stolen?
Try to guess from which technology...

I don't care what language or system you prefer to work in, being able to find people with those skills is important when you decide to pick one for use. That's one reason why some languages never get much traction, despite obvious technical benefits; no one wants to take the risk of not being able to hire people who can work with them.

When the previous poster talked about "consistent developers", he was pretty specific in talking about this. Java's current situation, with a wide variety of frameworks competing for attention, may be great for innovation (and I really think it is, there is a reason why so many things like NHibernate are direct ports of frameworks that were in Java first), but it is lousy for skillset consistency.

J.Ja

Any shop that insists on hiring widget developers deserves to get burned in the long run. Any good developer should be able to adapt to a different environment if they understand the framework and they know how to think for themselves, just like a Football player can do well on another team if they understand the fundamentals. It doesn't matter that the playbook might be different.

In our shop we use both Java and .NET. We allow our developers to use whatever development tool they want to use for .NET and haven't had any problems. Some use SharpDevelop and others use Visual Studio.
All code goes to our Subversion respository to go through automatic continuous integration and testing.

The common build and test environment is what's standard. Any developer coming in will have to learn the procedure for checking in/out code, building, testing, etc. Same thing goes for Java.

My experience in the last 8 years was that as a very small it shop (at times max 3 developers) we have been much faster turning out new apps for our main customer with .NET / IIS that their own IT dept with their Unix/Linux based environment using Java. Now this could as well be due to us simply being the better developers (thanks for the applause) but I tend to think that it's somehow related to the .NET platform.

Anybody who developed hundred's of thousands of lines of code on VB and COM only to see Microsoft pull the plug on it will realize how important it is to invest in a stable development platform that doesn't rely on a single vendor.

more.

I mean if it worked forever, what would they sell next...

You can re-use COM in .net anyway, you just wrap it, whether it's effective or not is another question.

There's no such thing as a stable development environment, never has been, change is a given. You can have a static one of course.

Before everybody rewrite all their VB applications, they might as well go for hype.NEXT.

Much more commercial sense in investing in open source Java and a plugin-based open source development environment like Eclipse instead of rewriting all our software every five years because MS says so.

A senior java developer will be a senior .net developer, the day the switch happens. Being a senior devloper is not about language, I've interviewed guy with years of experience, who I wouldn't let program my VCR unsupervised.

The real step from one langauge/framework to another, is resisting the assumption that the old way is the right way. My trigger point for google et al is, this should be easier.

That's a senior developer.

Switching from java to .net or from language A to B, is a business decision, not a technical one. For mainstream business, any technical consideration would be trivial, and probably should be.

I've used both systems extensively. As a long-time VB6/VC++6 developer, I am agnostic about tools and platforms. I do lean towards Java for three reasons.

First, the development environments do more for you. Eclipse can be unwieldy, but it supplies a tremendous number of useful tools. Netbeans and JDeveloper and JetBrains have less tools, but are easier to maintain. All four supply more tools than Visual Developer, but VD 2008 and beyond is catching up.

Second, there are many more open source libraries that have not yet been ported to .NET. Some are not as necessary in the .NET environment, but many are still useful.

Finally, the .NET environment runs only on Microsoft Server. While this is a stable and very usable platform, it requires more money to set up than a Linux box with a Tomcat or JBoss web server. In these cash strapped times, this can be a big factor in new development opportunities.

One other thing not mentioned, at least I didn't catch it if it was, is developer productivity. It is my experience that two deveopers with similar experience, one a .NET developer and the other a Java developer will have different productivity. The .NET environment, including VS and IIS will be the more productive of the two thus there is cost savings in that the development time will be shorter in a .NET environment.

Good Read. Thanks Justin. I am a .NET developer, and played around in JAVA a bit, just feel that building Enterprise Applications in .NET is a tid bit easier and more organized. However, I don't have an extensive experience of JAVA to back my claim. People who grew in JAVA from the start might feel otherwise.