Java's Real Advantage over C#: Development Time

IDE: Java's IDE's are more advanced. I use JBuilder 2005 and it far exceeds Visual Studio 2003. JBuilder seems to understand more about Java syntax and rules then VS2003. JBuilder catches far more errors without the need to do a module or project rebuild. Oracle's Developer even includes Profiling tools. JBuilder is one of the easiest to use IDE's on the market so I haven't found the need to experiment with Eclipse. JBuilder has the ability to build Jar files for your project( Developer version ).

To catch all your errors in VS2003 you've got to rebuild your module often.

Database Technology: JDBC vs. ADO.NET. JDBC has Prepared Statements. ADO does not. Prepared statements allow you to design your SQL statements and allow them to change as your design gets approved. Then the Prepared statements can be converted to Stored Procedures with small modifications to the code. Prepared statements have a security advantage of not building a sql string which can be targeted as a buffer overflow attack

ADO.Net offers Command Objects. But command objects require a Parameters Collection. Which is an extremely time consuming piece of data that the database already knows. ADO isn't using the DB Metadata available nearly as well as JDBC. ADO does offer some efficiency/performance methods that just complicate the coding phase. You can execute a scalar query with the command object, but doesn't this kind of nanosecond optimization rightly belong in the VM or ADO engine? Of course.

Secondly, JDBC makes no bones about it. You've got to learn SQL to use JDBC. ADO attempts to isolate the programmer from learning SQL, but eventually it's got to occur. So you have two conflicting philosophies. The JDBC developer knows learning SQL is where he's got to go. This gives most Java developers an advantage.

C# vs. Java: C# wins the more needlessly complicated award every time. structs being another example of needless Programmer API nanosecond optimization that rightly belongs in the VM. Structs should be labeled as "Legacy" or "Deprecated". In an Object Oriented project all resources should be classes.

Java has a honed down elegance that C# doesn't possess. Java looks like version 2 of a good language. C# looks like another Kitchen Sink language in a long line of Kitchen Sink languages: C and C++ come to mind.

And to the Microsoft C guys: Instead of complaining about the speed of object creation in object oriented languages, do something about it: Optimize It. Remember, You write the compiler and the VM. We're not going back to C.

Checked Exceptions: In C# they aren't there. Therefore, you either have to continue to flip back and forth between the object browser window( assuming your business object has coded comments the exceptions the business object throws ), and your code page, or, more likely you can attempt to catch all exceptions with a general catch( Exception e ) block. Or, even better, you can ignore exception handling!

Java wins when it comes to coding Business Objects and being sure exceptions to your business rules are caught. Aside from the fact that having Checked Exceptions is much faster in the coding phase. Programmer fatigue when having to page over and over again to the Object Browser window is avoided. Plus, Java gives you the assurance that your programmers will Not Miss Any Exceptions.

The problem with Microsoft's approach is Not having Checked Exceptions produces MORE FRAGILE Code then having them.

C# Books: Disappointingly at the beginner level or worse. Just a mere glance at the table of contents of these books is scary. Most Don't cover Exception Handling. Nor do they cover at least issuing a function return code. Or a switch statement to examine the multiple possible return codes that would be needed in an environment that discourages using Exception Handling. Microsoft programmers: Still in Denial.

Of course, what's the point of checking an integer code from a function call, that you must interpret as a special type of error? Isn't that exactly what Exception Handling does?

Java's advantage is still there. Developing in Java and implementing on a Dual-Processor or Dual-Core server would be far cheaper that writing code in Visual Studio/C#/Your-DB-Here and implementing on a single cpu server. The dual processor might cost your $1000 in additional hardware, but the savings in programmer development time, in my experience an hour ratio of 3 to 1. Too much feature-i-tus and nanosecond optimization.

Microsoft has a decision to make here. They could move all those API optimizations out of the language and into the VM and ADO.NET engine. By moving more programmers out of the API group and into the VM group and taking their favorite optimizations with them they could still archive great performance. Plus, a simplification of the language would increase programmer productivity.

But, for now Java is still far more productive.

When catching an OracleException from the Microsoft Oracle client, read that error code:

1 == Unique Constraint -- Key already in the database.

Warning: This should be a recoverable error condition.
( Just Programmer Doc. )

1008 - Not All Variables Bound -- Here's the real Sink Hole -- One Generic Error Message that could mean almost anything:

- Check your Parameter Name Spelling
- Check Parm Order
- Max Parm Name Length: 30 chars.
- Strings, Numbers or Date fields cannot be NULL. If your data comes in null, send a DBNull.Value to the OracleParameter.

You will enjoy burning 10's of Hours debugging this useless error code.
Sorry, but this looks like Microsoft really setting a LOW BAR for themselves.

1036 - Illegal Variable Name / Number -- Sink Hole Alert:

Check your OralceParameter Names starts with a Colon -- ;pUSER, :pPASSWORD, :pCREATE_DATE...

It's hard to believe the ADO Driver really doesn't know what the real issue is here.
In an Oracle Parameters collection, you'd think the ADO engine would know just which Parameter it can't understand. Which just begs the question, why is this Parameter Collection even necessary. It's not in Java. Metadata should be interrogated not just for command objects using stored procedures, but for text commands as well.

That's ok Old Timer, Don't break a sweat for us.

1438 - Here's an easy one: Your data is too large. Size of Data exceeds size of field. Check your table definition.

( Programmer Doc. )

2291 - Integrity Constraint Violated

Another easy one: Check the order of your inserts.

( Programmer Doc. )

Right off the bat: Validation Controls only perform Client Side Validation in IE and in No Other Browser. They do perform server side validation, however, this may not meet your spec requirements. Thanks Microsoft. File this under promises not keep. Yeah, Just Bill up to his old tricks.

IE Specific Coding makes Asp Validation controls only work in IE

If you're stuck on Dot Net but you dream of the productivity and quality of Java keep an eye on: Microsoft Spec# ( beta )

There does seem to be a small cadre of developers at Microsoft that get's the Quality Imperative. The question is will this spec ever really be released? And will anyone in the Microsoft realm use it. An OPTIONAL package on Dot Net will be sure to disappear after the initial PR release.

This spec Finally brings Checked Exceptions to the table.

So, it looks like Experience based language design does better then design by Kitchen Sink Committee. It's usually true that the guy that implements the original idea usually has a better version then the guy who does the knock-off. This is just one example.

All of this just begs the question: Why did you leave the Java community? You're not giving us any real advantage over Java, so, other then an Expensive Megalomania, what was the point?