Slashdot Mirror
Java 1.5 vs C#
Here's the list of enhancements to the Java Language:
- Generics (C# 2.0 already supports this)
- Enhanced For-Loop (the foreach construct in C# 1.0, duh!)
- Autoboxing/Unboxing (C# 1.0 already has this, everything is an object, even the primitives - not really, but they do it so well...)
- Typesafe Enums (again C# 1.0 already implemented this, but I think they've added a little bit more twist in Java, that its actually a better implementation)
- Varargs (C# 1.0's params construct, ellipsis construct in C++)
- Static Import (I don't know if C# 1.0 has this, or C#2.0, but C# has a construct for aliasing your imports - which is way cooler. Static Import, actually promotes bad coding habits IMHO)
- Metadata/Annotations (this is C# 1.0's Attributes, Sun's upturned noses just gave it a fancier name - also, C#'s implementation is better and more intuitive)
They've beefed up the API some, and integrated several packages with the regular JSDK that used to be a part of a separate package or installation ---in my NSHO, the Java API has become bloated...
At this point (even before Whidbey) the deciding factor (as always) for Enterprise work, when choosing a language platform, should be the support it has behind it, in terms of IDE, tools, api, and longevity of the vendor pushing it (forget the OpenSource crap argument, those guys are too in love with Perl, Python, and Ruby - Java could become the child nobody wants to talk about if Sun dies) - right now that's C# and the .NET Framework ---
If you ask Paul Graham though, both language would be utter crap and fit only for idiots :) http://www.paulgraham.com/gh.html [I'm exaggerating, so hold off on those flames.]
How about a cross-compiler that takes advantage of this vendor competition in cooperation to combine both communities of programmers into one pool targeting either virtual machine?
--
make install -not war
Growing up as a software developer in C and C++, I'm really impressed with Java. Although it IS slower and it runs on another layer on top of the OS, it IS still very impressive because OOP gives people the chance to understand programming without having to know much besides how objects interact with each other... (Dog plays with Ball, Car has Wheels, etc.) The platform independence is also a plus, and as our processors increase in speed, the overhead of running on top of a layer which runs on top an OS will become less significant.
Fully agree. The guy doesn't know what he's talking about. Java has much more support in the industry, .NET in the enterprise is currently painful. The tools are barely usable (Visual Studio debugger on a large application, anyone?) plus he makes some fundamental errors in the list. .NET does not support auto-unboxing for example (at least not .NET 1.0 or 1.1).
Powered by onion juice.
Maybe I just don't grok OO design, but the whole language is really abstract. Nothing seems to tie together to anything else in any sort of logical fashion, and it takes hours to figure out how anything works.
Meh, that's just my take on it. And it would appear that my opinion is officially modded "troll". Oh, well. =/
"Quoting famous computer scientists out of context is the root of all evil (or at least most of it) in programming." - K
Is this article flamebait? Maybe I am just misunderstanding when he says:
"At this point (even before Whidbey) the deciding factor (as always) for Enterprise work, when choosing a language platform, should be the support it has behind it, in terms of IDE, tools, api, and longevity of the vendor pushing it (forget the OpenSource crap argument, those guys are too in love with Perl, Python, and Ruby..."
Which "crap" argument is he talking about? I assume he means that when using those languages you have thousands of directions to go for help in howtos, docs, tutorials, books and of course the loving #perl. I normally would not reply to something like that, but I took offense. Yes I love those languages. They all have strong points and make life fun when coding. I have support and have never had to rely on a company to provide said support. Oh yeah, and I write enterprise software with the mod_perl crap everyday of my life. Thanks.
iamchaos
No. Checked exceptions were an interesting experiment that turned out to be a bad idea. I won't rehash the arguments here (for a reasonable example, search for Bruce Eckel's writings on the topic), but when the ivory tower of checked exceptions meets the real world of deadlines, something has to give.
I've no plans to use C#, but it's something they definitely did right.
It is this similarity and 'compatibility' of Java & C# that is now making it easy to port various applications between the two languages. For instance, the very popular Lucene (Information Retrieval library from Jakarta (i.e. Java)) has a very solid .Net port written in C# called dotLucene. The Lucene -> dotLuene port is fairly automated, it appears, which allows developers of the .Net/C# port to keep up with the original software written in Java.
If C#/Java continue in this direction, I think we will see many more applications that have parallel versions in the two languages.
See:
Lucene
dotLucene
Simpy
Sorry, guys but as long as you don't have that, you're not really OO.
There are some important limitations of generics in
Java, which are properly addressed in C#.
For more details, you might want to read:
http://www.artima.com/intv/generics.html
C# still has a few extra niceties like properties,
events, delegates, anonymous methods and iterators.
Miguel.
Nice troll.
C# supports a full exception handling model, it just does not force you to declare and handle checked exceptions, an issue of strong contention within the Java community. Its left to the developers discretion when to check and handle errors. The orinal exception will still be available no information is lost.
For my own opinion I prefer unchecked exceptions as the code is far cleaner. Enforcing checked exceptions can be extremely clunky to handle and its highly debatable whether exceptions should be part of an interface. I also noticed a recent trend among java developers to use a single catch all exception in many cases to simplify coding.
Do not try to read the dupe, thats impossible. Instead, only try to realize the truth
What truth?
There is no dupe
Let's take these one at a time here:
;-)
Neither is open source. Languages can't be classified open source, because they aren't programs. Certainly both languages have non-open source implementations, but they also have open source implementations.
Both require virtual machines. Well, I guess it depends on what you mean by a virtual machine. Technically even the C runtime is a virtual machine. That being said, both Java and C# can be compiled to native code, bypassing the need for the JVM/CLR.
Despite being marketed as portable, but have portability issues. ROTFL! Yes, perfect portability isn't possible. However, both languages are amazingly portable considering their extensive feature sets.
We don't really need them. Really, when you think about it, we only really need C. PHP/Perl/C++/Python are really all flawed languages as a consequence.
They're closely tied to their respective companies. This is more of a perception problem than a reality problem. I can do development in either language without getting involved with either company.
sigs are a waste of space
Last time I checked, few industries were doing enterprise development with J2SE, regardless of the version. J2EE is the preferred platform for enterprise application development (hence the 'EE', or 'Enterprise Edition', after the 'J2' bit). J2SE 1.5 is a great release, but it means little currently for J2EE developers.
The new features to Java in version 1.5 are all anticipated and appreciated by the development community, but us J2EE developers won't be able to access these new features in our apps until the official J2EE 1.5 release comes out, and the various app server vendors (IBM, BEA, Oracle, Sun, JBoss, Apache, etc.) support it in their products.
I code in java on the side for some small business apps. I've also coded in C# and have used all of the MS Visual Stuido nonsense. Both languages are at a level that you can do just about anything with one that you can do with the other. So the deciding factors come down to really which is a better platform to develop on and cross platform compatibility (in some cases the latter isn't an issue, but it is for me). As far as IDE's go,I don't get what people like about Visual Studio, especially VS.net. I enjoyed VS 6.0 much better the VS.net, regardless I have since moved to a strictly open source platform and only use Windows for testing. When I did do C# coding, I preferred using vim or Sharpdevelop. I really can't stand VS.net. Anyway, Java, imho, has superior IDEs (some may argue that IDEs reinforce bad programming, etc..., but if used *correctly* they can significantly increase productivity) Eclipse puts Visual Studio to shame in many areas. Eclipse is an amazing IDE and made programming fun again. Another great IDE for Java, that puts great focus on GUI dev, Web App dev, and Mobile phones, is Net Beans. Both IDEs have very nice integrated features with a great tool selection and good plugin frameworks. I use both interchangeably depending upon specific tasks and projects. So in my oppinion as far as having a good platform to work on, Java is superior. Next is cross platform compatibility. Although Mono is making leaps and bounds, Java wins hands down on this. It gives my customers more options and major open source software foundations like the Apache foundation actively work on many java based enterprise applications. This allows my customers to also have low start up and implementation costs.No real need for further discussion on that. Another area where I prefer java is for distributing applications via WebStart. It makes life very easy, in many areas including maintenance and deployment. This is just my 2 cents. I don't really see why anyone would use C#, I mean they took Java and improved, and now Java has taken both its past and C# and improved itself :/
Regards,
Steve
Agreed. Even more frustrating is that all the collections classes have been rebuilt to be based on generics. I teach at a liberal arts college, and have found Java 1.5 to be a supreme headache. It's much harder to teach than Java 1.4. I'm finding that I have to either teach intro CS students the complexities of Java generics, or I need to teach them to ignore warning messages. It's painful.
I don't know much about C# or Java, as I jumped ship from the microsoft camp before .NET and currently program in PHP, but I can say one thing; based on the emails I get from recruiting websites, there's at least twice as many java openings in my area as there are .NET. That settles the argument for me.
I'm curious, why do we still get buffer overflows in C++ code? I mean, the C++ string type and the vector container have been around for the better part of a decade now, and a standard part of the language for, what, six years? Seven years? And you can grab smart pointers from boost.
.Net here, haven't looked at that) which still inexcusably use C-style strings and generally unsafe memory management. Not that Microsoft is solely to blame, of course.
So, why do we still have buffer overflows? Is it because of the language? I think my previous paragraph shows that this is no longer the cause, and hasn't been for years. On the other hand, C++ does still allow you to make use of C-style strings, unchecked arrays, etc., so perhaps we can blame C++ because it allows you to shoot yourself in the foot, you just have to be very explicit these days. Or perhaps the problem actually lies in the hideously outdated libraries that people are using, libraries such as the ones Microsoft gives you (I'm not talking
Oceania has always been at war with Eastasia.
Just because C# has more features does NOT make it a better language. Infact most of these Java 1.5 java changes annoy me. You could almost all these things in 1.4 there was just a certain way of doing it. If you have every programmed in C++ before with lots of different people who program things differently you will know that having different ways of doing things can be a VERY bad thing. This is way Java was so strong because there was 1 right way and 1 wrong way. Where in C++ you have like 3 right ways (that don't mesh together) and about 15 wrong ways to do something. Java is simpiler and faster to write code because you don't have 5 or 6 different ways of doing the same thing!
I sincerely apologize for feeding troll. :oD
Sometimes the truth is arrived at by adding all the little lies together and deducting them from all that is known.
>However, the template feature of our C++ is so
>powerful, that when used together with structs and
>classes, one can produce beautiful code that is
>extremely powerful, yet so simple
Yes... until you forget a blank between several lowerThan or greaterThan operators when instantiating a template... then suddenly, all hell breaks lose and you'll get 600 lines of error messages, leaving you absolutely no chance of finding the place where you actually made the error
(well, the only way of finding the guilty piece of code is by guessing.).
> I would then suggest that we join our efforts, in
>teaching the unwashed masses how to actually use
>the language properly, so that we will not have to
>re-do all software in the world (both ours and
>yours) by ourselves.
Indeed... of course, C++ programmers like learning their language so much, that that's everything they'll do. Sure, for the first 3 years it's necessary, because whenever you've mastered one concept, you'll get bitten by all of it's little problems and exceptions and special cases.
And after that, C++ programmers always get so hot about templates and generic programming, that they'll write 1000s of lines of code just to use
that feature, thereby turning their code into something unmaintainable... except maybe by Bjarne Stroustrup, Alexandrescu or themselves... And after 10 years of that, they suddenly realize, that there's more to programming than just calculating the factorial at compile time (using templates) or
thinking about the PIMPL idiom (yes, that's a real thing, google for it, and yes: it's basically a hack to get around some C++ problems, and yes: it's bascally a neutered bridge pattern).
In short: Java (and, in turn C#) were created, to cut off the cruft of C++. Java is a simple language, that can be learned in a short time because the sheer number of language features and syntax ambiguities is considerably lower (do you know what "C++ digraphs" are? Yes? OK... so how many lines of code have they saved for you or how much safer have they made your code?).
Oh... and BTW: I prefer using a language, where I can actually get more than one fully compliant compiler; C++ doesn't have that. (Think I'm talking trash? Try using the "export" feature for templates in GCC or Visual C++... the only compiler frontend that supposedly knows them (haven't checked) is Cormeau).
murphee
Yeah, there's a syntax for this. It's called "put the try and catch in the function, with an empty catch block, and a comment that indicates why the exception can't happen." Then your function doesn't have to be declared as throwing an exception, and someone who looks at your code will understand that you didn't just eat the exception for no reason.
And, before you whine about having to write the try/catch block, let me echo what somebody else said, that an IDE like IntelliJ will do it all for you (except for the comment).
Autoboxing/unboxing *shrug* nice when you need it, but how often do you actually need it?
I love this feature. Currently I have to do this sort of crap all the time:
String to int:
new Integer("1").intValue();
or parseInt
int to String:
String.valueOf(1);
In truth, Java should have dropped the primitive types altogether and went with a 100% object approach and allow things like this:
Integer _integer = 3;
Long _long = 5;
Number _number = _integer + _long;
_number--;
The above would be total sweetness.
What they should have done in 1.5 is strip out all the deprecated crap
Agreed. First to go: java.util.Date. And fix Calendar to be actually usefull.
Of course that is merely the tip of the iceberg of the power of generics. C++ templates are a Turing-complete language in their own right, and when used correctly can do many of the things LISP programs can do, except executed at compile time.
I have a couple of rules when regarding languages:
.NET and C#). And just when you get used to version XYZ, they come out with XYZ+1 which changes EVERYTHING. Sorry, I don't need my code to die at the whims of MS.
1. Does it have wide industry support or is it merely another "we ship it until we kill it" single-sourced language.
2. Does the name sound like it could hurt you?
C# pretty much fills the bill (no pun intended) for both 1 and 2.
MS is no stranger to introducing something and then killing it some time later (hence my avoidance of both
Then there is the whole "C#" name which, frankly, I think sounds retarded. To most Americans, the '#' symbol is pronounced "pound". Few people I know call it a "sharp" (actually, NO ONE that I know calls it that).
Finally, just the sound of it sounds dangerous and, if inserted in the wrong place (like my MIND) could cause harm.
IANAL, but I've seen actors play them on TV
JNI is inefficient and cumbersome. Furthermore, it requires you to compile and ship separate versions for every single target CPU. In C#, unsafe code is portable and WORA (and that's not a contradiction in terms).
CLR and Java VM are essentially the same thing. CLR is more flexible (it supports more languages, even though the list of currently supported languages is actually bigger for Java VM) and you can mix different languages for the same project. They both have advanced garbage collection schemes and both run 'inside' a virtual machine, although in C# you can 'step outside' (unmanaged mode) to do your own memory management (which is a big bonus for some projects). Duh!
No matter how fast light travels it finds the darkness has always got there first, and is waiting for it. (T. Pratchett)
You're comparing apples to oranges. If you want to compare GUI front ends, you should at least use one of the gui front ends in your comparison. I used DDD in the past. There are others.
Personally, I use GDB-mode in emacs - my biggest frustration with Visual Studio is that there's no easy way to see the history of variable's values.
I'd want to run through a loop 100 times and have a buffer showing the values of the variables from each of those hundred times in a table. Trivial with gdb-mode under emacs. With Visual Studio it refreshs the values each time I hit a breakpoint so I can't see the history.
For all those who keep saying java is dying, Unix is dying, and mainframes are dying. Fact is, they aren't dying. Are the roles changing? Well yeah! Nothing ever stays the same and things will always change.
A professional developer should always think about the needs of the clients first. that means using C# and .NET if they are a Microsoft centric shop. It also means being up front and honest about everything. No one language is perfect and no one platform will ever be perfect. Most of the platforms today are sufficient for the majority of the businesses. Blindly believing marketing and PR material is both retarded and silly. Languages and programming shouldn't be a religion. It's a tool god damn it.
If you aren't willing to spend the time to learn the tool, freaking get out of the IT industry so the rest of us can focus on getting work done. </rant>
One thing that makes me nuts in C# is its lack of compile-time enforcment of Exception handling. When I made the switch from C++ to Java, I fell in love with Java's compile-time checks for appropriate try/catch blocks.
In my C# development over the past year, I've been repeatedly frustrated by exceptions popping up in unexpected catch blocks because they were thrown and not caught deep down in the bowels of my code.
To me, that's more or less a deal-breaker in choosing C# for large-scale development. Unless developers are exceptionally disciplined (and that's hard to guarantee across a large/distributed team), lack of compile-time enforcement limits Exceptions' usefulness.
If it's a choice of language based solely on the portablity of code, C# wins out IMHO. With Java, you're dependant on Sun to support your system, which is a royal pain. (as anyone with a *BSD box will tell you)
I run a J2EE application on WebSphere on a mainframe under OS/390. Where's .Net for OS/390? I can (and have) also deploy that same application with zero changes to Linux, Windows, Solaris, AS/400 or Mac OS X. I can choose from a number of J2EE implementations like WebSphere, WebLogic, JBoss or Resin, each of which have different features and strengths. I don't even recompile, I just drop in the WAR and go.
And it is incorrect to say that you are dependent on Sun to support your system. Independent vendors like IBM, BEA and Apple also license and support J2SE and J2EE for their own platforms. My personal systems are Macs and I get my Java from Apple, not Sun. My corporate systems are IBM and I get my corporate Java from IBM, not Sun. If I have a problem with either, I don't call Sun, I call Apple or IBM. IBM provides my production support contract. IBM are the ones who responded with a custom patched version of WebSphere for OS/390 in less than 24 hours when I had a production problem. Not Sun.
As other posters have said, I don't think that C# is meant for big enterprise apps, but littler 'toy' apps. Still, you'd be surprised how many of such apps are in use right now. The biggest strengths of C# are:
.NET, so that a user can program to a higher level library. Documentation is all there. It also provides all of the tools and files needed in one tidy install, without the need for combining different packages. It all comes from one vendor, and it's easy to get your mind around.
1)Simplicity. Everyone loves to argue about how purists should code things, but in the real world, a lot of code is written by people who are blissfully ignorant of theory. VS allows them to make obvious progress, reusability be damned. A crude, but working app is more impressive to a clueless manager than a collection of nascent classes.
2)Integration. This goes along with #1. Much of the heavy lifting in creating desktop apps is rolled into
3)ASP.NET. I would argue that ASP.NET is the easiest way to accomplish application-like behavior in a web site. Session state works well, database access is a couple lines of code, and you can even draw the page on a coordinate system if HTML stymies you. Scorn it if you must, but it's a good step toward standardizing web/application development.
As Stroustrup says of the ellipsis construct in C++, "The most common use of the ellipsis is to specify an interface to C library functions that were defined before C++ provided alternatives", and gives an example of the "extra work that face[s] the programmer once type checking has been suppressed using the ellipsis." Using the ellipsis construct, other than where it has to be used to access some legacy C library, is definitely very poor style in C++.
The included libraries will make/break a language, and right now, the .NET libraries are much easier to use. Partly because they were designed "as a whole" and don't have a lot of cruft in them (yet). And partly because the MS on-line help is vastly superior to JDoc (does Sun not believe in code samples?).
.NET framework is that 90% of it uses concrete implementations. Because they didn't use an Interface-driven design, they now have to fall back on the Win32 style of appending "-ex" to class names when they want to improve them, rather than letting a dynamic loader find the class the developer needs.
The biggest weakness I see in the
Even so, the Visual Studio IDE is so far ahead of any of the Java IDEs (Eclipse comes closest), that it's probably Microsoft's single best competitive advantage.
Chip H.
DISCLAIMER: I develop heavily in both C# and Java, more C# than Java, about 80% C#, 20% Java, not by choice but based on client demands.
.NET, though, is that the libraries seem to be more consistent, whereas the Java APIs have evloved and been added to by different developers using diffferent programming styles and approaches to patterns, each package seems to implement different programming styles and constructs, but you get used to it after a while. Plus, Java has so much deprecated code, they need to clean those out once and for all and clean up the APIs, see this for more details of what I'm talking about.
I don't think it's fair to compare Java 1.5 (released) vs. C# 2.0 (beta, who knows when it'll actually be released). That's like comparing Linux to Longhorn.
And re: IDEs, while programming so much in VS.NET, I missed all of the cool features of my IDEA IntelliJ Java IDE that I was excited to buy ReSharper, bringing some of IDEA's cool features to VS.NET.
One of the main things I like about
Yeah,
... in respect to Symantec C++.
.... because they never heared about IDEA IntelliJ or about Omnicore CodeGuide :D at home I use CodeGuide for dayly work and Eclipse for CVS.
... well, the old SNIFF IDE was crafted by the same guy behind Eclipse. But thats a guy from GOF ... and most /.ers put OO and patterns into one basket and still think assembler rules :D
indeed, debuggin in visual studio is awesome. Granted. Hm, does anyone remember the company from wich MS bought that technology? I can reboot one of my very old 486 (year 1993) PCs where I have used the same debugger on Symantec C++ 6.0 (Larry Wall, D++, ever heared about?). Frankyl, I don't see much improvement in Visual Studio, but my latest version is from 1999
OTOH, I use Eclipse at my customer sides
I would dare a statement:
*ALL* Java IDEs are *FAR* beyond any C++/Microsoft IDE. The only thing comming close to Eclipse is SNIFF+ from WindRiver (shit, forgot the old company name, was it Take Five?)
angel'o'sphere
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
No specialised debugger for me - just the built in debugging support in Eclipse.
.NET at all.
Or even JBuilder.
And I assume all the other IDEs have debuggers built in too.
And there's heaps of stand alone ones too. There's bound to be one that suits your needs.
hmmm....googling for "java debugger" gives a nice long list of java debuggers.
".net debugger" gives you a page full of problems with the VS debugger - headed with "The VS7.X Debugger doesn't work, What can I do?"
and one or two links that appear to be 3rd party debuggers - but aren't related to
I'm pretty sure that says something...I'm not quite sure what though....
Advanced users are users too!
In C++ the decision whether or not to make use of exceptions is hard to make. If you don't use exceptions, the results of many function calls have to be checks, which is considerably more of a hassle than Java. If exceptions are used, writing exception-safe code is really quite limiting (It often means significantly more little objects when "new" can't be used freely, and much of the existing code have to be rewritten, and I hate comments like "func() can't throw, so this is safe"). Seems that an garbage-collecting language like Java/C# is very helpful if one want to use exceptions.