Docstoc

Java to .NET – A Comparative Evaluation for Migrating Developers

Document Sample
Java to .NET – A Comparative Evaluation for Migrating Developers Powered By Docstoc
					Java to .NET – A Comparative Evaluation for Migrating Developers Mandip Singh Panesar MSc Information Systems 2004/2005

The candidate confirms that the work submitted is their own and the appropriate credit has been given where reference has been made to the work of others. I understand that failure to attribute material which is obtained from another source may be considered as plagiarism. (Signature of student) ________________________________

SUMMARY
The main problem being solved in this project is that there are no frameworks available guiding developers wishing to migrate from Java to .NET. The main aim was to produce a Technical Framework comparing both Java and .NET platforms, allowing awareness of the obstacles for the migration from one platform to the other. The focus was to explore Java developers wishing to migrate to .NET’s C# language. The Technical Framework forms the majority of this report and compares languages, library usage, performance and tools. The report also introduces Mono, a development platform based on Microsoft’s NET, which allows developers to construct Linux and cross-platform applications. The Technical Framework is supported by test programs and experiments to prove certain concepts. Recommendation Guidelines are also included, which act as an overview of the likely obstacles involved with migrating, providing developers with useful advice. To determine the success of the project, evaluation criteria were devised and the success of achieving each criterion was discussed. Questionnaires were used to establish the effectiveness of the Recommendation Guidelines. In conclusion, it was found that migrating from Java to .NET using the C# language is not a straightforward process. This is due to a number of differences between the two platforms, which add to the overall complexity of migration.

Keywords: Java, .NET, platform, C#, Technical Framework, Recommendation Guidelines, obstacles, migration, comparing, Mono, advice.

i

ACKNOWLEDGMENTS
I would like to thank the following people for their help and support during the project: My Supervisor, Dr Nick Efford for his invaluable advice and guidance. Dr Lydia Lau for her kind suggestions regarding the structure of the report. My parents, brother and cousins for their encouragement throughout. Classmates for participating in evaluating my work. Particularly Harsharan, for his unbiased opinions and beneficial advice on my progress.

ii

TABLE OF CONTENTS
1 INTRODUCTION ........................................................................................................................ 1
1.1 Problem ................................................................................................................................................... 1 1.2 Project Aim and Objectives ..................................................................................................................... 2 1.3 Project Approach..................................................................................................................................... 2 1.4 Project Management ............................................................................................................................... 3

2 LITERATURE REVIEW .............................................................................................................. 4
2.1 Introduction to Platforms ......................................................................................................................... 4 2.1.1 The Java Platform............................................................................................................................ 4 2.1.2 The .NET Platform ........................................................................................................................... 5 2.2 Frameworks............................................................................................................................................. 5 2.2.1 The Java Framework ....................................................................................................................... 5 2.2.2 Microsoft .NET Framework .............................................................................................................. 6 2.3 Programming Languages ........................................................................................................................ 7 2.3.1 The Java Programming Language .................................................................................................. 8 2.3.2 The C# Programming Language ..................................................................................................... 8 2.3.3 Java and C# Common Features ...................................................................................................... 8 2.4 The Mono Project .................................................................................................................................... 9 2.5 Summary: Technical Framework ............................................................................................................ 9

3 LANGUAGES.. .......................................................................................................................... 10
3.1 Language Basics................................................................................................................................... 10 3.1.1 First glance differences.................................................................................................................. 10 3.1.2 Identifiers and Keywords................................................................................................................ 11 3.1.3 Packages and Namespaces .......................................................................................................... 11 3.1.4 Structure of a class file................................................................................................................... 12 3.2 Features present in both languages...................................................................................................... 13 3.2.1 Selection and Iteration ................................................................................................................... 13 3.2.2 Parameter Passing ........................................................................................................................ 14 3.2.3 Explicit Method Overriding ............................................................................................................. 15 3.2.4 Exception Handling ........................................................................................................................ 15 3.3 Features exclusive to C#....................................................................................................................... 17 3.3.1 Properties....................................................................................................................................... 17 3.3.2 Structs (Structures) ........................................................................................................................ 18 3.3.3 Delegates ....................................................................................................................................... 18 3.3.4 Operator overloading ..................................................................................................................... 18 3.4 Features exclusive to Java.................................................................................................................... 18 3.4.1 Static imports – Discussed in 3.1.4................................................................................................ 18 3.4.2 Generics......................................................................................................................................... 19 3.5 Summary ............................................................................................................................................... 19

4 LIBRARY USAGE .................................................................................................................... 20
4.1 Introduction to Libraries......................................................................................................................... 20 4.1.1 Java API......................................................................................................................................... 20 4.1.2 .NET Framework Class Library...................................................................................................... 20 4.2 Library Similarities ................................................................................................................................. 21 4.3 Scenario One – General Library Usage ................................................................................................ 22 4.3.1 Core library comparison (java.lang Vs System) .................................................................... 22 4.3.2 Input/Output Library Comparison (java.io Vs. System.IO)............................................................. 25 4.3.3 Common Library Usage Summary ................................................................................................ 26 4.4 Scenario Two – XML Library Usage ..................................................................................................... 26 4.4.1 – Parsing XML Documents ............................................................................................................ 26 4.4.2 – Using XSL for transforming documents ...................................................................................... 27 4.4.3 XML Library Usage Summary........................................................................................................ 29 4.5 Scenario Three – GUI Library Usage.................................................................................................... 26 4.5.1 Java Swing..................................................................................................................................... 29 4.5.2 .NET Windows Forms .................................................................................................................... 29 4.5.3 Libraries Involved........................................................................................................................... 30 4.5.4 GUI Structure ................................................................................................................................. 30

iii

4.5.5 VAT Calculator Application ............................................................................................................ 31 4.6 Further Differences................................................................................................................................ 33 4.7 Summary ............................................................................................................................................... 33

5 CROSS PLATFORM DEVELOPMENT ..................................................................................... 34
5.1 Vendor’s perspectives ........................................................................................................................... 34 5.2 Porting Windows.NET Code.................................................................................................................. 35 5.3 Legalities over Microsoft .NET Implementation..................................................................................... 36 5.4 Future Developments ............................................................................................................................ 36 5.5 Summary ............................................................................................................................................... 36

6 BENCHMARKING .................................................................................................................... 37
6.1 Purpose ................................................................................................................................................. 37 6.2 The Approach........................................................................................................................................ 37 6.3 Benchmarking Code.............................................................................................................................. 37 6.4 Windows XP Operating System Benchmarks ....................................................................................... 38 6.4.1 Complete Program ......................................................................................................................... 38 6.4.2 Reading in Integers from File......................................................................................................... 39 6.4.3 Sorting Numbers in an Array.......................................................................................................... 39 6.4.4 Printing out to Terminal.................................................................................................................. 40 6.4.5 Windows Benchmark Conclusion .................................................................................................. 41 6.4.6 Reasons for Differences ................................................................................................................ 41 6.5 Linux Operating System Benchmarks................................................................................................... 42 6.6 Summary ............................................................................................................................................... 43

7 TOOLS………..................................................................................................................... ......... 44
7.1 Command Line tools ............................................................................................................................. 44 7.1.1 Java Versus Microsoft.NET Tools ................................................................................................. 44 7.1.2 Microsoft.NET Versus Mono Tools ................................................................................................ 45 7.2 Integrated Development Environments................................................................................................. 45 7.2.1 Eclipse Platform 3.1.0 .................................................................................................................... 45 7.2.2 Visual Studio .NET 2003 (VS.NET) ............................................................................................... 45 7.2.3 IDE Comparison............................................................................................................................. 46 7.3 Microsoft Java Language Conversion Assistant 2.0 ............................................................................. 47 7.4 Summary ............................................................................................................................................... 47

8 RECOMMENDATION GUIDEDLINES

................................................................................... 48

9 EVALUATION.…. ...................................................................................................................... 53
9.1 Original Objectives and Minimum Requirements .................................................................................. 53 9.2 Evaluation of the Process...................................................................................................................... 54 9.2.1 Reliability of Resources ................................................................................................................. 54 9.2.2 Thoroughness of Research............................................................................................................ 55 9.3 Evaluation of the Product ...................................................................................................................... 56 9.3.1 Confidence in Test Programs/Experiments ................................................................................... 56 9.3.2 Effectiveness of Recommendation Guidelines .............................................................................. 57 9.4 Summary ............................................................................................................................................... 58

10 CONCLUSION AND FUTURE WORK..................................................................................... 59
10.1 Conclusion........................................................................................................................................... 59 10.2 Future Work......................................................................................................................................... 59

REFERENCES ............................................................................................................................. 61 APPENDIX A – PROJECT REFLECTION.................................................................................... 63 APPENDIX B – MID PROJECT REPORT HEADER SHEETS ..................................................... 64 APPENDIX C – CODE EXAMPLES ............................................................................................. 67 APPENDIX D – SAMPLE QUESTIONNAIRES ............................................................................ 70 APPENDIX E – INITIAL AIMS AND REQUIREMENTS ...…………………………………………….73

iv

INTRODUCTION
1.1 Problem

1

The main problem being solved is that are no frameworks guiding developers wishing to migrate from Java to .NET. The main motivations for comparing Java and .NET can be looked at from two different perspectives. The first being technological, with the second being from a programmer’s point of view. a) Technological: In the past the Java and .NET platforms could not be directly compared. This was due to Java being well established (which is still the case) and .NET being relatively new. The .NET technologies have since matured and Microsoft’s Vision (Longhorn Idea) is now falling into place. In August 2004 Microsoft announced that their new operating system Windows Vista (previously named Longhorn) is set for release in 2006. Microsoft’s vision for Vista is that it will be a powerful new version of Windows giving people a new level of confidence, offering an improved level of reliability and security. John Trupin (Executive editor of MSDN Magazine) states that “The long term future is going to start with Longhorn and the inclusion of the .NET framework in its operating system core”. [1, 2, 3] Another aspect is cross-platform development. As Microsoft is only primarily interested in Windows operating system development, .NET was not directly comparable with Java, which offers cross-platform development. The Mono project has changed this, introducing the idea of cross-platform development to .NET, allowing a migration path for both Windows and Linux developers.

b) Programmer’s point of view: The second motivation is that programmers are actually interested in migrating from one platform to the other, particularly Java developers to .NET. Moreover, .NET has been designed to work tightly with the Windows Operating System and it arguably provides a more Windows like applications than Java.

1

1.2 Project Aim and Objectives To produce a Technical Framework comparing the Java and .NET platforms, allowing programmers to be aware of the obstacles for migration from one platform to the other. In particular Java developers migrating to .NET development using the C# language. Objectives: 1) Produce a Technical Framework comparing the essential features of Java and .NET platforms for application development. 2) Implement test programs in both Java and .NET languages aiding the comparison. 3) Produce a document, which contains obstacles for migrating developers to look out for. 4) Include an investigation into the Mono platform and discuss obstacles that Linux developers may be likely to face during migration. 5) A discussion of how Java and .NET technologies approach web service implementation. N.B. Minimum requirements for the project are objectives 1 to 3. Objectives 4 and 5 are classed as further enhancements. Below are expected deliverables: 1) Technical Framework – This forms the bulk of the report 2) Test Programs – Present in the Framework and Appendix 3) Recommendation Guidelines – Cater for both Windows and Linux developers 1.3 Project Approach Two main approaches shall be carried out in this project. The first is a literature gathering approach with the second an experimental approach supporting the literature. • Literature Gathering: This is the core approach behind the content that shall be included in the Technical Framework. Various resources will be consulted to gain an in-depth understanding of both Java and .NET platforms. These resources shall include text books, whitepaper articles and websites. Throughout the research, it needs to be made sure that resources used are both valid and reliable. These aspects shall be reflected on in the evaluation at the end of this project. • Experimental Approach: To support the content gathered from the literature, it is essential that some experiments be conducted to prove certain concepts. This shall involve developing numerous small
2

applications written in Java and C# and comparing the two approaches. The Rapid Application Development Methodology (RAD) shall be used to develop the applications. RAD shall be used over the traditional waterfall model because development is much faster. [4] Furthermore, only small applications shall be developed, therefore analysis and design phases are not required. With regards to any experiments, it is important that the results be measurable so an accurate analysis can be performed. The analysis could be descriptive, statistical or a combination of the two. 1.4 Project Management Project management was of great importance in this project, particularly time management. The original project plan can be seen below.

Milestones April 1 Background research Further research Experiment with .NET languages Produce development plan Development of small applications Evaluation based on applications Type up draft report Finalise report # # # 2 3 4 1 May 2 3 4 1 2

Month June 3 4 1 July 2 3 4 1 August 2 3 4 Sept 1 2

N.B - # indicates examination revision period

As this original schedule was devised before starting full time work on the project, a number of alterations were made during the project, changing the way the project was managed. Without these alterations, the project may not have been delivered on time. The alterations were as follows: • Altering project milestones: Although the background research and typing up of the main report were done as planned, some milestones were added with some removed. Producing a development plan was no longer required and experimenting with .NET languages was done throughout the project. Other milestones including chapters in the Framework and the Recommendation Document were added. • Concurrent tasks: Development of applications and experimentation was done alongside the research, which was not initially anticipated. Due to the added number of milestones, it was necessary to perform many tasks in parallel, not sequentially as shown. For example developing applications and conducting experiments was done alongside class library research. Regular meetings with the project supervisor were conducted during the project, usually one meeting per week. This raised valuable opportunities to show project progress and get feedback.
3

LITERATURE REVIEW

2

This chapter presents the Java and .NET platforms along with respective Java and C# programming languages. The relevant frameworks are also described showing the main components and processes involved in both compiling and running source code. The open source .NET implementation project called the Mono is also introduced. Platforms in the context of operating systems, such as Windows and GNU/Linux are discussed in later chapters. On completion of this chapter, the various sections of the Technical Framework shall be realised. 2.1 Introduction to Platforms A platform describes two types of framework, either hardware or software based. These can be in the form of a computer’s architecture, operating system, or programming languages and their runtime libraries. This project focuses on programming platforms, in particular Java and .NET. [5]
2.1.1 The Java Platform

The Java platform is a programming environment, which was commercially released by Sun Microsystems in May 1995 at their annual conference. Sun’s platform runs applications using a standard programming language and set of development tools. The platform is officially known as the Java 2 Platform, and includes a Standard Edition (J2SE), an Enterprise Edition (J2EE) and a Micro Edition (J2ME). [6] J2SE: This is a fast and secure foundation for both building and deploying client-side (Enterprise) applications. Enterprise applications support a wide range of users over a computer network, providing them with data and services to enable business-specific functions. J2SE technology operates with a high speed performance and flexibility to fulfil demands of web users. [7, 8] J2EE: This technology simplifies the overall process of developing Enterprise Applications by basing them on standardised, re-usable components called Enterprise JavaBeans (EJBs). One of the many advantages of EJBs is that of automatic deployment of components in an application server. This automation saves time and allows enterprise developers to focus on adding value, concentrating more on enhancing business logic rather than building infrastructure. [7] J2ME: This technology has found its way onto portable devices ranging from small smart cards or pagers to bigger devices such as set-top-boxes, making an appliance seem as powerful as a personal computer. J2ME technology allows device manufacturers to provide a service to its customers and gain a competitive advantage as they try to make innovative breakthroughs. [7]

4

2.1.2 The .NET Platform

Microsoft announced .NET as the next generation of Windows software in June 2000. The main difference with .NET compared to Microsoft’s previous development family was the moving away from solely Windows based or COM (component object model) development. .NET provides interoperability between its languages, which include C#, Visual Basic.NET, C++ and Java Script. The code in .NET languages is compiled down to CIL (common intermediate language). COM previously did this through binary specifications. [9] CIL has allowed developers with different skill sets (knowledge of different languages) to work together easily. This would particularly be ideal for projects requiring systems to be implemented in various languages. Furthermore, CIL offers interoperability with non Microsoft languages, such as COBOL, Eiffel, Perl, Python and Java. This is ideal for non Windows developers approaching .NET and simplifies porting existing applications to .NET. [9] 2.2 Frameworks Both Java and .NET frameworks are discussed, showing the compilation chain of source code.
2.2.1 The Java Framework

The Java platform has two main components. These are the Java Virtual Machine (Java VM) and the Java Application Programming Interface (Java API). [10] Java VM - Java programs can run on a wide variety of hardware and software platforms. This is possible because a Java program does not execute directly on your computer, it runs on the Java VM. Java source code written by programmers is converted into Java bytecode via a compiler. This is an equivalent of Microsoft’s intermediate language (MSIL). Bytecode is necessary, as these are the instructions understood by the Java Virtual Machine. Java bytecode represents the compiled Java file, often known as the class file. Within the Java VM is a program called the Java Interpreter, which inspects and deciphers the bytecode to make sure it has not been tampered with and is safe to execute. The Java VM then executes the bytecode to perform the programs action in accordance to its internal specifications. [10, 11] Similarly to .NET, just-in-time (JIT) compilers can be used by the Java VM with code being translated down to native machine code; however this is optional, whereas in .NET it is compulsory. More details on JIT in Section 2.2.2. Figure 2.1 illustrates the complication process that has been discussed above.

5

Java Source Code

Java Compiler

Java Object Code Object/bytecode verified and loaded

Java virtual machine Program executed Java interpreter

Optional JIT compilation producing Native Code Computer Operating System Figure 2.1: Java Compilation Chain [11]

Java API - Is a vast collection of software components that provide programmers with some useful capabilities such as graphical user interface (GUI) tools. The API is grouped into fully reusable libraries of related classes and interfaces, which are available for use within Java programs. [10] The Java Framework is available to download at no cost from the Sun Microsystems homepage and is called the Java Development Kit (JDK). JDKs are public releases of the J2SE and J2EE components mentioned earlier. The latest JDK, version 5.0 and shall be used throughout this project. The JRE (Java Runtime environment) provides the basic logic for running Java applications, with the SDK (Software Development Kit) used for application development. The major advantage of the Java Framework is that it is platform independent with implementations available for Microsoft Windows, GNU/Linux and Apple Mac OS. [11]
2.2.2 Microsoft .NET Framework

ECMA and ISO Standards Bodies approved Microsoft’s C# and CLI (common language infrastructure) standards. Anyone who wishes to implement their own version of CLI may do so. The CLI represents the basis for running different programs in .NET. The first commercial version of the .NET Framework was released in February 2002 and included Microsoft’s new CLI implementation. CLI allows all programming languages in the .NET Framework to be complied down to Microsoft’s intermediate language mentioned earlier. [9] The .NET Framework is split into two parts. These are the Common Language Runtime (CLR) and the .NET Framework Class Libraries. The CLR is based on the CLI and is a virtual machine on which code runs. [9]

6

Microsoft released a supplementary toolkit with .NET called the .NET Framework SDK. The current release of the SDK is version 1.1 with the release of version 2.0 imminent. Version 1.1 shall be used during this project, as this is the latest full release available. As well as the compiler, the SDK is shipped with a number of useful command line tools including an IL assembler (ilasm.exe) and an IL disassembler (ildasm.exe). [9] Figure 2.2 shows how the .NET Framework handles program code through from the high level .NET source code, down to low level machine code. .NET source code may be C#, C++, VB.NET or J#. The appropriate compiler will translate the code into Microsoft’s Intermediate Language. It then runs on the CLR with lower level execution performed on the operating system. Code at the lowest level is called native code and just-intime (JIT) execution is performed by the CLR. JIT compilation allows code to be compiled on the fly, as required. The first time a method is called there is often a delay; however once JIT compilation has been performed the method is cached, therefore loads faster when re-called. [12]

.NET Source Code

.NET Complier

Microsoft Intermediate Language

Intermediate language verified and loaded

Program executed

Common Language Runtime (CLR)

JIT compilation producing Native Code Computer Operating System

Figure 2.2: .NET Compilation Chain

2.3 Programming Languages Since Java is the only programming language available on the Java Platform, it shall be compared with the .NET’s latest C# language, as this the most likely language migrating developers will be willing to learn.

7

2.3.1 The Java Programming Language

Java is based on C and C++ programming languages. It was designed by Sun Microsystems in 1990-1991, with the team led by James Gosling. Even though the team started with the basic syntax of C and C++, they were not constrained to use all the features of these languages. It was decided that the language should be object-oriented and as concise as possible. [13]
2.3.2 The C# Programming Language

C# (pronounced C Sharp) is described by Microsoft as “a simple, modern, object-oriented, and type-safe programming language”. C# will be familiar to C, C++ and Java developers, as some features have been inherited. C# supports Rapid Application Development (RAD) and has the raw power of C++. [14] The Visual Studio .NET suite is Microsoft’s main development tool, which is often referred to as an IDE (Integrated Development Environment). Visual Studio contains Visual C# .NET, allowing C# programmers to develop, compile and debug applications. All .NET languages, including C#, C++, Visual Basic .NET and Jscript have access to the same .NET Framework class library (FCL). The FCL is part of the .NET Framework, as opposed to the Java API, which is considered part of the language. [14] C# shall be used as opposed to other .NET languages during this project because unlike other .NET languages, C# has been specifically designed from the ground up to support the .NET Framework. [15] From looking at various online resources, it also appears as though there is more support available for application development in C#, which instantly appeals to Java developers.
2.3.3 Java and C# Common Features

• • • • • • •

Both languages compile to an intermediate format. Java compiles to bytecode with .NET applications compiling to MSIL. Both are run in a managed environment. Each environment supports automatic garbage collection. Classes descend from Object and are allocated on the stack during creation. Multiple inheritance is abandoned. Use of exceptions for error handling. Code comments produce API documentation. Classes are arranged in a package/namespace to avoid type collision.

[16] The features mentioned above are very general. Chapter 3 examines features of the languages in greater detail.
8

2.4 The Mono Project Mono is an open source development framework based on Microsoft’s .NET framework. The Novell sponsored platform allows developers to build Linux and cross-platform applications, with its .NET implementation based on ECMA standards for C# and CLI. As well as Linux, Windows and Mac OS operating systems can be used for Mono development. It includes developer tools and the underlying infrastructure required to run .NET client and server applications. [17] On top of Microsoft’s .NET, Mono includes some Mono-specific enhancements, including a number of additional libraries. These include a debugging API, Gnome platform integration, Open GL graphics and extensive database support. The main advantage Mono has over Microsoft .NET is its open source nature, allowing anyone to analyse or alter Mono’s inner workings. [9] Mono’s aims are to firstly provide the best tools for programmers to develop applications for free operating systems. Secondly, it aspires to provide interoperability by allowing those systems to fit in with other standards i.e. Windows. [18] 2.5 Summary: Technical Framework From the research gathered it is clear that the following aspects should be compared in the Technical Framework. • • • • • Languages – Both Java and C# language fundamentals shall be compared and contrasted. Libraries – The Java API shall be compared against features offered by the .NET FCL. Cross Platform Development – Facilities for developing applications on a non-windows platform. Efficiency – The efficiency of running applications on the two platforms shall be compared. Tools – Comparing tools available for Java and .NET, aiding application development.

The above sections shall be constructed with a view to migrating developers, particularly Java developers moving to .NET development. Each section of the Technical Framework is presented as a chapter in the overall project report. After the Framework has been formulated, the Recommendation Guidelines aimed to help migrating developers can be constructed.

9

LANGUAGES

3

The first component of the Technical Framework presents the fundamental similarities and differences between the Java and C# languages. The aim is not to examine every language feature, as this would require many pages, but focus instead on features that would be of interest to first time C# developers. 3.1 Language Basics This subsection compares the language fundamentals, which would be the starting point for migrating developers in learning some of the basic differences between the two languages.
3.1.1 First glance differences

A good starting place for the comparison is to look at a simple HelloWorld program in both Java and C#, observing similarities and differences. Code is shown in Figure 3.1 below:
Java public class HelloWorld { public static void main (String args[]) { System.out.println("Hello World!"); } } } } Figure 3.1: Hello World Code C# public class HelloWorld { public static void Main (String args[]) { Console.WriteLine("Hello World!");

As you can see from the code, both structure and syntax looks similar at first glance. The similarities and differences in the HelloWorld program are highlighted in the Table 1.
Feature Java C#

Declare class HelloWorld The main method

- Letter ‘H’ capitalisation is optional - Entry point to program - Must be declared as public - ‘m’ in main must be non-capitalised - There must be a parameter list present: main(String [] args)

- Letter ‘H’ capitalisation is optional - Entry point to program - The public prefix is optional - ‘M’ in Main must be capitalised - Parameter list in main is optional and may be omitted: Main() - Referred to using ‘;’ symbol
10

End of line

- Referred to using ‘;’ symbol

Table 1: Hello World Comparison

Through comparing such a simple program, there are instantly noticeable differences between the two languages. It appears as though Java is stricter than C#, as it has a number of compulsory language syntax requirements that need to be followed when coding. C# looks to have more relaxed requirements.
3.1.2 Identifiers and Keywords

Identifiers are names chosen by programmers for their types, methods and variables. An identifier must be a whole word made up of Unicode characters, digits, currency characters and must not clash with keywords. Furthermore, they must not start with a digit. Keywords are often referred to as reserved words. [19, 27] • • Java 5.0 contains 52 keywords [19] C# 1.1 contains 80 keywords [20]

The C# language has more keywords than Java (54% more), which adds to the complexity of C#. On the upside, many common keywords found in Java are also found in C#. In fact 38/52 (75%) of Java keywords are found in the C# programming language with the remaining ones mostly having a C# equivalent.
3.1.3 Packages and Namespaces

Both Java and C# have libraries containing pre-written classes. In Java these classes are organised in packages, which are classes grouped according different functional areas, for example input/output and xml. The equivalent in C# is referred to as a namespace. A simple line of code which outputs text to the display is shown below for both Java and C#, with comments showing similarities. Java code

java.lang.System.out.println("Hello World!");
Package in Java library Class in java.lang package Uses a standard output stream

Static method of the out

String to display

C# code

System.Console.WriteLine("Hello World");
Namespace in .NET library Class in the System namespace

Static method of the Console class

String to display

11

A similarity is that the package/namespace and class references are capitalised in both Java and C#. Method references are different, as Java recommends them to be lowercase with C#’s code convention being uppercase. It appears to be harder to distinguish between a method and class in C# because both start with uppercase characters.
3.1.4 Structure of a class file

Each class has a structure in which key components need to be added. These include adding packages, library imports and class declarations. Figure 3.2 shows how the languages differ in class structure.
Java package test; using System; using System.Xml; import static java.lang.System.*; import java.xml.*; class Hello { out.println(“Hello World”); } } Figure 3.2: Class Structures namespace test { class Hello { Console.WriteLine(“Hello World”); } C#

There are differences in the order in which the main components are added to a class. In Java, package declarations come before library imports; however this order is reversed by the C# class. C# also differs, as extra brackets are required to nest the code surrounding the namespace declaration. The keyword import allows a Java class to be referenced without the name of the enclosing package. The
using keyword performs a similar purpose in .NET. In Java the core package, java.lang is available by

default and does not need an explicit import statement. C# requires the core System namespace to be explicitly imported. Java 5.0 has a new feature known as static imports, which is shown in Figure 3.2 with the keywords import
static being used. Static imports allow the static members of a class to be referenced without using the

name of the containing class. C# does not support such a feature. [21]

12

3.2 Features present in both languages
3.2.1 Selection and Iteration

The if-else statements are very similar in both languages, as is the switch statement. Loop statements (while, do-while, for) are also very similar. C# has an extra for-each loop which allows you to loop through each element in a collection without the need for a counter initialisation. The keyword foreach is accompanied by in, which indicates the indexer in the structure being counted. An array provides a good example of a foreach statement. The code below extracts integers from an array testArray.

C# foreach (int i in testArray) { Console.WriteLine (i); }

The code reassigns each integer in testArray to the integer i and then prints the value of i. Through past experience it initially appears as though there is no equivalent offered by Java and a traditional for loop with a counter will be required. This is not the case as the latest specification of Java, version 5.0, has introduced an enhanced for loop. The code below shows Java’s equivalent of C#’s foreach statement. As with C#’s foreach loop, Java’s enhanced for loop does not require a counter or length check. This eliminates out of bounds compiler errors. The advantage of Java’s implementation is that there is no need for an additional keyword, which slightly reduces overall language complexity.

Java for (int i : testArray) { System.out.println (i); }

13

3.2.2 Parameter Passing

Each method has a sequence of parameters, which are used to define the set of arguments that must be provided for that method. Typically parameters are passed by value, which is common to both Java and C#. This is illustrated through the Java code below: [20]
public class Parameter { static void Foo (int p) { p++; } public static void main (String [] args) { int x = 8; Foo(x); System.out.println(x); } }

Assigning p a new value does not change the contents of x, as p and x exist in different memory locations. C# provides a feature allowing a parameter modifier ref to be used, which allows both p and x to refer to the same memory locations. Such a feature is not present in Java. An example of its use is shown in the C# code below: [20]
using System; public class Parameter2 { static void Foo(ref int p) { ++p; } static void Main() { int x = 8; Foo(ref x); Console.WriteLine(x); } }

[19]

The ref modifier allows p to be assigned a new value which also changes the contents of x, as a reference of x is assigned to a reference of p. A more useful example illustrating the use of the ref modifier is in a
14

swap method (Shown in Appendix C.1). Implementing an equivalent method in Java can be done; however is not the most natural way to swap two strings. The Java equivalent is also shown in Appendix C.2. [20]
3.2.3 Explicit Method Overriding

C# differs to Java when calling a method of the same name inherited from another class and changing its behaviour. This is known as overriding that methods behaviour. [22] The difference occurs because C# requires explicit method overriding, with the keyword override required. Another difference is that the keyword extends used in Java for extending a class is replaced by the : symbol in C#. The method being overwritten (base method) must be declared as either virtual, abstract or override. This is also not required in Java further suggesting that C# has added complexity. [19, 20] In the C# code example below a class Ferrari extends Car and overrides the EngineSize method to return a new engine size.
public class Car { public double engineSize; public virtual engineSize () { EngineSize = 1.0; return EngineSize; } } class Ferrari : Car { public override engineSize () { engineSize = 4.3; return engineSize; } } 3.2.4 Exception Handling Keyword override explicitly needs to be used : in C# instead of extends in Java

In both Java and .NET, errors that occur at runtime are handled in a consistent way through exceptions. Java and C# both provide syntax for working with exceptions, with the fundamental mechanisms being embedded in the JVM and CLR. [23]
15

Try/catch blocks are used by both languages to handle exceptions. Figure 3.3 shows how the languages approach exception handling.
Java Code try { x = y/z; System.out.println(x); } catch(AritmeticException e) { System.out.println("Caught arithmetic exception"); } catch (Exception e) { System.out.println(e); } } catch(System.DivideByZeroException) { Console.Writeln("Caught arithmetic exception"); } catch (exception e) { Console.Writeln(e); } Figure 3.3: Exception Handling [20] try { x = y/z; Console.Writeln(x); C# Code

Primarily the calculation divides an integer y by an integer z, assigning the result to an integer x. If z was zero, an exception would be caught in the catch block, as it is not possible to divide by zero. An error message would be subsequently printed out to the terminal. The first catch block implicitly catches the arithmetic exception thrown by this program, with the second catching any other exception that may be thrown. [23] As you can see, the code looks very similar, both in terms of keywords used and the order in which they are used. The subtle differences that do occur are solely to do with method calls, as the underlying libraries are different (discussed in Chapter 4). Both languages also support the finally statement, which gets executed whether an exception occurs or not. A noticeable difference between the two languages is the absence of the throws declaration in C#, therefore the programmer is not forced to choose between catching exceptions or declaring that those exceptions are thrown by the methods. Conversely, in Java, if a method throws a checked exception such as
java.io.IOException, the calling method must either catch and handle that exception, or else declare

that it can throw IOException. Failure to do one of these two things means that the code will not compile. C# programmers have to rely on the API in order to check for the exception to be handled. It appears as though Java’s approach is stricter than that of C# for handling exceptions. [15] As a programmer it is essential to catch exceptions that we cannot explicitly define, as software often behaves unpredictably. As discussed both languages offer this ability; however there are differences. [23]

16

3.3 Features exclusive to C# Through studying the languages, it is clear Java and C# are predominantly similar. Java developers migrating to C# would therefore be particularly interested in the features that are exclusive to the C# language. Some of those features shall be briefly discussed in this subsection.
3.3.1 Properties

These are object oriented fields. A field is a name given to a variable or a method name. The purpose of a property is to support encapsulation, allowing a class to control access to its data whilst hiding the internal representation of that data. [20] An example to illustrate this is the use of simple get and set accessors to both get and set field values.
public class Money { int pounds; public int Pounds { get } set Keyword value used as a variable for setting new Money object instances } } static void Main() { Money m = new Money(); m.Pounds = 20; Console.Writeln(m.Pounds); } } Automatically uses the get method Automatically uses the set method { if(value<1) thrownewOutofRangeException(“Please enter a value greater than 1”); pounds = value; { return pounds;

[12] Java loosely implements this concept of properties using the get-set method convention in two separate methods, which must be called explicitly. C# allows the get and set accessors to be associated with a single property and makes implicit calls when that property is accessed, resulting in a more natural representation.

17

3.3.2 Structs (Structures)

A struct is similar to a class; however has the following differences: • A struct is a value type, whereas a class is a reference type. The main use of structs is therefore in situations where value types are preferred over reference types. [20] Structs are useful for defining primitive ‘data bundles’, for example a Point struct as a combination of x and y coordinates. [42] • Classes fully support inheritance; however structs do not. Structs can inherit from any object, just like any other class but not from another struct or class. [20] • Structs cannot override methods, whereas classes can. [20]

3.3.3 Delegates

Passing references to methods is a very common thing in programming. For example telling a piece of code what method should be called when a specific event occurs. Pointers are common in the C language for pointing to a method to be invoked; however this is not available fully in C# due to the fact that pointers contain major security flaws. Pointers do not pass by reference; they pass by the physical address (i.e. in memory). One of the main security flaws with pointers is that of pointing to an insecure method, which does not have privileges to execute. [20] Delegates have been introduced into the C# programming language, providing the flexibility of pointers in a type-safe manner. A delegate is an object, which contains a reference to a method with a specific signature. Once created and initialised, it can be passed as a parameter into another method and then invoked. [20]
3.3.4 Operator overloading

All unary and binary operators have pre-defined implementations in both languages and are available for use in any expression. C# allows you to choose the way you wish to handle the operation performed by an operator, instead of just using the default operation. This is known as operator overloading and is not available in Java. It is not possible to overload all operators so the .NET documentation should be checked to see what can and cannot be overwritten. Once again this feature is inherited from the C++ programming language. The keyword operator is specifically used for overloading purposes. [20, 24] 3.4 Features exclusive to Java
3.4.1 Static imports – Discussed in 3.1.4

18

3.4.2 Generics

Generics have recently been added to Java 5.0. They allow you to specify the type a collection should hold to the compiler, which is safer than having a collection that could contain many different types. The example below shows how an ArrayList is made type-safe, being only allowed to contain string objects. [25]
ArrayList<String> al = new ArrayList<String>();

Now suppose we wish to add objects to that ArrayList:
al.add("A string"); al.add("Another String"); al.add(new Integer(2));

The first two lines of the above code shows two string objects being added to the collection. This is legitimate, as the ArrayList is specified to contain only objects of type string. The third line adds an integer object to the ArrayList. An error is produced at compile-time; hence the code is type-safe. [25] Suppose we wish to get these string objects out of the collection. The enhanced for loop can be used for this because we know for certain that the ArrayList contains only objects of type string, therefore no additional checking is required.
for (String s : al) { System.out.println (s); }

In C# suppose we wish to extract elements from the ArrayList using the foreach statement. If the ArrayList contains both string and integer objects, this would produce an error at run-time and is not picked up by the compiler. Therefore, C# is not completely type-safe due to generics being non-existent. 3.5 Summary By and large, Java and C# are very similar languages. There are some key differences, in particular the way in which parameter passing and exception handling are performed. The generics feature, currently exclusive to the Java, is due to be included in the next .NET release, version 2.0. When comparing Java with C#, it is important that the latest Java release always be referred to, as enhanced for loops, generics and static imports are just some of the recent additions to Java 5.0. C# has features not present in Java such as properties and delegates. It remains to been seen whether future releases of Java have these features, including those found in future editions in .NET 2.0.
19

LIBRARY USAGE

4

This section presents and compares features of the Java API and the .NET Framework Class Library (FCL). Migrating developers will be keen to know what the similarities and differences are between the two libraries. Differences could fall into the following two categories: • Physical differences – These occur with naming principles between the packages and where they are located. Do the packages in the Java API have an equivalent in the .NET FCL and to what extent? These issues shall be explored. • Behavioural differences – Such dissimilarity could occur when similar methods in Java and .NET classes offer different behaviours. Certain tasks may need to be done in a different way, as the libraries may offer classes with different methods. 4.1 Introduction to Libraries The Java API and .NET FCL are standard libraries which contain pre-written code and are part of the respective software development kits (SDKs). Libraries reduce the amount of coding developers need to do, as pre-written code can be simply reused, increasing convenience and saving time.
4.1.1 Java API

The Java API (Application Programming Interface) contains classes and interfaces grouped together in a number of different packages. Packages are named according to the functionality they provide. The core package is java.lang. [26] The Java 2 Platform Standard Edition 5.0 API Specification is the latest API released to date therefore all test programs are subsequently compiled and run on this latest platform specification.
4.1.2 .NET Framework Class Library

Microsoft’s .NET FCL has been organised similarly to Java, in a hierarchy of namespaces. Each namespace may contain types such as classes or interfaces, as well as sub-namespaces. [23] The library can be used by any .NET language, which is advantageous to developers switching between .NET languages, as they will be familiar with namespace declarations. The core namespace of the framework is System and every .NET application will use some of the types it contains. [23]
20

4.2 Library Similarities Table 2 shows a sample of Java API packages with the equivalent .NET FCL namespaces. A common description of each package/namespace is included.

Java API java.lang System

.NET FCL

Description

Contains core classes and interfaces, which are most central to both languages and are commonly used. It contains types that allows synchronous and asynchronus reading and writing on data/byte streams.

java.io java.nio

System.Io

java.util

System.Collections System.Globalization

Contains a number of useful classes, in particular collection classes that are often useful when working with groups of objects. Time and calendar classes are also included. .NET is more neatly arranged with a sub-namespace Globalization used for time/calendar classes.

java.NET

System.NET System.NET.Sockets

Contain classes for network programming. In particular through the use of sockets. Both Java and .NET provide a comprehensive service provider architecture to handle security and cryptographic operations in particular. Classes provide secure access control and authentication through the use of message digests and digital signatures.

java.security

System.Security

javax.xml

System.xml

Provides support for managing XML documents, in particular parsing. (section 3.2) Represents classes, interfaces and objects in the current JVM/CLR. Classes used for building graphical user interfaces (section 3.3)
Table 2: Class Library Similarities [19, 20, 23]

java.lang. reflect java.awt java.swing

System.Reflection

System.Drawing System.Windows.Forms

21

Table 2 shows packages/namespaces in Java and .NET that appear to map effectively i.e. contain the same group of classes. To see how effectively these libraries map so a few examples programs are written testing the mappings. Primarily a Java program will be written followed by the C# equivalent. As well as testing the mapping, the ease of porting a Java application to C# studied. This is measured subjectively and quantitatively, comparing lines of code where applicable. The following groups of library shall be compared to test the mappings: • • • Scenario One - General library usage (Section 4.3) Scenario Two - XML library usage (Section 4.4) Scenario Three - GUI library usage (Section 4.5)

4.3 Scenario One – General Library Usage This section compares some common features available in both the core packages/namespaces and other common classes. In particular the use of the string and input/output classes shall be compared.
4.3.1 Core library comparison (java.lang Vs System) The String Class

The string class is found in both the Java and .NET framework core class libraries. Working with strings is very common therefore it is interesting to see how the use of strings differs between Java and C#. The first noticeable difference is that the String object in Java is referred to as String (uppercase ‘S’). In C# it is referred to as string (lowercase ‘s’) or String (uppercase ‘s’). Java and C# both are referring to the objects of the string class. However, C# also has string as a keyword, which is an alias for the String object of a class and therefore can be used interchangeably. This causes confusion for migrating Java developers. [16] Some examples of common string operations shall be looked at in turn and compared.
• Concatenation

Figure 4.1 shows concatenation code in the two languages. Three strings are declared and then concatenated using the appropriate method. Concatenating the string produces the output ‘abcdefghi’.

22

Java

C#

String x = "abc"; String y = "def"; String z = "ghi"; String c = x.concat(y+z);

string x = "abc"; string y = "def"; string z = "ghi"; String c = String.Concat(x,y,z);

Figure 4.1: String Concatenation

The same method name ‘concat’ is used in both Java and C# except for the common difference in case sensitivity. In the Java example you can see that concat is applied to a pre-defined string and is concatenated with other strings via the ‘+’ symbol. C# works slightly differently. The concat method in C# is static, which means it does not need to be assigned to an object like in Java. Instead all strings which are to be concatenated are written inside a bracket, separated by commas. C#’s representation seems more natural, therefore is easier to use than Java’s.
• Substring Method

The substring method is used to produce an output from a string, taking a specified range of characters. The examples show a string ‘abcde’ having substring applied. Both Java and C# have the same ‘substring’ method name with the difference in case sensitivity present.
Java: String c = "abcde".substring(1,4);

Start Index

End Index

In the method above, the first argument is zero-based, which means the first index position starts at zero. Unfortunately the second argument is not zero-based, which means it starts counting from 1. This therefore produces the output ‘bcd’. [27]
C#: string c = "abcde".Substring(1,4);

Start Index

End Index

In C# the substring method works similarly. Porting the Java code directly to C# compiles successfully; however ‘bcde’ is produced, which differs from Java. This is because unlike Java, both arguments are zerobased.
23

•

Finding specific character

Java and C# differ in the way that a character is returned from a specified location in a string.
Java: c.charAt(4) – returns the character at index 4 of the string c.

C#: c[4] – returns the character at index 4 of string c. This eliminates the use of a charAt method and

instead references a character through an array-like index value. This representation appears to be more natural than Java’s.
• Similarities with the string class

Table 4.2 shows some widely used methods that work similarly in both Java and C#. They also appear to have similar method names.
Java C#

length() toUpperCase() toLowerCase() indexOf() toString()

Length() ToUpper() ToLower() IndexOf() ToString()

Figure 4.2 String class method similarities • String class summary

There are differences and similarities in the way the String class is used by both languages. Some methods have the same names in both classes; however their behaviour is different, for example the substring method. Furthermore, equivalent methods are often named differently, for example charAt. This inconsistency amongst the two classes makes it particularly problematic for migrating developers and may cause confusion. The string class is just one of many in the core libraries, therefore further differences should be expected throughout the comparable classes. As a result, it is important that the API documentation be consulted prior to C# development, particularly involving classes that named similarly to Java.

24

4.3.2 Input/Output Library Comparison (java.io Vs. System.IO)
Reading from File

Java and C# provide methods for reading and writing to and from a text file. Figure 4.3 compares sample code, which reads lines from a text file and prints them to the display. In Java a class called FileReader is used. Correspondingly C# uses StreamReader. FileWriter and StreamWriter are the respective classes used to write to a file. N.B. The full program code is present in Appendix C.3
Java C#

FileReader read = new FileReader("c:/ ../../brown.txt"); BufferedReader input = new BufferedRe. ..ader(read); String str; do { str = input.readLine(); System.out.println(str); } while (str != null); read.close();

StreamReader read = new StreamReader("c:/ ../../brown.txt"); string str; do { str = read.ReadLine(); Console.WriteLine(str); } while (str != null); read.Close();

Figure 4.3: Reading from a text file

There is little difference between the code and only minor changes are required during porting. Apart from the difference in classes used, Java’s implementation requires an additional BufferedReader to read the values from the text file. The readline() method is then applied to the buffered reader in order to read the contents of the text file. C# does not require this additional class, instead its StreamReader has the
ReadLine() method built in. Both Java’s FileReader and C#’s StreamReader have a close() method

to terminate the readers safely. This shows that there is minimal re-coding required when porting to C# from Java and vice-versa, with Java taking 8 lines of code and C# taking 7.
• I/O Summary

Many things are the same with regards to reading and writing to file. However, C Sharp has a useful
ReadLine() applied to the reader, eliminating the need for an additional class; BufferedReader. This 25

makes the C# code simpler; however this would cause a slight irritation for the Java developer, as things work differently from what they are accustomed to.
4.3.3 Common Library Usage Summary

Findings suggest the majority of program code ports from Java to C# quite well. However, studying the string class shows there are differences in class behaviour. By and large, C# makes it relatively easy for Java developers wishing to program I/O applications. Unfortunately, subtle differences in behaviour add to the overall complexity of migrating. 4.4 Scenario Two – XML Library Usage This section compares the XML class libraries, as XML processing is of increasing interest to developers. Both parsing XML and the use of XSLT are studied with key differences acknowledged.
4.4.1 – Parsing XML Documents

There are two de facto standards for parsing XML documents. The W3C recommended standard is DOM (Document Object Model) with the other SAX (Simple API for XML). [19] DOM is used to describe an XML document in a tree-like structure with each XML element being represented as a node in the tree. It works by parsing in the entire document, storing it in memory, and then working on the document present in memory. [19] SAX reads XML documents in an incremental manner, line by line. Due to the fact that input is continually being streamed, no permanent representation of the document is composed. [19] The two main packages required for parsing XML are Java’s javax.xml and C#’s System.Xml
• Example Application

An application was written to show how Java and C# differ in the way the DOM parser is declared and used. A DOM parser has been implemented as opposed to SAX because it is more commonly used and is standardised. [23] The XML document to be parsed is in an offline format and contains various news headlines. The aim this example is to extract the useful content from the XML document containing the title, link, description and publication date of each headline. (The XML document is found in Appendix C.4.1)

26

DOM Parsing – Table 3 highlights the similarities and differences of using the DOM standard for parsing the news headlines. Please refer to Appendix C.4 for the full Java and C# code.
Java C#

The object we are working with is named by Java as Document. Requires a DocumentBuilder that allows you to build up your own document. This has various options regarding validation of the document.

The object we are working with is named by C# as
XmlDocument.

An XmlNode is used to build the document. No validation options are available.

Both a FileInputStream and BufferedReader are An XmlTextReader is used to read the XML file. required to parse the XML file. a list. Simpler than Java. the XML document (XPath), for example:
<rss/channel/item>. This may be problematic

Elements are obtained by Tag name and placed into Elements are obtained by knowing the structure of

when parsing files with different structures. A for loop is used to get sub elements out of the list. Two for loops are used to obtain the sub elements. Looks very complex. Total Program Line Count = 71 Lines Implementation looks far more concise than Java. Total Program Line Count = 48 Lines.
Table 3: DOM parsing comparison

The comparison shows that many of the differences that exist stretch further than that of merely naming classes and methods. Java does have some advantages over C#, which give the programmer greater flexibility with what can be done to the document. For example, a greater degree of validation can be performed and extracting elements by tag name is a much safer approach, as not all XML documents have the same structure. However, C# does appear to have a more concise implementation than Java, with methods being more compact and the overall code being 23 lines less.
4.4.2 – Using XSL for transforming documents

The W3C has provided a standard called XSL to transform some source XML into a format that is more suitable for human consumption, for example HTML. This is especially useful for RSS feeds, where XML data is extracted from an XML document using a parser, and then needs to be transformed into a browser friendly HTML form. XSLT (Extensible Style sheet Language for Transformations) provides the actual rules for transforming an XML document with the XSLT processor doing the work. [28] Java offers XSL support through the javax.xml.transform package. .NET offers XSL through the
System.Xml.Xsl namespace. [19, 20] 27

•

Example Application

An example application was developed as an addition to the previous parsing example. It takes in the parsed XML file as a large string and formats it according to the specification present in an XSLT file (Appendix C.4.4). The file is then outputted as a HTML file. Table 4 highlights the differences between the two applications at performing this task. Please refer to Appendix C.4.5 and C.4.6 for the full Java and C# code.
Java C#

The XML file to be transformed is read in using the
source class present in the javax.xml package.

The XML file is read in using the StreamReader class of the System.IO package. This is a multipurpose class, not specifically designed to read XML.

This class is specifically designed for this purpose.

Requires an additional statement in the source XML Does not require the additional statement. file where the XML version needs to be included. The class used to transform the document is named
TransformerFactory with the newTransformer method loading the source file.

An XslTranform class is used to transform the document with the Load method loading the source file. The method used to transform the document is called Transform. The
Transform

The method used to transform the document is called transform. The transform method requires two arguments, the source file and the output file.
trans.transform(xmlSource, result);

method

requires

the

two

arguments; however, additional parameters for Xpath have to be declared as null even when not used.
transform.Transform(xmlSource, null, result, null);

Total Program Line Count = 35

Total Program Line Count = 45
Table 4: XSLT comparison

The comparison shows that both applications are very similar. One of the main benefits of using XSLT is that the same style-sheet is used by both programs, with no alterations required. Differences only occur with naming principles. However, C#’s transform method is slightly more complex, as its extra variables need to be declared as null, even when not used. Another difference, not mentioned in table 4 is with regards to the XML source file. The Java file requires an additional line of code stating the document’s XML version. This is not required in C#, suggesting Java is more strict by only allowing XML documents to be transformed.

28

The lines of code are also relatively similar, with both programs being very short and concise. The Java code is however 10 lines shorter.
4.4.3 XML Library Usage Summary

The Java API and .NET FCL differ greatly for the parsing of XML. The porting of code in particular is not straightforward, as C# does not use many Java conventions. The code examples show fundamental differences in the way Java and .NET approach XML parsing. These differences could prove to be problematic, adding to the overall complexity of migration. On the contrary, use of the XSL for transforming XML documents appears very similar with only subtle differences apparent. 4.5 Scenario Three – GUI Library Usage This section compares the capabilities of Java and .NET for adding GUI (graphical user interfaces) to applications. A Java Swing GUI was developed and compared with an equivalent Windows Form based GUI.
4.5.1 Java Swing

Sun describes Swing as a GUI component kit, which simplifies and streamlines the development of windowing components. [29] Components include menus, toolbars, dialogs etc. which are commonly used in graphical based applets and applications. Before Swing, AWT (Abstract Windowing Toolkit) was used as the standard package to create GUI’s. Sun have released an article, which states “Swing Components are so much more elegant than their AWT counterparts, thus most Java developers have migrated to Swing”. [29] An important feature of Swing is its Pluggable Look and Feel (PL&F). This gives the user an option of choosing the appearance and behaviour of the components they wish to use in their programs. The GUI can be made to mimic the users’ operating system, for example, Windows, Linux or Mac.
4.5.2 .NET Windows Forms

Windows Forms is a namespace available in the .NET Framework which allows windows application developers to take advantage of the rich UI (user interface) features available on the Microsoft Windows Platform. Using the Visual Studio .NET Environment, developers can create Windows Forms based applications using any of the languages available in .NET’s Framework. The Windows Forms namespace shares the same design principles as the ASP package known as Web Forms but they differ in both classes offered and their implementations. [30]

29

4.5.3 Libraries Involved

The main packages/namespaces required for building GUI form type applications are shown in Figure 4.4.
Java API - java.swing - java.awt .NET FCL - System.Windows.Forms - System.Drawing

The javax.swing package contains the tools for developing GUI applications. Even though Swing has outdated AWT, the majority of Java GUI applications still make use of the AWT package, as this contains many layouts and other useful tools,

Figure 4.4: GUI packages

which are not present in Swing. .NET has its main GUI classes located in the System.Windows.Forms namespace and System.Drawing is used for many associated tasks such as adding colour.
4.5.4 GUI Structure

The structures of GUI based applications are similar for both approaches; however different conventions are used. This is shown by Table 5.
Part Java Swing C# Windows Forms

1

Frame: GUI elements are added to a Form: GUI elements are added to a form, which is frame, which is a type of component. It has a type of control. It has various properties to properties to control its visual appearance. control its visual appearance.

2

Components: These are added to a frame Controls: These are added to a form and are via a panel, which is a type of container. typically used to display some kind of output. Components are used to display an output Examples on the GUI. E.g. a button or text field contains a panel, which adds components to the frame.
Checkbox.

include

Button,

Textbox,

and

Container: Is a type of component and No equivalent

3

Events:

Components

have

associated Events: Similar to Swing

events. The type of event differs according to which component requires an action. Listeners: Are attached to components for Event Handler: Each event must have an handling various events. associated event handler which calls a method to handle that event.
Table 5: GUI Structures [23, 29, 30]

The main difference is that Swing makes use of a container with no equivalent in Windows Forms. This shows a main distinction in the way GUI elements are positioned on screen (more detains in 4.5.5).

30

4.5.5 VAT Calculator Application

In order to compare Swing and Windows Forms a sample application was developed in both Java and C#. The VAT calculator application works out the price of a product including VAT. Screenshots of the calculator are shown in figures 4.5 and 4.6. Please refer to Appendix C.5 for the full Java and C# code.

Figure 4.5: Java VAT Calculator • Creating GUI Elements

Figure 4.6: C# VAT Calculator

As shown in Figure 4.7, the VAT Calculator uses some basic elements that are named very similarly among the two approaches.
Java Swing JButton JTextField JLabel JMenu JMenuBar JMenuItem C# Windows Forms Button TextBox Label Menu MainMenu MenuItem Figure 4.7 – GUI Elements

The GUI elements were relatively easy to set up in both implementations with minor differences. Adding text to a button in Java is done when the button is instantiated (calculateButton = new JButton
(“Calculate”);), whereas in C#, the .Text attribute is used (calculateButton.Text = “Calculate”);). This difference is also consistent for Text fields but for the size property instead of the text

property. Such differences are minor and are easy to adjust to.
31

The calculator has a menu with two options, one file and the other edit. Adding options to the menus is achieved through a similar approach. Java adds its menu items to a JMenuBar object with C# adding its menu items to a MainMenu object. Handling events for GUI elements also appear to work differently. In Java an action listener is used to handle the event, whereas in C# an event handler is used. A difference in functionality occurs with the way the methods for performing the events are called and used. Java requires this application to use the
ActionPerformed method to produce an output for the event, whereas C# allows method names to be

customised per event (Shown bellow). This seems more convenient for the developer as there is less to learn.
E.g.: calculateButton.Click += newSystem.EventHandler(this.buttonCalculatePrice); Button click event • Organising the Layout Event Handler Customised method name

In Swing a JPanel object is used to organise the items using a layout manager. The layout manager used in this application is the GridBagLayout. There are also other layouts that could have been chosen such as
BorderLayout and CardLayout. The GridBagLayout has an associated object, which allows GUI

elements to be positioned according to x and y cell location. Windows Forms by default has a much more straightforward approach, which allows for absolute positioning according to x and y coordinates in pixels. In contrast to the Java approach, it is possible to decide exactly where on the screen you wish position your GUI elements, without the restriction of a layout manager. Even though the GridBagLayout manager was chosen, the two applications do look visually different in terms of the GUI element positioning due to Swing’s restrictive layout options. Swing’s advantage over Windows Forms is that the application is still useable when resized by the user. Reading suggests an equivalent effect can be achieved by Windows Forms using a combination of anchors and docking, however; this is not done by default. [30].
• Appearance

Unlike Swing Windows Forms by default appears as a Windows styled GUI. The setLookAndFeel method is used in Java to give the application an appearance consistent with the operating system it runs on. The Swing application looks the more appealing because the buttons and menu appear to stand out better. Although this maybe the case, Windows Forms ultimately produces the most Windows like application.
• Learning Curve – Conclusion

The learning curve aspect seems an appropriate topic to draw a conclusion for the GUI comparison. In terms of time taken to develop the GUI’s, Windows Forms (developed first) took 3 hours in comparison with Java Swing (developed second), taking 6 hours. Generally speaking, the GUI developed first would usually take
32

the longest development time but this does not seem to be the case. This could be due Java Swing having a steeper learning curve than Windows Forms. Although some aspects such as creating GUI elements are similar, choosing an appropriate layout manager proved to be the most problematic and time-consuming phase. On the other hand, third party layout managers can be downloaded for Java, which are specifically designed for form like applications, often reducing this complexity. To conclude, Java developers approaching Windows Forms should expect to produce a more Windows like application, with a smaller learning curve. A smaller learning curve was the primary mission of Windows Forms and it appears to have succeeded, consequently making GUIs simpler to develop and maintain. [30] 4.6 Further Differences Thus far, packages/namespaces that appear to map well have been investigated. There are also some less obvious mappings and some packages present in one platform’s library but lacking in the other.
• Example of less obvious mappings

In Java, the class used for threading is present in java.lang.Thread. Table 4 shows that the java.lang package maps well with .NET’s System namespace. Therefore, one would expect .NET’s threading class to be in System. Unfortunately, this is not true as .NET have chosen to add this in a separate
System.Threading namespace. •

Examples of absent packages/namespaces

Java has a package, java.beans but the concept of beans does not exist in .NET. Microsoft’s .NET has a package named System.Win32 with no equivalent found in Java. This is because unlike Java, .NET is platform specific and this namespace contains only classes that interact with the Windows platform. 4.7 Summary The Java API and .NET FCL have many packages/namespaces that map effectively. The success of the effective mappings has been investigated by comparing core library usage, xml usage and the construction of GUI applications. Findings suggest that some classes map well, with others fundamentally different in the methods required to construct applications. The use of XML parsing with the DOM parser shows that C#’s implementation is more concise but lacking Java’s flexibility. Further differences have also been highlighted for instance less obvious mappings and absent packages/namespaces.

33

CROSS PLATFORM DEVELOPMENT

5

This chapter presents means for developing Java and C# applications on a non-Windows platform. In particular the Linux platform shall be concentrated on, as Linux developers also need to be aware of the issues concerned with migrating from Java to .NET. We shall start by looking at what Sun and Microsoft have to offer Linux developers using Java and C#. The mono project shall be introduced with the porting of C# code written in Windows to Linux performed and analysed. 5.1 Vendor’s perspectives Sun and Microsoft have very different ways of describing their (respective Java and .NET) platforms. Figure 5.1 shows models of the two platforms, looking at the languages offered by supporting operating systems.

Figure 5.1: Model of Java vs. .NET [9]

Figure 5.1 shows Sun and Microsoft’s opposite views regarding cross-platform development. Java’s key attribute is its platform independence, with Sun choosing to focus their efforts on a single language running on many platforms. Microsoft has focused on many .NET languages running on a single Windows platform, including compliance with Windows enabled devices, such as PDA’s and mobile phones. [42] Existing Linux Java developers will be keen to continue programming in Linux if they decide to migrate to .NET. Sun have an implementation of their Java SDK available for Linux, which is identical to its Windows
34

equivalent so porting code from Windows to Linux and vice versa is achievable. Microsoft currently do not cater for Linux developers with most .NET applications being developed specifically for the Windows platform and Microsoft wishing to keep development within this domain. Although Microsoft does not offer a cross-platform implementation of its .NET platform, there are methods available for vendors to do so. This is because Microsoft gave its specification for the core parts of its .NET Framework, known as the Common Language Infrastructure (CLI) to the ECMA for standardisation. Subsequently, the technical details such as the .NET virtual machine, C# language and libraries are now available to the open source community. This allowed the open source Mono Project to commence (Introduced in section 2.4). [9] 5.2 Porting Windows.NET Code In order to assess the current state of Mono and how closely it has been able to implement Microsoft’s .NET FCL, lets attempt to port a range of C# code from Microsoft.NET on Windows to Mono (version 1.1.8.3) on Linux. Table 6 shows a variety of tests, which were conducted using a range of namespaces. A successful outcome is obtained when the program code compiles and runs as expected.
Namespace Test Description Outcome

- System

- String functions (concat & substring methods) - Writing to console - Use of Array class

Successful Successful Successful Successful Successful Successful Successful Successful Unsuccessful (Compiler error) Successful

- System.Collections - System.Threading - System.IO - System.Xml - System.Xml.Xsl - System.Windows. Forms - System.Drawing

- Use of the ArrayList class - Creating and running two threads - Reading and writing to file using StreamReader and
StreamWriter

- Parsing an XML document using DOM - Using XSLT to create a formatted HTML file from an XML document - The VAT Calculator GUI used earlier. Contains buttons, textboxes, labels, menus… - Used in VAT Calculator code, particularly for colour selection

Table 6: Porting C# code from Windows to Linux

Namespaces that port effectively: From the tested namespaces, 6/7 (85%) were ported from Windows.NET to Mono on Linux without any compilation errors. Research suggests these namespaces are architecturally

35

sound among others such as System.Data, System.Text and System.Web, which have been fully implemented by the Mono team. [9] Namespaces that do not port effectively: System.Windows.Forms was the only unsuccessful namespace tested. As already discussed in section 4.5 Windows Forms are used for creating Windows-like GUI’s. Currently the Mono team is working on implementing System.Windows.Forms. Some other namespaces, which do not port include
System.ComponentModel, System.EnterpriseServices

and

Microsoft.Win32. These namespaces all contain classes and methods which are unique to the Windows

platform. 5.3 Legalities over Microsoft .NET Implementation There are many legal issues surrounding the key elements of the .NET platform. Earlier it was mentioned that Microsoft standardised core parts of its .NET framework. Accompanying this standardisation was a patent from Microsoft, restricting the open source community from implementing some of .NET’s key elements. These elements include ASP.NET, ADO.NET and Windows Forms subsets, which are particularly convenient for people requiring compatibility with the Windows platform. Therefore, this is clearly a problematic area for Mono developers because as noted earlier, porting Windows applications can be troublesome. Mono is determined to implement an equivalent of these elements mentioned to allow this interoperability with Windows. [31] 5.4 Future Developments The three main incomplete elements, ASP.NET, ADO.NET and Windows Forms are currently undergoing intense development and are expected to be fully completed and available in Mono 2.0 in 2006. [32] One of the main developer tools, which is undergoing heavy development is an IDE to rival Microsoft’s Visual Studio .NET, which is called MonoDevelop. It aims to have class management, built-in help, code completion, project support, and an integrated debugger. [33] 5.5 Summary It is clear that Mono is one solution for cross-platform C# development and may be particularly attractive for Java Linux developers who are wishing to develop C# applications without switching operating system. However, there are some obstacles, particularly concerning the porting of Windows C# code due to various legalities and current state of development. Tests show that it is best to avoid Windows specific namespaces at present, as they are largely incomplete (particularly System.Windows.Forms). However, the majority of C# code tested (85%) ports from Windows.NET to Mono successfully..
36

BENCHMARKING
6.1 Purpose

6

The purpose of benchmarking is to create and execute a number of tests, usually involving a time value, to prove a concept. This chapter presents various experiments conducted to compare the efficiency of the Java language versus the C# language. As discussed previously, each platform has an underlying virtual machine used to run the bytecode. These experiments require discussion regarding the efficiency of the JVM (Java Virtual Machine – running Java applications) and the CLR (Common Language Runtime – running .NET applications). Benchmarks shall be performed on both Windows XP and Linux. 6.2 The Approach To obtain reliable results, independent testing was carried out. Tests were carried out on a single number reader program, which demonstrates some commonly performed programming tasks (Program code found in Appendix C.6).These can be somewhat demanding on the virtual machines. To produce a large number file, a random number generator program was executed, allowing the number of random numbers to be specified (Program code found in Appendix C.6.1). Three main functions of the program are: 1. Reading in values from a file (I/O) – Integer values are read in from a text file and added to an array. The text file is created using a random number generator. 2. Sorting numbers in an array – Integral functions sort the values in the array from smallest to largest. 3. Printing out to terminal – Integral functions are used to print the sorted array of numbers to the display. These were investigated in order to demonstrate where the differences lie in terms execution time (seconds).

6.3 Benchmarking Code To measure the efficiency of the program, benchmarking code was applied. Special code is placed around the code being benchmarked (timed). This is shown for each language in Figure 6.1.

37

Java double time; long start = System.currentTimeMillis();

C# const double TICK_LENGTH = 1.0e-7; double time; long start = DateTime.Now.Ticks;

**BENCHMARKED CODE GOES HERE**

** BENCHMARKED CODE GOES HERE**
long finish = DateTime.Now.Ticks; time = (finish-start)*TICK_LENGTH; Console.Out.WriteLine(time); Figure 6.1: Benchmarking Code

long finish = System.currentTimeMillis(); System.out.println(time = 0.001*(finish – start));

Procedures were implemented to ensure fair and reliable results. The same computer was used throughout. This was a relatively new specification PC – Pentium 4 3.0GHz, 512 MB RAM, 1MB Cache. All background programs were closed in the operating system, as well as ensuring that a command terminal was used to run the programs for both Java and C#. 6.4 Windows XP Operating System Benchmarks
6.4.1 Complete Program

Initially, the complete code (containing the three functions mentioned earlier) was benchmarked for both Java and C#. A whole range of inputs were benchmarked, ranging from handling 100 integers through to 5 million. Graph 1 shows the complete program’s execution time for both Java and C#. N.B. Lines 100 and 1000
are disclosed from the graph as differences between the languages are insignificant.

5000000

Number of Integers

C#
1000000

Java

500000

100000

0

50

100

150

200

250

300

350

Time (seconds)

Graph 1: Windows Overall Program Execution Time 38

From analysing the graph, execution times for both Java and C# appear consistently similar across a range of inputs. However, when analysed closely the results show that for 5 million integers, C# required approximately 1.3 seconds longer than Java. This is a very slight difference therefore each of the three functions stated in Section 6.2 were analysed to give an idea of which function is more efficient.
6.4.2 Reading in Integers from File

Graph 2 shows the execution time for reading in the numbers from the text file. Java is using the
FileReader class whereas C# is using the StreamReader class to read in from the file. These classes are

part of the I/O libraries and are shown in more detail in Section 4.3.2.

50000000

Number of Integers

20000000

C# Java

10000000

1000000

0

5

10

15

20

25

Times (Seconds)

Graph 2: Reading in Code

The graph above shows that Java requires more time than C# across the range of inputs measured. A reason why Java appears slower compared to C# could be due to Java requiring an additional buffered reader to read in the integers.
6.4.3 Sorting Numbers in an Array

Graph 3 shows the execution time for the “sort” functions of the respective programs. The function in Java is called through the declaration Arrays.sort() with C# Array.Sort(). A wide range of inputs have been chosen for this benchmark (1 million to 20 million), as it shows the differences between Java and C# more clearly.
39

20000000

Number of Integers

15000000

C# Java

10000000

1000000

0

1

2

3

4

5

6

7

8

9

Time (Seconds)

Graph 3: Sorting the Array

Throughout the range of inputs, it appears C# requires more time (approximately twice as long) than Java for sorting the array of numbers. This suggests that Java’s implementation of sort appears more efficient than the equivalent C# implementation. The possible reason for this is given in Section 6.4.6.
6.4.4 Printing out to Terminal

Graph 4 shows the execution time for printing to terminal functions. Java uses System.out.println() and C# uses Console.WriteLine().

5000000

Number of Integers

1000000

C# Java

500000

100000

0

50

100

150

200

250

300

350

Time (seconds)

Graph 4: Printing to Terminal 40

The results illustrated in the graph noticeably show that the execution times for Java and C# are equally efficient throughout the range of inputs tested. Benchmarks also show that printing to terminal is responsible for consuming the greatest proportion of the overall execution time. For example 5 millions integers require 305 seconds to print to terminal, with the overall time requiring 308 seconds. That makes 99% of the complete program’s execution time being taken up by the System.out.println() function.
6.4.5 Windows Benchmark Conclusion

For the sorting numbers program running on the Windows XP Operating System, performance depends on what classes/methods are being used within your program. Some classes/methods are more efficient than others. For example: • • • • Overall Java and C# are equally efficient (graph 1). C#’s StreamReader is more efficient than Java’s FileReader (graph 2). Java’s sort() is more efficient than C#’s Sort()(graph 3). Java and C#’s methods for printing to terminal are equally efficient (graph 4).

To summarise, for the programs benchmarked on Windows, there is no clear advantage of using Java over C# or vice versa in terms of gaining an overall performance advantage.
6.4.6 Reasons for Differences

Benchmark testing is not sufficient to identify the particular reasons for the differences in performance. Possible theories for these variations could be: 1) Implementations of underlying library functions. As previously discussed, Java inherits its functionality from the Java API and C# through the .NET FCL. Unfortunately these details are hidden from developers and it cannot be said for certain if this is the cause of efficiency differences. The layer of native code generated by a particular method may be thicker than another, taking longer for the operating system to execute that code. [42] 2) Implementation of the underlying virtual machine, on which the compiled code runs. In Chapter 1 the JVM and CLR were introduced as Java and .NET’s virtual machines, executing compiled code. The difference in the performance of executing the compiled code by these programs could be due to the variation in efficiency of the virtual machines.

41

Microsoft argue in the article “Technical overview of the common language runtime” [34] that their CLR is more powerful than the JVM in terms of multilanguage support. This may be true as Java focused very much on using a single language, cross platform. In contrast Microsoft aimed to use multiple languages running on a single platform. In my opinion the JVM could have some potential benefits in terms of efficiency, as there is a need to concentrate on a single language. Article “JVM versus CLR: A Comparative Study” [35] demonstrates that there is little performance difference between the JVM and CLR. Furthermore, it shows similar performance between the JIT (just in time) compilers used by both Java and C#. Article [35] supports my findings of the two languages having equal performance on the Windows platform. Presumably the differences are due implementations of the underlying library functions as research has shown that the virtual machines have similar performance. 6.5 Linux Operating System Benchmarks Linux was used to conduct further benchmarks to see if cross-platform porting caused any differences in efficiency. Java Sun’s Linux version was used to compile and run the Java code and conversely C# using open source Mono. For this cross-platform investigation the overall execution times of the number reader program were analysed. Graph 5 shows the execution time for the complete program, again for a range of input sizes ranging from 1 to 5 million integers.

5000000

Number of Lines

C#
1000000

Java

500000

100000

0

20

40

60

80

100

120

140

160

180

200

Time (seconds)

Graph 5: Linux Overall Program Execution Time 42

It appears as though C# is significantly slower than Java, roughly twice as slow. As speculated with Windows, this could be down to the implementation of the methods or the underlying virtual machines. It would be of particular interest to compare the efficiency of the programs running on the Windows XP operating system with those on Linux. Graph 6 shows the complete program execution times for Java and C# running on both Windows and Linux.

5000000

Number of Lines

C# (L) C# (W)
1000000

Java (L) Java (W)

500000

0

50

100

150

200

250

300

350

Time (Seconds)

Graph 6: Windows Vs Linux Overall Program Execution Time

From observing the results a distinct trend is apparent. Java and C# programs running on Linux are significantly more efficient than their Windows equivalents across the range of inputs. The question is if this due to the virtual machines on Linux being more efficient than their Windows counterparts, or the operating system is more efficient than Windows? This is not useful information for migrating developers. What is important is that Linux developers would clearly expect a performance advantage by using Linux over Windows. Furthermore, Java Linux developers appear to have a clear advantage of using Java on Linux over C# for this sort of program. 6.6 Summary On Windows, there is no clear performance advantage of using Java over C# or vice versa. Performance is dependent on both the classes/methods being used in a given program and the operating system platform on which the code runs. On Linux, Java developers appear to have a considerable performance advantage over C# developers. Linux developers, regardless of the language being used, appear to have a clear advantage over Windows developers for this particular application.
43

TOOLS

7

This section presents tools available in both Java and .NET to aid developers when creating applications. Command line tools shall be briefly explored before looking at the two major integrated development environments (IDEs) available for each platform. The Microsoft Java Language Conversion Assistant tool shall also be introduced and evaluated. 7.1 Command Line tools There are a range of command line tools which come as standard with software development kits by Java, Microsoft.NET 1.1 and Mono platforms. Java 5.0 JDK comes with the same tools on either Windows or Linux versions; therefore the Linux version does not need further investigation. As Mono for Linux is open source, its tools for C# development shall be briefly looked at in comparison to Microsoft.NET.
7.1.1 Java Versus Microsoft.NET Tools

• •

Both platforms have compiler tools, which are most essential. Java has javac, with .NET having csc for compiling C# applications. Usually, the Java launcher is needed to run Java applications. .NET on the other hand solely requires the file name, as it compiles to an executable (.exe) and does not require the user to run a launcher. This is because by default .NET runs the CLR automatically. The same effect can be achieved in Java, but requires changes in the settings.

• • • •

Java can be set up to do this, but it is not done by default. Both platforms offer common programming tools like interpreters, debuggers, file signers and disassemblers. The .NET framework offers some tools that are not present in Java 5.0, including an assembler, XML generator and Wsdl tool. Java also has some tools that are not present in .NET such as a document generator, Jar Tools and an applet viewer. In terms of quantity Java 5.0 comes with 29 tools and .NET 1.1 more than 40. Some of these tools are related to other .NET languages therefore are not required for C# development.

•

It appears as though tools are heavily dependent on the development platform. Java does not require many tools that are related to Microsoft assemblies and a variety of programming languages. Likewise .NET does not require Jar tools, as files compile to executables.

•

Additional tools are available for both platforms, which can be downloaded, often free of charge. [36, 37, 19, 20]
44

7.1.2 Microsoft.NET Versus Mono Tools

• • •

Both platforms have compiler tools for C#. Microsoft.NET has csc and Mono has mcs. As previously mentioned, Microsoft.NET does not need a launcher. However Mono uses a mono launcher, for example running a Mono C# file: mono filename.exe. Mono has implementations of the majority of C# tools available on Microsoft.NET. These include a debugger, interpreter, assembler, file signer, disassembler, security tools and XML tools. Some tools are named similarly between the two platforms, for example gacutil, ilasm, sn, soapsuds, Wsdl. Different naming conventions have also been used, for example ildasm, the MSIL disassembler in Microsoft.NET is named monodis in Mono.

[20, 37, 38] 7.2 Integrated Development Environments A basic text editor such as notepad can be used to write and edit programming code, nevertheless an IDE tool offers a more supportive and productive environment. Not only can an IDE be used to write and edit programs, the code can be both compiled and executed amongst providing other tools aiding development. The two IDEs that shall be compared are Eclipse for the Java platform and Visual Studio .NET for the .NET platform. [24]
7.2.1 Eclipse Platform 3.1.0

Eclipse is an IDE that can be used to create a variety of applications, primarily Java applications but also websites and C++ applications. Eclipse is an open source application and one of its appealing attributes is its support for an unrestricted set of tool providers including independent software vendors. [39]
7.2.2 Visual Studio .NET 2003 (VS.NET)

VS.NET is Microsoft’s RAD tool and is not open source. The IDE allows you to create many types of application supporting all .NET languages. Such applications include Windows, ASP.NET web applications and ASP.NET web services. [24]

45

7.2.3 IDE Comparison

Table 7 illustrates the variety of features offered by Eclipse in comparison to Visual Studio .NET 2003.
Feature Eclipse VS.NET

General Features - Integrated Compiler and Runtime - Debugger - Plug-ins available - Use of colours to show keywords, variables, comments - Tabbed viewing - Dockable controls - Built in task list - Customization capability – set user preferences for IDE appearance and behaviour - Program in multiple languages - Refactoring support - Built in WYSIWUG tool for GUI applications - Built in support for writing both Java and C# code - Open Source Built in Intelligence Features - Automatic code completion - Automatic syntax checking as typing (before compilation) - Automatic variable/method checking (before compilation) - Obsolete function/import warnings - Help on how to use a method/function as you type - Suggest Library Imports - Show local variables and methods in code completion

Table 7: IDE Features Comparison

In relation to general features, the table shows that both IDEs have an integrated compiler. However, VS.NET will only allow the project to compile using one main method. Eclipse allows you to specify which class you wish to compile. Other features appear very similar apart from support for developing GUI’s using a drag and drop interface. Visual Studio .NET has a built in tool for developing GUI’s and Eclipse does not. Eclipse does on the other hand have a plug-in tool, SWT, which is available for a fee and offers a similar solution. The shipped version of Eclipse does not allow support for writing C# applications. Visual Studio .NET allows Java applications to be written by default. Obviously integrated compiler support is not
46

available for Java within VS.NET. A free plug-in can however be downloaded for Eclipse that allows C# applications to be written. The other major contrast is that Eclipse is open source meaning that it is free to download. Visual Studio .NET is not open source although can be bought. [39, 40] Regarding intelligence features both Eclipse and VS.NET offer them, allowing programmers to code in a faster and more error-free manner. From the table it appears that Eclipse offers superior support to programmers. The intelligence feature in VS.NET has been branded by Microsoft as IntelliSense. IntelliSense lacks key features, which Eclipse developers may be accustomed to. Incorrect method/variable references only produce errors after compilation in VS.NET. Moreover, missing library imports are not suggested and added automatically as in Eclipse. [40] 7.3 Microsoft Java Language Conversion Assistant 2.0 This tool is available as a free plug-in for the Visual Studio .NET IDE and allows existing Java language code to be converted into the C# equivalent. Once converted, the applications can be extended to utilise .NET features including XML web services and ASP.NET. [41] In order to evaluate the effectiveness of the tool, some tests shown in Figure 7.1 were performed. Different Java programs developed during this framework were converted into C#. The test is considered successful if the program compiles once it has been converted. All basic programs passed the test, whereas programs which used advanced features did not port well. In my opinion, the conversion assistant is a useful tool for porting Java applications although not offering the complete solution it appears to promise.
Figure 7.1: Conversion Tool Tests
Program Passed

Basic - Hello World - String Concatenation - Thread - Array List Advanced - XML Parsing - Swing Application

7.4 Summary Java and .NET come with many equivalent command line tools but different naming conventions exist for using such tools. For example .NET’s command for compiling is csc unlike Java’s javac. The two main IDE’s, Eclipse and Visual Studio .NET have many equivalent features such as integrated compilers and debuggers. Eclipse developers may however notice that VS.NET is lacking built-in intelligence features. The next release of VS.NET is set to improve on this. The Microsoft Conversion Assistant Tool used for converting Java programming code to a C# should be used with caution, as it does not live up to its promise.

47

RECOMMENDATION GUIDEDLINES

8

The purpose of this document is to serve as a series of guidelines for Java developers wishing to move to .NET development using the C# language. It aims to help make the overall transition from Java to .NET as straightforward as possible. The document caters for both Windows and Linux developers and should be read prior to the Technical Framework. It is assumed that the latest releases of Java and .NET are used. Document Structure Key obstacles that you may be likely to face during migration are outlined along with suggestions on how these may be overcome. For further details on any of the issues raised in this document, please refer to the Technical Framework. The document is split up into three main sections: 1) General Development a. The Java and C# languages b. Using the Built in Libraries c. IDE Tools 2) Windows Specific Development a. Performance of Java Versus C# b. .NET Command Line Tools 3) Linux Specific Development a. Mono b. Performance of Java Versus C# Each subsection mentioned above is accompanied by some direct advice. An overall summary is present at the end of this document. How to use the document • • Windows Developers: Linux Developers & Multi platform developers: Read section 1 and 2, plus summary. Read all sections.

N.B Multiplatform Developers are assumed to develop applications using both Windows and Linux. 48

Section 1: General Development
a) The Java and C# languages: By and large, the languages are very similar; however do watch out for

the following differences.
•

Capitalisation differences throughout. Referring to a method in C# is done using a capitalised name, unlike Java which is conventionally lowercase. For example sort() and Sort(). There are 28 more keywords in C# but the majority (75%) are also found in Java. Key differences in parameter passing and exception handling. Both languages allow parameter passing by value. However, C# additionally allows you to pass by reference, which is particularly good if you wish to implement swap methods. With regards to exception handling, C# appears to be less strict as some methods do not require you to throw exceptions by default.

• •

•

C# has a foreach statement, allowing you to loop through each element in a collection without the need for a counter initialisation. Java has recently introduced an equivalent called an “enhanced for loop” in version 5.0.

•

C# has features that are not in Java such as properties, delegates, structs and operator overloading. Read the Technical Report to find out how these work. Properties are particularly useful as an alternative for the current Java get and set conventions.

•

Java has a stricter approach than that of C# for handling exceptions. The absence of the throws declaration in C# means that the programmer is not forced to choose between catching exceptions or declaring that those exceptions are thrown by the methods.

•

Java 5.0 has features that are not in the current release of C# such as static imports and generics.

Advice: Learning the C# language is quite straightforward providing you’re aware of the language differences from the start. When comparing language features, it should be made sure that the latest releases are always compared. Java 5.0 has introduced key features, which were previously lacking. .NET Version 2.0 is due to be released soon and does contain generics, a feature that is currently not present. Watch out for these features along with future releases of Java.
b) Using the Built in Libraries: Each platform offers the facility for calling pre-written code. Java uses the

Java API, with C# using the .NET Framework Class Library (FCL).
•

Java has its common classes grouped together in packages, whereas .NET calls these namespaces. They are essentially the same thing. A noticeable difference is that the string object in Java is referred to as String (uppercase ‘S’). In C# it is referred to as string (lowercase ‘s’) or String (uppercase ‘s’).

•

49

•

You will notice that many Java packages have an equivalent .NET namespace. For example
java.lang contains many of the same group of classes present in the System namespace. You may

also notice other examples, including input/output and XML.
•

Watch out for differences in .NET’s String class. Although it is named the same as Java’s String class and contains many of the same method names, some of the methods work differently. Examples include String concatenation, substring and finding a character at a specified location.

•

When parsing XML using .NET’s DOM parser, you will notice the code is more concise that Java’s implementation. Extracting elements from the XML document is done by knowing the document structure instead of tag name, which can cause problems if the XML document’s structure is unknown.

•

.NET’s Windows Forms namespace contains methods for building GUI applications. In comparison to Java Swing it appears much simpler to use, as there is no need for a layout manager. GUI elements are positioned according to x and y pixels on screen. You will notice that Windows Forms GUI’s do not resize well by default. Additional docking and anchoring are required for this effect.

•

Look out for less obvious mappings. For example .NET has a separate threading namespace,
System.Threading. In Java threading is a class present in java.lang.thread.

•

Look out for absent packages/namespaces. Java has a package, java.beans; however the concept of beans does not exist in .NET. .NET has a package named System.Win32 with no equivalent found in Java.

Advice: To overcome some of the difficulties mentioned, make sure that you refer to the latest API/FCL documentation at all times. Even though some classes and methods are named the same, they work differently, which could change the outcome of your program if not anticipated beforehand.
c) IDE Tools: Eclipse developers should expect to use Visual Studio .NET 2003 (VS.NET) for writing C#

applications. Most features found in Eclipse are present in VS.NET but watch out for the following:
•

VS.NET is not open source and is available for a fee. If you cannot afford the IDE, one named Sharp Develop is available free of charge, offering many of the equivalent features. VS.NET has a built in tool for developing GUI’s using a drag and drop interface. A similar tool is available as a plug-in for Eclipse at a cost. You may notice that VS.NET is lacking some built-in intelligence features that you are accustomed to in Eclipse. Incorrect method/variable references only produce errors after compilation in VS.NET. Missing library imports are not suggested and added automatically as in Eclipse.

•

•

Advice: Watch out for the differences mentioned, but bare in mind the new release of VS.NET, 2005, will be available soon. This is due to contain improved intelligence features that are currently lacking.

50

Section 2: Windows Specific Development
a) Performance of Java Versus C#: Benchmark testing using an intensive number reader program was

conducted on Windows XP. Some noticeable differences were observed.
• •

For the program tested, there is no clear performance advantage of using Java over C# or vice versa. Performance depends on what methods are being used within your program. Some classes/methods are more efficient than others. For example: o o o C#’s StreamReader is more efficient than Java’s FileReader. Java’s sort() is more efficient than C#’s Sort(). Java and C#’s methods for printing to terminal are equally efficient.

Advice: Given a Java and C# program, it cannot be said for certain which is most efficient, as this is dependant on classes/methods used. Therefore, do not base any general judgement on Java having a performance advantage over C# or vice versa.

b) .NET Command Line Tools: Both platforms offer common programming tools like interpreters,

debuggers, file signers and disassemblers.
• • •

Watch out for some .NET specific tools including an assembler, XML generator and Wsdl tool. .NET does not require many Java tools such as Jar Tools and an applet viewer. Not all .NET tools are specific to C# development so will not be useful. Additional tools are available for both platforms, which can be downloaded, often free of charge.

•

Advice: Watch out for differences in naming principles. .NET’s command for compiling is csc unlike Java’s
javac. Always check the documentation that comes with .NET Framework 1.1 prior to using any tools.

Section 3: Linux Specific Development
a) Mono: Linux developers who wish to program in C# should use the Mono platform, which offers many

equivalent features found in Microsoft .NET’s Framework. Migrating from Java to Mono is straightforward but there are some things to look out for migrating from Windows.NET to Mono.
•

The majority of program code tested (85%) ported from Windows.NET to Mono without any problems. In the current release of Mono (Version 1.1.8.3) applications using the System.Windows.Forms package do not compile.

51

•

Mono has implemented many of Microsoft .NET’s command line tools. However, be sure to watch out for naming differences between the tools. For example, ildasm, the MSIL Disassembler in Microsoft.NET is named monodis in Mono

Advice: Tests show that it is best to avoid Windows specific namespaces at present, as they are largely incomplete (particularly System.Windows.Forms). Continue checking the Mono-Project website for details on when these packages are due to be completed and keep downloading the latest Mono releases.
b) Performance of Java Versus C#: If not read already, please read section 2a) before proceeding. The

same program in Section 2a) was used for Linux benchmarking. Sun’s Java implementation was benchmarked against Mono’s .NET based implementation. • • It appears that for the program tested, there is a clear performance advantage of using Java over C# on Linux. The Java program was roughly twice as fast as its C# equivalent. There is a clear performance advantage in using both Java and C# on Linux over Windows.

Advice: Although not tested on Linux, the choice of classes/methods within a program could also influence its overall efficiency. If performance is of great importance, it is recommend Linux be used over Windows, as there is a noticeable advantage.

Summary As you shall now be aware, moving from Java to .NET using the C# languages is not straightforward due to differences in the languages, library usage and tools offered. There are many obstacles along the way. However, now that you are aware of some of these obstacles in advance, the migration path should be easier. Please bare in mind that only a small proportion of the .NET platform has been compared with Java. For more details, the Technical Framework along with documentation that comes with the respective development kits should be consulted. Watch out for the new releases of Java and .NET Framework 2.0, which shall include new features that should also be studied prior to migration.

52

EVALUATION

9

In the evaluation process, a series of criteria and sub-criteria have been devised to determine the success of this project. The first task is to evaluate the outcome against the original objectives and minimum requirements, which were specified prior to starting full time work on the project. Secondly, the process of constructing the Technical Framework shall be evaluated, looking at reliability and thoroughness of research in particular. Finally, the deliverables themselves are evaluated. 9.1 Original Objectives and Minimum Requirements Each of the objectives stated at the beginning of this project shall be discussed in turn, stating whether they were met successfully or not. • Objective 1: Produce a Technical Framework comparing the essential features of Java and .NET platforms for application development. Successful The Technical Framework forms the majority of the written material within this project. Following the literature review chapter, essential features of Java and .NET platforms were identified and compared throughout. These features included the Java and C# languages, library usage and tools. • Objective 2: Implement test programs in both Java and .NET languages aiding the comparison. Successful Throughout the Technical Framework, test programs written in Java and C# were used to aid the comparison. Small pieces of code are included where necessary in the Technical Framework, with full program code available by referring to Appendix C. Some of the applications developed included an XML parser, XSL transformer and GUI applications. • Objective 3: Produce a document, which contains obstacles for migrating developers to look out for. Successful This document was produced after the construction of the Technical Framework and is shown in Chapter 8.

53

Obstacles were identified throughout the Technical Framework. However, the Recommendation Guidelines act as a concise overview, allowing migrating developers to become aware of the key obstacles in a much shorter period of time. The effectiveness of this document is evaluated in Section 9.3.2. Further Enhancements: • Objective 4: Include an investigation into the Mono platform and discuss obstacles that Linux developers may be likely to face during migration. Successful A chapter was produced comparing Sun and Microsoft’s views regarding cross-platform development. The Mono project was introduced and tests were performed, which highlighted problems relating to the porting of Windows .NET code to Mono, particularly concerning Windows specific namespaces. • Objective 5: A discussion of how Java and .NET technologies approach web service implementation. Unsuccessful This further enhancement was not met due to other areas of the project taking precedence. In particular, an additional objective was introduced midway through the project. This was to compare the performance of the Java and C# languages through benchmarking, which took longer than expected. Nevertheless, sacrificing objective 5 proved to be worthwhile, as both useful and interesting conclusions were obtained providing migrating developers with beneficial advice. 9.2 Evaluation of the Process
9.2.1 Reliability of Resources

During the project a variety of research resources have been consulted (please refer to References). Reliable resources are likely to produce more reliable conclusions, on which helpful advice can be based. As shown below, a combination of textbooks, research papers and web resources were used throughout.
Resource Quantity

Textbooks Research Papers Websites

16 5 18
54

Figure 9.1: Resources used

Generally, textbooks and research papers are considered as being reliable resources and web sources usually considered as being less trustworthy. Figure 9.1 shows textbooks and web resources were most commonly used in this project. The websites referred to during this project are considered reliable, as they are all published by credible vendors, such as Microsoft, Sun and Novell. Information about products, especially ones directly from vendors, were often spoken about from a marketing perspective. Hence, it was important to make sure only useful facts were extracted, without placing too much trust in the capabilities of certain products. An example of this is Microsoft’s Java Conversion Assistant. Microsoft claims the assistant can convert existing Java code to a C# equivalent but do not state to what extent. Testing shows the tool to be ineffective in the porting of certain applications, obviously not revealed by Microsoft. Due to the credibility of resources and measures taken to ensure reliable information was extracted, this criterion has been met successfully.
9.2.2 Thoroughness of Research

This criterion raises the question: “Were the right areas chosen for the Technical Framework and was the research conducted thoroughly enough?” The Technical Framework comprises of various topics. Comparing Java and C# languages seemed like an appropriate starting point, as programming languages form the basis of all software applications. Secondly library usage was compared. During this chapter, the detail with which certain areas could be investigated was restricted. For example, in the core library comparison, solely the String and I/O classes could be studied. Even though it would have been ideal to investigate more classes, a selective approach had to be adopted, mainly due to the page restriction placed upon this report. Supposing more classes were examined, the detail level of other sections would have been compromised, producing less useful advice for migrating developers. Researching the Mono Project proved to be largely problematic, due to the limited amount of information available and changeable state in Mono’s development. For the most up-to-date information, the official Mono website was consulted throughout. Although this was predominantly useful, finding details on the workings of Mono tools were not explained in detail. This restricted the level of the detail with which Mono tools could be compared with .NET tools.

55

Further topics in the Technical Framework included Benchmarking and Cross-Platform Development, as they are also regarded as being imperative for migrating developers to consider. Generally, the areas chosen were very broad and fundamental to developers migrating from Java to .NET. Issues such as security, web development and networking were not included as part of the Framework, as they seemed more specialised and not primary topics that migrating developers would be likely to consider. Due to the range of areas covered by the Technical Framework and their overall relevance to the aim of the project, this criterion has been achieved successfully. 9.3 Evaluation of the Product The original deliverables for this project were: 1) Technical Framework which forms the bulk of the report. 2) Test Programs that are present in the Framework and Appendix. 3) Recommendation Guidelines which cater for both Windows and Linux developers. The following criteria look at evaluating these deliverables.
9.3.1 Confidence in Test Programs/Experiments

Test Programs/Experiments of a high standard are more likely to construct a reliable discussion in the Technical Framework. Moreover, a thorough discussion is the basis for accurate conclusions on which sound advice can be drawn. Test programs have been implemented and compared during various chapters of the Technical Framework. It was of prime importance that like-for-like programs be produced in Java and C# languages, resulting in a fair and accurate comparison. For example, during the I/O library comparison, the use of a FileReader class in Java prompted the need to implement an equivalent StreamReader class in C#. Experiments were carried out in the Benchmarking and Cross-Platform Development Chapters. The Benchmarking Section states several conclusions comparing the performance of the Java and C# programming languages. Confidence in these conclusions is reflected by the reliability of experiments. Again, it was made sure that like-for-like functionality was tested, along with using controlled test conditions (more details in Section 6.3). Unfortunately, it cannot be said for sure that benchmarks conclusions are completely reliable, as some are always out to prove otherwise and often bring up factors which were not anticipated. The conclusions may vary for more specialised tasks, for example the performance of arithmetic operations or parsing XML.
56

Even though it cannot be said whether the benchmarking experiments are 100% reliable, measures were taken to make sure those tests were conducted fairly and accurately. Therefore, this criterion is judged to have been met successfully.
9.3.2 Effectiveness of Recommendation Guidelines

The use questionnaires seemed an appropriate method for capturing feedback on whether the Recommendation Guidelines (produced in Chapter 8) were effective or not. Six potential migrating developers were asked to read the Recommendation Guidelines and then fill in a questionnaire querying the effectiveness of the document. Samples questionnaires can be found in Appendix D. The following charts represent views of the participants and correspond to the some of the questions asked.

View of of Migration View Migration
17%

Straightforward Problematic Straightforward
Problematic No View No View

Figure 9.2 represents views of participants on how easy it is to migrate from Java to .NET development prior to reading the Recommendation Guidelines. As shown, the majority of people asked thought that migration was straightforward,

17%
View Changed?

with the remaining participants believing it was either problematic or had no view. A follow-up question was then asked to those who thought migration was straightforward to see if their view had changed since reading the documents.

66%

Yes No

Figure 9.2: Respondents views on migration

Out of the four participants that thought migration was straightforward, every one had changed their views to problematic since reading the document. This shows that the document was effective in making the target audience aware of the issues developers are likely to face prior to migration from Java to .NET.
Preconceived Performance
17% 17%

Java Faster C# Faster No View

Figure 9.3 represents views on Java versus C# performance ahead of reading the guidelines. The majority of people asked believed that C# had a performance advantage, with one respondent arguing Java had a performance advantage. Again, a follow-up question was asked. This was aimed at developers who had preconceived views on performance, to see if their views had changed since reading the document. Out of the five people with preconceived views on performance, four of changed since reading the Recommendation 57

View Changed?

66%

Yes No

Figure 9.3: Respondents views on performance

those questioned had changed their minds since reading the document. The document informs developers that it cannot be said with certainty which language out-performs the other, as performance varies according to the classes and methods used within a given program. Therefore, analysing these results and reading the feedback indicates that the Recommendation Guidelines were effective. Towards the end of the questionnaire, two direct questions were asked to the respondents. The first of which was asking if the document effectively informs developers of the likely obstacles (Figure 9.4). The second question explored whether the advice given within the document was useful or not (Figure 9.5).

Document Effectiveness
17% 17%

Document Usefulness
17%

Very Effective Effective Average
50% 33% 66%

Very Useful Useful Average

Figure 9.4: Respondents views on performance

Figure 9.5: Respondents views on performance

Analysis shows that the majority of people questioned thought that all together the information was very effective and the advice useful. Reading the comments suggests that some people cannot fairly judge how useful the advice was, until they experiment with the .NET technologies. If time permitted, developers could be further questioned following migration from Java to .NET development, to explore if the main issues were addressed. A limitation of such a document is that it has a limited shelf life, which constrains its usefulness. To overcome this, the work must be continually updated (see Section 10.2). Overall analysis of the survey shows that the Recommendation Guidelines are effective and serve their purpose as a brief overview of the likely obstacles one is expected to face during migration from Java to .NET. For that reason, this criterion is judged to have been met successfully. 9.4 Summary On the whole, the project is regarded as being a success, as the majority of the evaluation criteria have been achieved. There is however room for extending the project. This is discussed in Chapter 10.

58

CONCLUSION AND FUTURE WORK
10.1 Conclusion To conclude, let us re-introduce the original project aim:

10

“To produce a Technical Framework comparing the Java and .NET platforms, allowing programmers to be aware of the obstacles for migration from one platform to the other. In particular Java developers migrating to .NET development using the C# language.” This aim has been achieved as the associated objectives have been met successfully and to some extent exceeded. It can be said with authority that migrating from Java to .NET development using the C# language is not straightforward due to number of obstacles which have revealed throughout the project. Such obstacles largely occurred due to differences in the languages, built-in library usage, cross-platform development and tools. These add to the overall complexity of migration. The project has been well managed (please refer to Section 1.4). Time restrictions were considered and accordingly alterations were made concerning project milestones and performing a number of tasks concurrently. The Technical Framework met expected standards, as it was based on data from reliable resources. It also covers a range of areas that are relevant to the aim. The test programs/experiments used to support the Technical Framework were implemented as fairly and as accurately as possible, comparing like-for-like features. The Recommendation Guidelines also proved to be effective, as revealed by the evaluation. 10.2 Future Work This project can be extended and has room for further work. Whether the work is done by myself or another, various directions can be pursued. For example: Update Work: For the Technical Framework to remain useful, it must be continually updated. With the immanent new release of .NET, various issues are raised with regards to the accuracy of the Technical Framework in its current state. For example, the C# language is due to include the generics feature, one which is currently not available in .NET Version 1.1. Mustang, the code name for the new Java platform expected in 2006 is to include more core language features. Therefore, new language features of C# need to be compared and contrasted with future releases of Java. Furthermore, the soon to be released Visual Studio

59

.NET 2005 IDE, should be compared with Eclipse. It would useful to see if Microsoft has improved their built-in intelligence features, which were previously lacking. The latest developments with the Mono Project should be looked out for, particularly the Windows specific namespaces. It would be interesting to see if the Mono can achieve an equivalent implementation to that of .NET and allow Windows based applications to port successfully. One of the examples of such an application is that requiring the use of the System.Windows.Forms namespace. Ensuring that the Technical Framework is up-to-date, allows migrating developers to be continually aware of the latest obstacles they may be likely to face during the changeover from Java to .NET. Additional Benchmarking: Further experimentation could be conducted to compare the performance of Mono on Windows with Mono on Linux. This will determine whether the performance differences are caused by the underling operating system or not, allowing conclusions to be stated with greater certainty. Cover more areas: This project covers what is regarded as the essentials for migration from Java to .NET development. Other specialist areas could be added to this report as supplementary investigations. This might include the development of Enterprise Applications using the capabilities offered by Java 2 Enterprise Edition and ASP.NET. The security side could also be investigated, perhaps through comparing Java and .NET cryptography classes. Further developer involvement: After reading the Recommendation Guidelines and Technical Framework, developers could be further questioned following migration. This may well raise new issues which had not been anticipated.

60

REFERENCES
[1] Microsoft: Longhorn Announcement Date, http://www.microsoft.com/presspass/press/2004/Aug04/0827Target2006PR.mspx [July 2005], Aug 2004 [2] Microsoft: Windows Vista Information: http://www.microsoft.com/windowsvista/basics/default.mspx [July 2004] [3] Maunder, C., What .NET means to Developers, http://www.codeproject.com/interview/interview_msdn_0103.asp [July 2005], Jan 2003 [4] Hentzen, W., The Software Developer’s Guide: Third Edition, Hentzenwerke Publishing, 2002 [5] Wikipedia Online Encyclopaedia, Platform (computing), http://en.wikipedia.org/wiki/Platform_%28computing%29 [March 2005] [6] Zukowski, J., Mastering Java 2 J2SE 1.4, Sybex, 2004 [7] Hardee, M., Smaragdis, M., Java[tm] 2 Platform, http://java.sun.com/java2/whatis/ [March 2005] [8] Kanalakis, J., Developing .Net Enterprise Applications, Apress, 2003 [9] Easton, M., King, J., Cross Platform .NET Development Using Mono, Portable.NET, and Microsoft .NET, Apress, 2004 [10] Official Java Website, About the Java Technology, http://java.sun.com/docs/books/tutorial/getStarted/intro/definition.html [March 2005] [11] Horton, I., Beginning Java 2, Wrox Press, 1999 [12] Efford, N., DSS Lecture - Java & .NET Security, [April 2005], 2005 [13] Garside, R., Mariani, J., Java: First Contact, Course Technology, 1998 [14]MSDN homepage, Introduction to C#, http://msdn.microsoft.com/library/default.asp?url=/library/enus/csspec/html/vclrfcsharpspec_1.asp [March 2005] [15] James, A., Freeman, A., C# for Java Developers, Microsoft Press, 2003 [16] Bagnall, B., Chen, P., Goldberg, S., C# for Java Programmers, Syngress Publishing, 2002, Pages 29-32 [17] Mono Project Website, About Mono, http://www.mono-project.com/About_Mono [March 2005], March 2005 [18] Mono Project, Frequently Asked Questions Page, http://www.mono-project.com/FAQ:_General [July 2005] [19] Flanagan,9D., Java In a Nutshell: A Desktop Quick Reference, O’Reilly, 2002 [20] Drayton, P., Albahari, B., Neward, T., C# In a Nutshell: A Desktop Quick Reference, O’Reilly, 2002 [21] Sun Microsystems, J2SE 5.0 New Features, http://java.sun.com/j2se/1.5.0/docs/relnotes/features.html# [July 2005] [22] Khalid, A., Rasmussen, R., A Programmer’s Guide to Java Certification, Addison-Wesley, 2000 [23] Chappel, D., Understanding .NET: A Tutorial and Analysis, Addison-Wesley, 2002 [24] Harris, R., C# Complete, Sybex, 2003 [25] Sun Microsystems, J2SE 5.0 New Features, http://java.sun.com/j2se/1.5.0/docs/relnotes/features.html# [July 2005]
61

[26] Java , Java 2 Platform SE 5.0 API, http://java.sun.com/j2se/1.5.0/docs/api [July 2005] [27] Sierra, K., Bates, B., Sun Certified Programmer & Developer for Java 2, McGraw Hill, 2003 [28] Tidwell, D., XSLT, O’Reilly, 2001 [29] Andrews, M., Getting Started with Swing, Sun Micrososystems, 2005 [30] Burke, S., Using the Microsoft .NET Framework to Create Windows-based Applications, Dec 2001 [31] Mono Project, Licensing and Patents, http://www.mono-project.com/FAQ:_Licensing#Patents [July 2005] [32] Mono Project, Mono development schedule,, http://www.mono-project.com/Mono_Project_Roadmap [July 2005] [33] Mono Project, Monodevelop IDE, http://www.monodevelop.com/ [July 2005] [34] Meijer, E., Gough, J., Technical Overview of the Common Language Runtime, 2001 [35] Singer, J., JVM versus CLR: A Comparative Study, Kilkenny City, June 2003 [36] Sun Microsystems, JDK Development Tools, http://java.sun.com/j2se/1.5.0/docs/tooldocs/index.html#basic [July, August 2005] [37] Microsoft, .Net Framework Help File, 2003 [38] Mono Project, Command-Line Tools, http://www.mono-project.com/Command-Line_Tools#Main_tools [August 2005]. [39] IBM Corporation, Eclipse Platform Technical Overview, Object Technology International, 2003 [40] Liberty, J., Learning C#, O’Reilly, Sept 2002 [41] Microsoft, Microsoft Java Language Conversion Assistant 2.0, http://msdn.microsoft.com/vstudio/downloads/tools/jlca/ [July 2005] [42] Efford, N., Personal Communication, 17th July, 2005

62

APPENDIX A – PROJECT REFLECTION
This project proved to be a great challenge and in the process of completing it I learnt a number of important lessons that should stand me in good stead for the future. Essentially I learnt to work independently and under my own my initiative. This included learning how to selectively extract information from resources and being aware of marketing bias. The project gave me the opportunity to make independent judgement as to what to include, striking a fair balance between ranges of topics and the depth to which each was studied. Project management was especially significant, as I often had to reorganise the order of tasks, frequently performing more than one task at a time. Furthermore, I learnt to be impartial and compare the two technologies as fairly as possible. As the project progressed, these skills became more refined, allowing me to work more efficiently. Experimenting with new technologies was very rewarding. I have always been interested in the .NET Framework but previously haven’t had the opportunity to study it in detail. Using .NET, especially the C# Language, has given me the chance to exercise and extend my programming skills. Although I had previous experience with the Java language, I learnt various new language features such as static imports, enhanced for loops and generics. The comparison gave me the opportunity to learn XML technologies with the use of XSL to transform documents. The construction of graphical user interfaces using Windows Forms was interesting as it was new to me. However, constructing the Java Swing GUI was largely frustrating due to the steep learning curve. Comparing library features involved the painstaking task of delving through masses of API documentation. Although this was a monotonous task is was an essential requirement of this type of project because of the importance of comparing the equivalent features at all times. I discovered that it is best to compare by example. Often it was necessary to implement certain features to grasp the full extent to which they differed. This awareness is not always possible through reading literature alone. Therefore, in order to succeed I would advice anyone wishing to take on such a project to implement some sample programs in advance of reading literature. The skills I acquired include project management, the ability to work under my own initiative and the capability to be flexible with new technologies. I believe these qualities will be invaluable when needed in prospective job situations.

63

APPENDIX B – MID PROJECT REPORT HEADER SHEETS

64

65

66

APPENDIX C – CODE EXAMPLES
C.1 C# Swap Method
using System; public class Reverse { static void Swap(ref string a, ref string b) { string temp = a; a = b; b = temp; } static void Main() { string x = "Bush"; string y = "Gore"; Swap(ref x, ref y); Console.WriteLine("x is " + x + " y is " + y); } }

C.2 Java Swap Method
public class Reverse { public static void main(String [] args) { { String x = "Bush"; String y = "Gore"; String m = y; String n = x; System.out.println("x is " + m + " y is " + n); } } }

C.3 Reading Input from File
C.3.1 Java Code – Present on CD C.3.2 C# Code – Present on CD

67

C.4 XML Code
C.4.1 RSS Document

<?xml version="1.0" encoding="ISO-8859-1" ?> <?xml-stylesheet title="XSL_formatting" type="text/xsl" href="/shared/bsp/xsl/rss/nolsol.xsl"?> <rss version="2.0"><channel> <title>BBC News | UK | UK Edition</title> <link>http://news.bbc.co.uk/go/rss/-/1/hi/uk/default.stm</link> <description>Updated every minute of every day</description> <language>en-gb</language> <lastBuildDate>Mon, 11 Jul 05 20:03:37 GMT</lastBuildDate> <copyright>Copyright: (C) British Broadcasting Corporation, see http://news.bbc.co.uk/1/hi/help/rss/4498287.stm for terms and conditions of reuse</copyright> <docs>http://www.bbc.co.uk/syndication/</docs> <ttl>15</ttl> <image> <title>BBC News</title> <url>http://news.bbc.co.uk/nol/shared/img/bbc_news_120x60.gif</url> <link>http://news.bbc.co.uk</link> </image> <item> <title>First victim named as toll rises</title> <description>The first victim of the London bombs has been named, as the confirmed number of dead reaches 52.</description> <link>http://news.bbc.co.uk/go/rss/-/1/hi/uk/4671993.stm</link> <guid isPermaLink="false">http://news.bbc.co.uk/1/hi/uk/4671993.stm</guid> <pubDate>Mon, 11 Jul 05 18:18:16 GMT</pubDate> </item> <item> <title>Jenkins facing third murder trial</title> <description>Sion Jenkins faces a third trial after a jury fails to decide whether he murdered his foster daughter Billie-Jo.</description> <link>http://news.bbc.co.uk/go/rss/-/1/hi/england/southern_counties/4638201.stm</link> <guid isPermaLink="false">http://news.bbc.co.uk/1/hi/england/southern_counties/4638201.stm</guid> <pubDate>Mon, 11 Jul 05 16:40:18 GMT</pubDate> </item>
C.4.2 Java DOM Parser Code – Present on CD C.4.3 C# DOM Parser Code – Present on CD C.4.4 XSLT file

<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0"> <xsl:template match = "title"> <h2><xsl:value-of select = "text()" /></h2> </xsl:template> <xsl:template match = "description"> <xsl:value-of select = "text()" /> </xsl:template> <xsl:template match = "link"> 68

<br><a href = "{text()}"><xsl:value-of select = "text() " /></a></br> </xsl:template> <xsl:template match = "pubDate"> <i><xsl:value-of select = "text()" /></i> </xsl:template> </xsl:stylesheet>
C.4.5 Java XSLT Code – Present on CD C.4.6 C# XSLT Code – Present on CD

C.5 VAT Calculator GUI Code
C.5.1 Java GUI Application Code – Present on CD C.5.2 C# GUI Application Code – Present on CD

C.6 Benchmarking I/O Code
C.6.1 Random Number Generator Code

import java.util.Random; public class RandomNumGen { public static void main (String [] args) { Random gen = new Random(); EasyWriter outFile = new EasyWriter("C:/Documents and Settings/All Users/Documents/Dell Project Stuff/Dissertation code examples/Numbergen.txt"); for (int i=0 ; i < 100 ; i++) { int x = 10001; int y = gen.nextInt(x); outFile.println(y); } outFile.close(); } }
C.6.2 Java Number Reader Program – Present on CD C.6.3 C# Number Reader Program – Present on CD

69

APPENDIX D – SAMPLE QUESTIONNAIRES

70

71

72

APPENDIX E – INITIAL AIMS AND REQUIREMENTS
Email 16/03/2005 AIM AND REQUIREMENTS FORM COPIED TO SUPERVISOR AND STUDENT -----------------------------------------------------------------------------------------------------Name of the student: Mandip PANESAR Email address: scs4msp MIS - MSc in Information Systems Degree programme: Supervisor: Company: The aim is: To produce a technical analysis of Java and .NET platforms, allowing programmers to be aware of the issues for migration from one platform to the other. The project outline is: Background reading: Research on Java and .NET platforms, languages, development tools available Methodology: This is not a software development project so no traditional development methodology will be followed; however, Rapid Applications Development will be performed for creating small applications quickly. Product: A report consisting of a critical evaluation, aided by test applications. Evaluation of product: An evaluation of the comparison (report content). The minimum requirements are: 1. Produce a technical report comparing Java and .NET platforms 2. Produce test programs in both Java and .NET languages, aiding the comparison
73

Number of credits: 60 nde (none)

3. (none) 4. (none) 5. (none) The hardware and software resources are: 1. 2. 3. The foundation modules are: 1. COMP5010M 2. COMP5160M The project title is Java and .NET - A comparative Evaluation.

74


				
DOCUMENT INFO
DevStuff DevStuff
About