Java AND C#

Yes, Java's "Standard Library" SUCKS. Big time.

I suggest C#.

C# is supposed to be faster than Java (and some say even than unmanaged C++) on Longhorn.

P.S. M$ is teh devIL

My preference is C# over java, dont really like either of them (would rather have C/C++ but right tool for right job so have to work with all).

Java looks too bloated and cumbersome to me, half the stuff that you want to do is already coded in some library somewhere (just have to poke and find it which isn't always obvious). I also dont like the GUI thing in java, swing, awt and that, hate it. C# looks more like C/C++ (and cleaner), GUI designer is also better IMO.

HTH

Quote:

Original post by xMcBaiNx Yes, Java's "Standard Library" SUCKS. Big time. I suggest C#.

That's a rather unfounded claim don't you think?

Quote:

Original post by Raduprv C# is supposed to be faster than Java (and some say even than unmanaged C++) on Longhorn. P.S. M$ is teh devIL

Well if you read my post you'll know I really am not taking any MS-related into account.

Also, I know you wrote that to be funny, but I don't want to have Oluseyi to bring the "Wrath of Closure"(TM) on this thread. Thanks.

Quote:

Original post by nts My preference is C# over java, dont really like either of them (would rather have C/C++ but right tool for right job so have to work with all). Java looks too bloated and cumbersome to me, half the stuff that you want to do is already coded in some library somewhere (just have to poke and find it which isn't always obvious). I also dont like the GUI thing in java, swing, awt and that, hate it. C# looks more like C/C++ (and cleaner), GUI designer is also better IMO. HTH

That's something I don't like with Java as well. Too many importing libraries and such. I wish they'll make a VERY clean slate with Java and make the AWT and Swing libraries as independent and intuitive as possible.

Though it seems you have to import (or is it include...i forget) a bunch of library files in C# as well. Since I haven't looked into it much I asking for constructive comments [smile], before diving in.

Quote:

Original post by Alpha_ProgDes Also, I know you wrote that to be funny, but I don't want to have Oluseyi to bring the "Wrath of Closure"(TM) on this thread. Thanks.

He is not THAT cynical, now is he? :D

Anyway, if you want other OSes besides for Windows, you should go with Java. Sure, they are developing C# enviroments for other OSes, but Java is implemented on virtually any OS, while C# isn't.

Quote:

Original post by nts Java looks too bloated and cumbersome to me, half the stuff that you want to do is already coded in some library somewhere

If your actually complaining about the breadth and depth of code other people have written for you, then maybe you should have your head examined.... ;P

I haven't used c# extensively, but my understanding is that its designe to fit the exact same problem domain as java. RAD, network, threading, gui aware applications that are supposedly highly scalable. Only java is multi platform and .net wasn't intended to be (unless you novell and you wanted to put forth the effort).

Java is the festering boil on the ass of software development. Enough said.

Quote:

Original post by jsgcdude Quote: Original post by nts Java looks too bloated and cumbersome to me, half the stuff that you want to do is already coded in some library somewhere If your actually complaining about the breadth and depth of code other people have written for you, then maybe you should have your head examined.... ;P I haven't used c# extensively, but my understanding is that its designe to fit the exact same problem domain as java. RAD, network, threading, gui aware applications that are supposedly highly scalable. Only java is multi platform and .net wasn't intended to be (unless you novell and you wanted to put forth the effort).

.NET was indeed intended to be multi-platform.

Quote:

Original post by nts My preference is C# over java, dont really like either of them (would rather have C/C++ but right tool for right job so have to work with all). Java looks too bloated and cumbersome to me, half the stuff that you want to do is already coded in some library somewhere (just have to poke and find it which isn't always obvious). I also dont like the GUI thing in java, swing, awt and that, hate it. C# looks more like C/C++ (and cleaner), GUI designer is also better IMO. HTH

I bet you're the type that prefers to write his own container classes over using the STL in C++. Although I agree with you that the .NET libraries are for the most part better designed over it's Java counterpart, but you should be aware that the .NET Framework BCL is far larger than the Java libraries.

Quote:

Original post by JesseT Java is the festering boil on the ass of software development. Enough said.

how about we STOP MAKING UNFOUNDED ACCUSATIONS!!! and back up what we say. hmm? i'm sure it can't be that hard.... (well only GD.net it seems)

and no, that's not "enough said".

Quote:

Original post by Alpha_ProgDes Quote: Original post by JesseT Java is the festering boil on the ass of software development. Enough said. how about we STOP MAKING UNFOUNDED ACCUSATIONS!!! and back up what we say. hmm? i'm sure it can't be that hard.... (well only GD.net it seems) and no, that's not "enough said".

Okay, okay, I'll back them up. I'm just sick of having to back up my points in Java VS .NET discussions, it's starting to tire me out. Hell, the one on slashdot today really stressed me out, I had to refrain myself from driving up to the university to strangle some perl-loving zealots. Give me a few moments to compose myself.

Quote:

Original post by JesseT I bet you're the type that prefers to write his own container classes over using the STL in C++. Although I agree with you that the .NET libraries are for the most part better designed over it's Java counterpart, but you should be aware that the .NET Framework BCL is far larger than the Java libraries.

Nope actually, i heavily use STL, strings over char* (where possible, almost everywhere) and list, vectors, maps where needed. I've only written one container, a special vector class (not nearly the features of std::vector just the barebones needed, its only for special items too).

I dont know the comparative sizes of the two frameworks, however the design in C# definately looks better for me, maybe because i'm more from a C/C++ background.

Some Reasons Why Java Sucks (And Why You Should Commit Seppuku If You Use It):

[Edit: To my knowledge, C# and .NET do not suffer from the below problems, with the exception of the "hacks within hacks" item, as I haven't looked at MS's source code. Thus, by showing you a bit of the dark side of Java, I hope that you will consider alternatives!]

- No parameter type information is retained on a generic collection. You can’t ask what the type parameters were of a certain collection a run-time, for example.

- You can’t use a primitive type as a type parameter for a generic type.

- The new boxing features and generics won’t always work as you might expect, as generic types, once instantiated, use java.lang.Object internally. Thus, generics in Java offer no performance benefits like they do in .NET.

- You can’t create an array of generic collections.

- There is some additional minor stuff that involves inconsistently using the keyword "extends" when actually implementing interfaces (for which Java always used "implements", but not with generics).

- Forcing programmers to check all exceptions that can be thrown from a method may seem like a good thing at first, but now enters the library/middleware developer. Class libraries generally are not responsible for handling errors, they pass them on to the application programmer. But what about nested method calls inside of the library? Yep, that's right you'll need a lot of try/catch and exception rethrowing code. It's no better than the error return codes of lore. So what are middleware developers forced to do? The wrap exceptions in an exception derived from RuntimeException and rethrow it, but this is both painful and leads to information about the exception being lost.

- Nothing equivalent to struct or enum in C#/.NET is found in Java. Java enums are reference types. And not only that, but you cannot imbue a reference type to have value semantics like you can in C#/.NET (example, System.String). Yep, a whole boat load of optimizations and efficieny has been thrown overboard here folks.

- The fact that static methods aren't really class methods (they're actually global functions: you can't overload them in a subclass) is pretty stupid.

- The Java libraries are full of hacks within hacks. Don't believe me? Download the shared source code from Sun and have a look yourself.

- Two identical byte[] arrays aren't equal and don't hash the same. This is a problem when having a default Hashtable of such arrays. Maybe this is just a bug, but:

- You can't fix this by subclassing Hashtable.

- You can't fix this by subclassing Array because it's not really an object. What you can do is wrap an Object around an Array and let that implement hashCode and equals by digging around in its contained array, but that adds not-insignificant memory overhead (16 bytes per object, today.)

- Gee, I know, I'll write my own hash table. I've only done that a thousand F$@!^!#^!ING times.

- I can't seem to manage to iterate the characters in a String without implicitly involving half a dozen method calls per character. The other alternative is to convert the String to a byte[] first, and iterate the bytes, at the cost of creating lots of random garbage.

- Broken support for UTF-8 in the Java. Have fun exporting UTF-8 characters from a UTF standards compliant system (eg. .NET) and importing them into Java.

- This "integers aren't objects" nonsense really pisses me off. Why did they do that? What the hell. This leads to problems of not being able to treat such types transparently in collection classes...

- And in related news, it's a total pain that one can't iterate over the contents of an array without knowing intimate details about its contents: you have to know whether it's a byte[], or an int[], or an Object[]. I mean, it is not rocket science to have a language that can transparently access both boxed and unboxed storage. It's not as if Java isn't doing all the requisite runtime type checks already! It's as if they went out of their way to make this not work. .NET doesn't have this problem, all Arrays implement ICollection and IEnumerable.

- No conditional compilation. As far as I can see, there's no efficient way to implement "assert" or "#ifdef DEBUG".

- No weak references. Without weak references and a working finalization system, you can't implement a decent caching mechanism for, e.g., a communication framework that maintains proxies to objects on other machines, and likewise keeps track of other machines' references to your objects. .NET has weak references, so wtf is your problem Sun?

- The access model with respect to the mutability (or read-only-ness) of objects blows. Here's an example: System.in, out and err (the stdio streams) are all final variables. They didn't used to be, but some clever applet-writer realized that you could change them and start intercepting all output and do all sorts of nasty stuff. So, the whip-smart folks at Sun went and made them final. But hey! Sometimes it's okay to change them! So, they also added System.setIn, setOut, and setErr methods to change them! "Change a final variable?!'' I hear you cry. Yep. They sneak in through native code and change finals now. You might think it'd give 'em pause to think and realize that other people might also want to have public read-only yet privately writable variables, but no. Oh, but it gets even better: it turns out they didn't really have to sneak in through native code anyway, at least as far as the JVM is concerned, since the JVM treats final variables as always writable to the class they're defined in! There's no special case for constructors: they're just always writable. The javac compiler, on the other hand, pretends that they're only assignable once, either in static init code for static finals or once per constructor for instance variables. It also will optimize access to finals, despite the fact that it's actually unsafe to do so.

- Basically the only proper way to write your software in Java is system independent--you’re stuck with the common denominator. On the server side this usually isn’t the biggest problem, but when you do client stuff, you might want to use the system tray in Windows. No! Thou shalt write pure code! Oh sorry, I bought this really cool OS that has all those cool features, but now I can’t use them because that would affect the purity. What the fuck?

- No delegates. The distinction between slots and methods is stupid. Doing foo.x should be defined to be equivalent to foo.x(), with lexical magic for "foo.x = ..." assignment. Compilers should be trivially able to inline zero-argument accessor methods to be inline object+offset loads. That way programmers wouldn't break every single one of their callers when they happen to change the internal implementation of something from something which happened to be a "slot" to something with slightly more complicated behavior.

- James Gosling, the founder of Java, often says stupid things that are just not true: "Java always has been faster or as fast as C++." [Source]

Want more reasons? I can keep going if you like?

[Edited by - JesseT on December 23, 2004 11:44:18 PM]

Quote:

Original post by nts Quote: Original post by JesseT I bet you're the type that prefers to write his own container classes over using the STL in C++. Although I agree with you that the .NET libraries are for the most part better designed over it's Java counterpart, but you should be aware that the .NET Framework BCL is far larger than the Java libraries. Nope actually, i heavily use STL, strings over char* (where possible, almost everywhere) and list, vectors, maps where needed. I've only written one container, a special vector class (not nearly the features of std::vector just the barebones needed, its only for special items too). I dont know the comparative sizes of the two frameworks, however the design in C# definately looks better for me, maybe because i'm more from a C/C++ background.

Okay, sorry for the accusation. I'm in a sour mood, I over-reacted.

Anyway, my opinion on what I would use? Well, naturally the development tools that are best suited for the job. So long as Java isn't a part of that list. :)

For quick RAD stuff, I might use Python or VB.NET. For systems/services/library development, I'll use C# or C++. If I were to, right now, design and build a game engine, I'd write some of the low-level, processor-intensive stuff in C++/CLI, thus allowing me to take advantage of unmanaged code, and I'd write the higher-level subsystems in C#.

realisticly you can make games with both... but you cant expect to get nowhere near compiled code speed, becouse you wont

the people i know seems to go toward C# to dev since they like the sintax better, personaly i dont see any difference between both, i mean they are equaly similar to C++

i dont know how C# is on that, but but java is realy about IT deving (ie non-fun programing), everywhere i know uses java for that stuff... well becouse thats what java was made for and it does it very well
by far i know people only uses C# when the whole thing is on MS systems and always java otherwise

unlike some people stated, java standard lib is great, you can find anything you might need on it, and if you wont... you likely to find it on the apis... seriously java lib and apis pretty much let you do everything and with 70% of the work already done, you just need to learn how use them, and you cant expect high performance as well (even though u might get a little boost from using native methods... but them you either loses portabiliity or have to rewrite it in C++ and in java and will be slow in the plataforms where it runs with java)

java biggest problem and quality is thats its multiplataform, lots of things thats arent nice have to be made to make it like that, and you will ahve to live with them, well is just about learning how use it

seriously you should try both and see whats suits you better.. though that you need to give java a good time is not something you can understand how works with a quick look

Quote:

Original post by JesseT - No weak references. Without weak references and a working finalization system, you can't implement a decent caching mechanism for, e.g., a communication framework that maintains proxies to objects on other machines, and likewise keeps track of other machines' references to your objects. .NET has weak references, so wtf is your problem Sun?

Latest version of Java supports weak references, or at least claims to.

But I bet they dont have a generic version of a weak reference class like C# 2.0 does. Not losing type info is a good thing.

Quote:

Is there any distinct differences between the two or strengths they have toward certain development that a programmer should consider before coding?

I've used both fairly heavily, so I feel qualified in what I'm saying. But feel free to challenge if you don't agree. Here's a point-by-point rundown of some of the major differences, and some of the features that exist in one language but not the other. Ultimately, when all is said and done, C# is the better choice unless you absolutely require portability; in that case, use Java.

Relevance of file structure: In Java, each class must be placed separately in its own file. Classes themselves are organized into packages. The source file/directory tree, in other words, mirrors the class hierarchy in the code. Changing one breaks the other -- if you change the class organization, you must also change the source file's name and organization; if you change the directory structure or source file name you must also change the code.

In C#, there are no such restrictions. In fact, with the partial keyword you can even break a class across multiple files if you so desire. The Forms Designer in Visual Studio does this, for instance, to separate lengthy GUI component constructor/initializations from the important part of your code.

Reflection: Reflection is the ability of a program to discern information about itself. Java's term for reflection is "metadata", which really describes what reflection looks at rather than what it is. On the whole, reflection in Java is much weaker than in C#. The kinds of information you can extract from Java reflection are also much less rich. In C#, however, you can find out pretty much anything. Using the Reflection.Emit namespace, you can even modify the behavior of your own program at run-time, or build your own assemblies/source code. That's enormously powerful.

Annotations/Attributes: Some languages provide programmers with the ability to associate metadata with programming constructs. In C#, this is called attributes; Java calls it annotations. Both C# and Java allow you to apply attributes and annotations to virtually any construct. C#, however, lets you apply them more finely than Java does because Java doesn't have the notion of interface/struct constructs. Because of the way C# and Java store static class information, there is generally little or no performance implication to using attributes in either language.

Parametrized Types (Generics): A parametrized type is not a type itself, but instead represents another type; it is a placeholder. A programming language supports generics to at least some extent if it allows parametrized types. The way in which they do this, however, has vast impact on the performance implications of using generics. A major feature that J2SE 5 ("Java 1.5") and .NET/C# 2.0 have in common is parametrized types.

Generics in Java are essentially a compile-time hack. The Java VM is not generics-aware. Thus, when you write List in Java, the VM actually erases the type information and converts it into a List of Objects. Furthermore, to keep the VM happy, the compiler has to insert all of the type casts to Object that you didn't write as syntactic sugar -- but you get none of the execution efficiency associated with generics. Furthermore, you can't even use reflection to get the type information at runtime, because the VM's gone behind your back and erased all the information about it. You might say that Java generics gives you all of the sugar and none of the ice cream.

In C#, however, instantiation is deferred as late as possible. That is, no generic types are ever instantiated until you actually use them. This is in contrast to Java, where the compiler goes back and adds the type conversions everywhere. Result: big performance benefits over Java.

Additionally, C# allows you to put type constraints on parametrized types, which lets you demand that the parametrized type support a given interface. For instance, if your generic PriorityQueue class only makes sense if T supports the IComparable interface, you can specify that T must implement IComparable. Java has no such ability.

Function pointers: Whereas most instances of something point to some kind of value or object, C# has delegates -- instances which point to methods. The type of a delegate is the signature of the functions it can point to; a delegate cannot point to functions not of its type. This can be emulated in Java by defining interfaces which have a method with the same function type, but this is horrendously unwieldy and has enormous performance penalties. A somewhat cleaner solution in Java is to use inner classes, but these, too, are unwieldy.

Java over C#: There are some features in Java that don't have a close one-to-one analog in C#. These include:

-- checked exceptions: In C#, all exceptions are unchecked. That is, without access to the source code or accurate documentation, it is not possible to know what exceptions may be thrown by a method. This can potentially lead to unrobust code through unexpected failures. In Java, exceptions can be either checked or unchecked, and methods must declare what checked exception they throw with the throws keyword. Thus, users of C# classes are reliant on the documentation skill of the programmers, which is a less than optimal solution. (The .NET BCL documentation is widely considered rigorous and very good, however.)

-- write once, run anywhere: Java has a legitimate claim to being a portable, cross-platform language. Few if any changes are required for a nontrivial Java application to run on another platform. This is not the case with C#, however. Currently projects are underway for .NET implementations on Linux and FreeBSD.

-- extensions: Java developers can extend the core Java platform, and developers can create classes or packages that are subsequently treated as if they were core Java classes. Extensions are contained within JAR files, and once installed, are available to all applications running on the target platform. In C#, this would be analogous to creating assemblies that are treated as if they are part of the System namespace and inside the System.dll assembly.

-- strictfp: Java has the strictfp keyword, which enforces the non-use of extended intermediate values in floating-point expressions (conformance to IEEE 754). That is, if an intermediate value in a calculation exceeds the range of the type, the language is not allowed to switch to a wider type to hold the temporary result -- even if the final result is eventually in range of the type.

In integer terms, this would be equivalent to storing the value 254 in an unsigned one-byte-wide integer, adding 50 to it, then subtracting 50 from it. With a strict precision modifier in place, the compiler would not be allowed to use a wider type to hold the intermediate value of 304 (254 + 50) -- instead, the compiler would cause all subsequent values after the initial overflow to be "Infinity".

Section 4.1.5 of the C# specification covers floating point numbers and states that due to the excessive performance costs of enforcing that certain architectures perform operations with less precision than is possible, there is no way to enforce FP-strictness in C#.

-- dynamic class loading: Java allows clients to dynamically load classes at runtime. This is quite powerful when combined with some kind of remote procedure call mechanism. C# also supports this (remoting), but the server must publish the assembly and the client can then load it via a URL.

-- interfaces with fields: In Java, you may declare constants in interfaces, which are then available to implementing classes; in C#, you may not. Generally, declaring constants in interfaces is a poor emulation of enumeration, so you should avoid it anyway.

-- anonymous inner classes: Java allows you to specify a class declaration without a name inside another class. This is typically useful where only one instance of a type will exist in the application. The most popular usage of anonymous inner classes is for specifying callbacks. C# has no direct analog to this, but it does support anonymous delegates.

C# over Java: Conversely, there are some features in C# that don't have a close one-to-one analog in Java. These include:

-- properties: Properties are a way to abstract away from directly accessing the members of a class, similar to how accessors (getters) and modifiers (setters) are used in the Java world. It is possible to create, read-only, write-only or read-write properties depending on if the getter and setter are implemented or not.

-- pointers: Although core C# is like Java in that there is no access to a pointer type that is analogous to pointer types in C and C++, it is possible to have pointer types if the C# code is executing in an unsafe context. When C# code is executing in an unsafe context, most runtime checking is disabled, so the program must have full trust on the machine it is running on.

Since garbage collection may relocate managed (i.e. safe) variables during the execution of a program, the fixed keyword is provided so that the address of a managed variable is pinned during the execution of the parts of the program within the fixed block. Without the fixed keyword there would be little purpose in being able to assign a pointer to the address of a managed variable since the runtime may move the variable from that address as part of the mark & compact garbage collection process.

-- pass-by-reference: A method that swaps two numbers -- the hallmark of freshman computer science classes for years -- is impossible to do in Java without resorting to coding tricks. The C# keywords used to specify that a parameter is being passed by reference are ref and out. The difference between the keywords is that parameters passed using ref must be initialized to some value, while those passed using out do not.

-- variable parameter lists: In C and C++ it is possible to specify that a function takes a variable number of arguments. This functionality is used extensively in the printf and scanf family of functions. C# also allows one to define a parameter with the params keyword; this indicates that a variable number of arguments are accepted by the method. There is support for variable argument lists in Java 1.5/Tiger, but you pay a significant performance cost for using it some circumstances.

-- verbatim strings: C# provides the ability to avoid the usage of escape sequences within string constants and instead declare strings literally. Thus backslashes, tabs, quotes and newlines can be part of a string without using escape sequences. The only caveat is that double quotes that appear within verbatim strings should be doubled. Verbatim strings are specified by prepending the @ symbol to string declarations. Java does not support verbatim strings.

-- overflow detections: C# provides the option to explicitly detect or ignore overflow conditions in expressions and type conversions. Overflow conditions detected in code throw a System.OverFlowException. Since overflow detection causes a performance hit it can be explicitly enabled by using the /checked+ compiler option. One can also mandate code that must always be checked for overflow conditions by placing it in a checked block or that must always be ignored with regards to overflow detection by placing it in an unchecked block.

-- explicit interface implementation: When a class implements an interface, namespace collisions are possible with method names. In Java, there is no solution to this problem besides writing one method that does the same thing. C# doesn't have this problem, since you can bind methods to interfaces.

edit: I typed "compile time" instead of "run-time" in the reflections ection. Oops. Fixed.

[Edited by - kSquared on December 24, 2004 8:05:13 PM]

on anonymous inner classes, just because java has it, doesn't make it a good thing. just try to clean up after someone that used ONLY anonymous inner classes for the action listeners on a grid of about 10 buttons. It's a lot of fun, fun like sticking your fingers in a light socket with popcorn kernels glued to your naked skin. And if the l-user coded a bug into those anon classes, good luck ever finding where it is, as the debugger is incapable of determining the line number in the anon inner class.

In short, if you ever write an anonymous inner class on MY watch, you're fired. There are plenty of better ways around it.