AddThis Social Bookmark Button

Print

Conversational C# for Java Programmers
Pages: 1, 2, 3

Standard out, error, and in

The System.out, System.err, and System.in variables should be familiar to almost any Java programmer, with the first two variables being 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 Out, Error, and In. Out and Error are both System.IO.TextWriters, meaning that methods named Write and WriteLine can be used to send data to them. In, on the other hand, is a System.IO.TextReader. The ReadLine method can be used on In to read a line of text. C# also provides shortcut methods in System.Console named Write, WriteLine, Read, and ReadLine that will write and read from Out and In respectively -- these are the methods used in the example above. There are no shortcuts for writing to standard err.

Exceptions

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 Documentation

Java 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 csc.exe Running

csc Hello.cs

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.

Conclusion

If 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.