Standard out, error, and in
System.in variables should be familiar to almost any Java programmer, with the first two
java.io.PrintStreams while the last is a
java.io.InputStream; these variables allow access to the streams that they are named for. Any program can access these streams as if they were any other stream and manipulate them by sending data to and from them. To write something to standard out, the program typically calls
println on the System.out variable. Reading from standard in can either be performed by using the read method or, as in
Hello.java, by wrapping the
InputStream in a
java.io.BufferedReader and using it to read a whole line.
Support for this in C# is exactly the same: there are three variables in the
System.Console class named
Error are both
System.IO.TextWriters, meaning that methods named
WriteLine can be used to send data to them.
In, on the other hand, is a
ReadLine method can be used on
In to read a line of text. C# also provides shortcut methods in
ReadLine that will write and read from
In respectively -- these are the methods used in the example above. There are no shortcuts for writing to standard err.
In following the Hello example, you may think that there are almost no differences between Java and C# exceptions. Appearances can be deceiving. A fundamental difference is that all exceptions in C# are run-time exceptions; there is no concept of a compile-time exception in C#.
There will be a divide amongst programmers surrounding this choice. Many programmers will recognize this as an attempt to provide a faster prototyping environment; however, an equal number will notice that this will require programmers to be very careful when writing robust applications. The C# compiler does not inform the programmer when he is not taking into account an exceptional condition. What also may annoy certain programmers (the type that wishes to have as many problems as possible brought up at compile time) is that the thrown exceptions do not have to be listed in their method signature. This may make it more difficult to make sure that all possible conditions are being dealt with.
Source DocumentationJava programmers may embed JavaDoc comments; C# programmers may embed XML. The "javadoc" tool in the J2SE provides a way to use different doclets to guide the output of the generated documentation. By default, "javadoc" generates the familiar framed HTML. C# can use the compiler to generate a well-formed XML file containing the documentation from the source code that looks like
<?xml version="1.0"?> <doc> <assembly> <name>Hello</name> </assembly> <members> <member name="T:com.oreilly.hello.Hello"> <summary> a simple application that was ported from java to c# </summary> </member> <member name="M:com.oreilly.hello.Hello.Main(System.String)"> <summary> the entry point into this class -- this class will ask the user for his name, then reply to it </summary> <param name="args">the command line arguments</param> <returns> 0 if everything goes well, 1 if there is an error </returns> </member> </members> </doc>
The common next step would be to run this XML through an XSLT transformation to generate HTML or whatever other documentation may turn out to be helpful.
Compilation and Running
Hello.cs can be compiled using the
which generates a 3584 byte
Hello.exe file in the current working directory.
Hello.exe is a standalone program only relying on certain DLLs to be present from the Microsoft.NET SDK -- it can be run from the command line by simply typing "Hello" on the command prompt.
Compared to the 1284 byte
Hello.class file outputed by Sun Microsystem's JDK 1.3 for Windows, the
Hello.exe may seem bloated until you remember that the Java program must be run within a 20 MB Java virtual machine.
ConclusionIf you are a Java programmer, there is no reason why, after some basic reading, you should not be able to decipher any simple C# program as C# -- the concepts are the same, and most of the syntax is the same (with a few alterations and a few other additions). If you have a desire or need to program within the Common Language Runtime, or within .NET, read the rest of this series -- it should be pretty easy to figure out. This article is the introduction to a series of articles entitled "Conversational C# for Java Programmers." Each article will focus on different aspects of the language: the first covers objects, methods, syntax, and other concepts not necessarily familiar to the Java programmer. The second will cover IO and networking, the third, multithreading, and the last, GUI applications.
Raffi Krikorian makes a career of hacking everything and anything. Professionally, he is the founding partner at Synthesis Studios: a technological design and consulting firm that orchestrates his disjointed train of thought.
Return to the .NET DevCenter.
2005-06-10 02:57:14 reinux [View]
Java's other superpower: free and good libraries
2003-10-17 07:41:03 anonymous2 [View]
C# will likely have to run on Linux
2001-06-04 16:57:34 sanglin [View]
Will this poor man's Java run on Linux ?
2001-06-01 01:45:17 toboy [View]