Java VS .NET

mikegoes101

Weaksauce
Joined
Jan 20, 2010
Messages
71
I have learned Java in School and .Net at work. Hands down I perfer .Net but what are your thoughts?
 
Some will argue ofc, but this is my opinion.

I prefer Java hands down, mainly because its cross platform but there's many other reasons, its easy, simple to handle.
 
I understand the cross platform, but anymore if you host a Java program that platform must be installed on the server hosted from so that it has the correct jar to access.
 
Lol, yes, its #1 on amount of Mobile games built on it (though theres a bit of a move from java with iPhones etc, but still, its top dog still)
 
Yea, I basically do windows/web development so .NET is the choice for me. I couldn't compare the two but thought Java died out...
 
Well both are valid points. For Mobile Applications on multiple platforms Java definitely has its importance however many new techs backed by android etc will make Suns Java less of a mainstay.

I find that .Net being integrated freely with Visual Studio and a fairly intuitive coding model its hard to show its flexibility especially with Database web apps.

Also if you are running Windows 7 you are already .Net reliant.
 
.NET is ALSO cross platform in the form of Silverlight, and it officially supported by Microsoft on the Mac and I think Microsoft has an agreement to do a Linux version.

At any rate, I think .NET isn't going anywhere any time soon. And neither is Java. Both have strenghts and weaknesses but if I were going to so something client web based and needed something beyond what I could get in AJAX, I'd look at Silverlight. Indeed, Silverlight can actually work just on top of AJAX if you want but it provides a MUCH cleaner development platform than AJAX libraries and framworks, at least not without some IDE tools for your AJAX development.

At any rate. .NET though is a much more straight forward platform overall but Java is definitely more platform neutral.
 
C# has better documentation. VB.NET is still the same horror VB6 was and to be avoided at all cost. Java as a language is lacking. I program mostly C++ professionally and the incredibly high-level approach taken in Java combined with its lacking implementation of OO makes for a rather painful experience. C# is much more to my liking in that regard.

.Net as a runtime doesn't really offer many benefits over running native, because you lose the ability to go cross-platform (the OSS Linux implementation isn't 100% compatible) and managed code can lead you into even worse minefields than regular unmanaged code, mostly because you can't see WTF it's doing behind the scenes. The Java VM has the same managed vs unmanaged issues, but as a VM it wins because it's cross-platform (any noticeable platform), very efficient and can run more than just Java (which the .NET runtime can do too, of course).

In the end most applications are still programmed in C/C++ :p
 
C# has better documentation. VB.NET is still the same horror VB6 was and to be avoided at all cost. Java as a language is lacking. I program mostly C++ professionally and the incredibly high-level approach taken in Java combined with its lacking implementation of OO makes for a rather painful experience. C# is much more to my liking in that regard.

.Net as a runtime doesn't really offer many benefits over running native, because you lose the ability to go cross-platform (the OSS Linux implementation isn't 100% compatible) and managed code can lead you into even worse minefields than regular unmanaged code, mostly because you can't see WTF it's doing behind the scenes. The Java VM has the same managed vs unmanaged issues, but as a VM it wins because it's cross-platform (any noticeable platform), very efficient and can run more than just Java (which the .NET runtime can do too, of course).

In the end most applications are still programmed in C/C++ :p

I'll conceed to the point that most apps still rely on C/C++ just look at vista. But compare Vista to Win7 and you see the power that .Net can bring
 
.NET

Is Java even being widely used anymore?

Java is very big in enterprise systems (in the form of JavaEE) and it has a strong showing in mobile platforms. It doesn't have a whole lot of visibility on the desktop. There is a huge market for JavaEE developers (I would hazard to guess that makes up the majority of Java related job postings) and the community is powered by some pretty big corporate players (IBM, Oracle, BEA, SAP, Redhat, Google, VMWare, Apache etc)
 
Last edited:
This topic, in some form, comes up every so often. From what I know, Java still has a higher utilization than .Net. But both are supported, documented, still being enhanced, and are popular in enterprise environments down to small shops. Much of it comes down to user preference, and what platform/technology roadmap the team chooses to follow -- .Net, Java, or otherwise.

Ignore any comments along the lines of "avoid VB.Net like the plague"; VB.Net is not VB6, both VB.Net and C#.Net go through the same CLR into MSIL, and (generally speaking) are only syntactical differences between C#.Net and VB.Net. There's a book I've mentioned before that highlights the more niche difference, but that is starting to show a little age as the C# and VB teams at MS tighten up things more and more.
 
As an Amazon Associate, HardForum may earn from qualifying purchases.
C# has better documentation. VB.NET is still the same horror VB6 was and to be avoided at all cost. Java as a language is lacking. I program mostly C++ professionally and the incredibly high-level approach taken in Java combined with its lacking implementation of OO makes for a rather painful experience. C# is much more to my liking in that regard.

Out of curiousity, what is Java lacking in OO implementation? Only know Java atm but I know it fairly well at this point. From the little I looked at c#, it looked similiar with the exception of being able to create seperate scopes pretty much anywhere and the whole struct thing. Oh, is it that java can only pass parameters by value? Dont know how that would fall into OO though.
 
Out of curiousity, what is Java lacking in OO implementation? Only know Java atm but I know it fairly well at this point. From the little I looked at c#, it looked similiar with the exception of being able to create seperate scopes pretty much anywhere and the whole struct thing. Oh, is it that java can only pass parameters by value? Dont know how that would fall into OO though.

If you mean anonymous methods, Java can do that too. In my experience, however, C# has the better programming conventions, and is just nicer to use than Java. I could do with either, but I hope in the long run, the most elegant language wins out (which currently is C#).
 
If you mean anonymous methods, Java can do that too. In my experience, however, C# has the better programming conventions, and is just nicer to use than Java. I could do with either, but I hope in the long run, the most elegant language wins out (which currently is C#).

Personally I'd rather the open language win out.

That being said though I don't think there will ever be a "winner" given the players on both sides.


Oh, is it that java can only pass parameters by value

Parameters in Java are all pass-by-reference. Primitives are immutable as are Strings.
 
Last edited:
C# has better documentation. VB.NET is still the same horror VB6 was and to be avoided at all cost.

Not true. Both have similiar feature sets and compile to the same IL. Comparing VB .NET and VB6 is ridiculous.

Ignore any comments along the lines of "avoid VB.Net like the plague"; VB.Net is not VB6, both VB.Net and C#.Net go through the same CLR into MSIL, and (generally speaking) are only syntactical differences between C#.Net and VB.Net. There's a book I've mentioned before that highlights the more niche difference, but that is starting to show a little age as the C# and VB teams at MS tighten up things more and more.

Smart man.
 
As an Amazon Associate, HardForum may earn from qualifying purchases.
If you're a C++ programmer though, C# will be more akin to what you've done before, I think. VB .NET has always looked a little funky to me.
 
Parameters in Java are all pass-by-reference. Primitives are immutable as are Strings.

It's one of the major themes in my current data structures class that java only has pass by value, and the professor is a pretty smart guy. From my understanding, if you pass an object, a new refence is created and given the location of the object, which is considered the value of the reference passed in. That way the reference in the method can be reassigned to a new object and the old reference that was passed in will still point to the original object, meaning 2 references exist. When I think of pass by reference, I'm assuming that means only 1 reference ever actually exists.
 
If you're a C++ programmer though, C# will be more akin to what you've done before, I think. VB .NET has always looked a little funky to me.

C# makes sense for web developers because it's similiar to JavaScript syntax. I just feel more comfortable with C# but it's just syntax. Any real developer should be able to develop to an object model.
 
Out of curiousity, what is Java lacking in OO implementation?
Restraint.
I'll conceed to the point that most apps still rely on C/C++ just look at vista. But compare Vista to Win7 and you see the power that .Net can bring

Win7 and Vista are both written primarily in C++, and comparing them doesn't teach us anything about Java or C#.
 
It's one of the major themes in my current data structures class that java only has pass by value

You are correct and devman is incorrect -- Java is completely pass-by-value. However, it passes references by value (for non-primitives), so as long as you don't change the Object that the parameter points at, you're changing the original Object.

However, if you set the parameter to a new Object, then it is now pointing at a completely different Object than the original, and from that point on, nothing you do to the parameter will affect the original.
 
I feel more comfortable using the .NET platform (using C#) than J2EE, but that's just me... since I'm in a Windows environment @ work.
 
You are correct and devman is incorrect -- Java is completely pass-by-value. However, it passes references by value (for non-primitives), so as long as you don't change the Object that the parameter points at, you're changing the original Object.

However, if you set the parameter to a new Object, then it is now pointing at a completely different Object than the original, and from that point on, nothing you do to the parameter will affect the original.

Thank you for the correction, Java is indeed pass references by value, I was mistaken.
 
Language itself matters very little.


I develop in multiple languages, Java variants and C# take about 95% of my time with some C++/Object C thrown in the mix. I prefer Java but for reasons too many to list.
 
Last edited:
Restraint.


Win7 and Vista are both written primarily in C++, and comparing them doesn't teach us anything about Java or C#.

Not sure what you mean by "restraint."

Win7 and Vista are a combination of C and C++, though I thought certain higher level programs use .NET framework stuff, such as WPF in control panels and the like.
 
By "restraint", I mean the lack of restraint in the oopaholic design of the Java libraries.

Control Panel in Win7 is a native application. It's possible to write a control panel applet that is managed, but I don't think any of the system-provided ones are. The Windows' team problems with managed code have been pretty well documented.
 
By "restraint", I mean the lack of restraint in the oopaholic design of the Java libraries.

Control Panel in Win7 is a native application. It's possible to write a control panel applet that is managed, but I don't think any of the system-provided ones are. The Windows' team problems with managed code have been pretty well documented.

I was thinking more of the some of the configuration tools controls, such as the hyper-v wizard, ipsec policy manager, etc (which I just checked - they're managed). I don't think any of the core OS is managed code (especially not in my area - graphics drivers), but a number of the tools are moving that direction.
 
I was thinking more of the some of the configuration tools controls, such as the hyper-v wizard, ipsec policy manager, etc (which I just checked - they're managed). I don't think any of the core OS is managed code (especially not in my area - graphics drivers), but a number of the tools are moving that direction.
Which also doesn't tell us anything, either. For example, my team re-wrote one of the tools that ships in SQL Server in C# from C++. It's one of my most regrettable technical decisions; performance is terrible. Decisions about platform are made at companies like Microsoft for political and schedule reasons far more often than they are for technical reasons. That is, you can't assume that the application of a certain technology is an endorsement of its merit.

citation needed

http://blogs.techrepublic.com.com/programming-and-development/?p=553 is one decent explanation of the issue. Another is the poor performance of the Java runtime. There are simply too many layers of OO crap to get work done; immutable strings are a symptom of this design problem. The same thing is true of the .NET framework; pretty close, but not quite as bad.
 
http://blogs.techrepublic.com.com/programming-and-development/?p=553 is one decent explanation of the issue. Another is the poor performance of the Java runtime. There are simply too many layers of OO crap to get work done; immutable strings are a symptom of this design problem. The same thing is true of the .NET framework; pretty close, but not quite as bad.

Interesting, thanks for the infos. I think the article was written before Scala came out -- it's pure OO, but it does make for more concise and expressive code and gets rid of some of Java's annoying verbosity. Still wouldn't match C++ for performance, of course. Man, I should come up with a C++ side project to work on, I haven't used that in a good 5 years. All I ever do is web these days.
 
Last edited:
Which also doesn't tell us anything, either. For example, my team re-wrote one of the tools that ships in SQL Server in C# from C++. It's one of my most regrettable technical decisions; performance is terrible. Decisions about platform are made at companies like Microsoft for political and schedule reasons far more often than they are for technical reasons. That is, you can't assume that the application of a certain technology is an endorsement of its merit.

I wasn't strictly saying it was an endorsement, though there's definitely something to be said for the ability of C# and similar to help you make those tight schedules. That is, sometimes (often, even), the ability for a certain technology to meet your needs in the timeliest manner may outweigh the need to meet your needs in the most computing-speed-efficient, a trade-off you're well aware of.

*edit*
Of course, I say that while writing this c++ framework for testing certain plug and play capabilities and correct performance of graphics drivers, one of those areas where using C# would actually slow me down a ton both in work and code efficiency - I'd spend more time working with p/invoke than I would actually implementing logic >.<
 
Last edited:
though there's definitely something to be said for the ability of C# and similar to help you make those tight schedules.
I couldn't disagree more. Microsoft has pushed on about developer productivity in C#, and I just don't agree that it's real. For trivial apps, sure; you can slap something together pretty quick. For quality, commercial software, though, you've got to spend the time you've saved in the development cycle cleaning up other problems. A more complicated installer, for example; localization problems, perf issues, and so on.

That is, sometimes (often, even), the ability for a certain technology to meet your needs in the timeliest manner may outweigh the need to meet your needs in the most computing-speed-efficient, a trade-off you're well aware of.
There are situations when that's true. It's surprising those situations would come about in a company with 90,000 people and two to five years between product releases.
Of course, I say that while writing this c++ framework for testing certain plug and play capabilities and correct performance of graphics drivers, one of those areas where using C# would actually slow me down a ton both in work and code efficiency - I'd spend more time working with p/invoke than I would actually implementing logic >.<
I don't think the issues you notice are related only to low-level interop, but it's certainly one of the big areas of concern. The cost of leaving the confines of .NET are very high, but frequently necessary.
 
I couldn't disagree more. Microsoft has pushed on about developer productivity in C#, and I just don't agree that it's real. For trivial apps, sure; you can slap something together pretty quick. For quality, commercial software, though, you've got to spend the time you've saved in the development cycle cleaning up other problems. A more complicated installer, for example; localization problems, perf issues, and so on.

We'll agree to disagree, then. There are definitely places I've found C# to be far more productive for me. Perhaps it's due to the nature of the apps I was coding with them - utilities and simple productivity-enhancing software, but there was definitely an increase in my productivity compared to doing the same in C++. I say this because I had previously started doing some of the work in C++ (xml dom parsing for one of the tools), before moving to LINQ. I think the issue is a matter of what we call "trivial." I consider an app that is deployed to thousands or millions of users nontrivial, even if it is simple. However, with your experience in MFC and, now, Steam, your idea of what is or is not trivial may have expanded well beyond my own.

I would like to know what localization problems you've encountered that are any different than whatever other (programming) language you might use. Perf is easy for me to understand, as I see the results of poorly written/handled C# code come back to haunt me (well, to be fair, it's often faster than the c++ code it replaced, but that's a whole other bag of issues), but I am not sure what caveats I should be wary of when doing C# development.

There are situations when that's true. It's surprising those situations would come about in a company with 90,000 people and two to five years between product releases.
Hurry up and wait.
 
Back
Top