Contents - Cultural View
Contents - Cultural View Contents - Cultural View
Comparison of Java and C Sharp 68 Object handling Both C# and Java are designed from the ground up as object oriented languages using dynamic dispatch, with syntax similar to C++ (C++ in turn derives from C). Neither language is a superset of C or C++, however. Both mainly use garbage collection as a means of reclaiming memory resources, rather than explicit deallocation of memory (though C# requires explicit deallocation for graphical, GDI+ objects, in which case it uses the IDisposable interface). Both include thread synchronization mechanisms as part of their language syntax. In both languages objects are created with a new. References In both languages references are a central concept. All instances of classes are by reference. While not directly evident in the language syntax per se, both languages support the concept of weak references. An instance which is only referenced by weak references is eligible for garbage collection just as if there were no references at all. In both languages this feature is exposed through the associated libraries, even though it is really a core runtime feature. In addition to weak references, Java has soft references. Soft references are much like weak references, but the JVM will not deallocate softly-referenced objects until the memory is actually needed. Object initialization In both C# and Java, an object's fields can be initialized either by variable initializers (expressions that can be assigned to variables where they are defined) or by constructors (special subroutines that are executed when an object is being created). In addition, Java contains instance initializers, which are anonymous blocks of code with no arguments that are run before the constructor is executed. C# initializes object fields in the following order when creating an object: 1. Derived static fields 2. Derived static constructor 3. Derived instance fields 4. Base static fields 5. Base static constructor 6. Base instance fields 7. Base instance constructor 8. Derived instance constructor Some of the above fields may not be applicable (e.g. if an object does not have static fields). Derived fields are those that are defined in the object's direct class while base fields is a term for the fields that are defined in one of the object's superclasses. Note that an object representation in memory contains all fields defined in its class or any of its superclasses, even if some fields in superclasses are defined as private. It is guaranteed that any field initializers take effect before any constructors are called, since both instance constructor of the object's class and its super classes are called after field initializers are called. There is, however, a potential trap in object initialization when a virtual method is called from a base constructor. The overridden method in a subclass may reference a field that is defined in the subclass, but this field may not been initialized because the cubclass' constructor that contains field initialization is called after the constructor of its base class. In Java, the order of initialization is as follows: 1. Invocation of another constructor (either of the object's class or of object's superclass) 2. Instance variable initializers and instance initializers (in the order they appear listed in source code) 3. The constructor body
Comparison of Java and C Sharp 69 Like in C#, a new object is created by calling a specific constructor. Within a constructor, the first statement may be invocation of another constructor. If this is omitted, the call to the super class' argument-less constructor is added implicitly by the compiler. Otherwise, either another overloaded constructor of the object's class can be called explicitly, or a superclass' constructor can be called. In the former case, the called constructor will again call another constructor (either of the object's class or its cubclass) and the chain sooner or later ends up at the call to one of the superclass' constructor. After another constructor is called (which causes direct invocation superclass' constructor, and so forth, down to the Object class), instance variables defined in the object's class are initialized. Even if there are no variable initializers explicitly defined for some variables, these variables are initialized to default values. Note that instance variables defined in superclasses are already initialized by this point, because they were initialized by superclass' constructor when it was called (either by constructor's code or by variables' initializers performed before constructor's code or implicitly to default values). In Java, variable initializers are executed according to their textual order in the source file. Finally, the constructor body is executed. This ensures proper order of initialization, i.e. the fields of a base class finish initialization before initialization of the fields of an object class begins. There are two main potential traps in Java's object initialization. First, variable initializers are expressions that can contain method calls. Since methods can reference any variable defined in the class, the method called in variable's initializer can reference a variable that is defined below the variable being initialized. Since initialization order corresponds to textual order of variable definitions, such a variable would not be initialized to the value prescribed by its initializer and would contain the default value. Another potential trap is when a method that is overridden in the derived class is called in the base class' constructor, which can lead to behavior the programmer would not expect when object of the derived class is created. According to initialization order, the body of the base class' constructor is executed before variable initializers are evaluated and before the body of the derived class' constructor is executed. The overridden method called form the base class' constructor can however reference variables defined in the derived class, but these are not yet initialized to the values specified by their initializers or set in derived class' constructor. Arrays and collections Arrays and collections concepts featured by both languages. The syntax used to declare and access arrays is identical, except that C# has added syntax for declaring and manipulating multidimensional arrays. Java C# Arrays are implicitly direct specializations of Object. They are not unified with collection types. Instead of a common iterable/enumerable interface, the for loop accepts either arrays or Iterable (a collection interface). This means that the same short syntax can be used in for-loops. Arrays and collections are completely separate with no unification. Arrays cannot be passed where sequences or collections are expected Arrays in C# are implicitly specializations the System.Array class which implement a number of collection interfaces. The foreach statement iterates through a sequence using the IEnumerable orIEnumerable interface. Because arrays always implicitly implement these interfaces, the loop will iterate through arrays as well. Arrays can be passed where sequences (IEnumerables) or collections/list interfaces are expected. However, the collection operations which alter the number of elements (insert/add/remove) will throw exceptions as these operations are not supported by arrays. In both languages arrays are covariant. This means that a String[] array is assignable to variables of Object[] because String is a specialization of (assignable to) Object. In both languages the arrays will perform a type check when inserting new values because type-safety would otherwise be compromised. This is in contrast to how generic collections have been implemented in both languages. Multidimensional arrays only in the form of arrays of arrays (also known as "jagged" arrays); Java does not have true rectangular multidimensional arrays. True multidimensional "rectangular" arrays, as well as the arrays-of-arrays (jagged arrays).
- Page 21 and 22: AgentSheets 17 year, per school. Of
- Page 23 and 24: AgentSheets 19 References [1] Cyber
- Page 25 and 26: Lightweight Java 21 Lightweight Jav
- Page 27 and 28: .properties 23 See also • java.ut
- Page 29 and 30: Apache Harmony 25 Sun answered on a
- Page 31 and 32: Apache Harmony 27 Component Descrip
- Page 33 and 34: Apache Harmony 29 [10] Gilbert, Dav
- Page 35 and 36: Apache Shiro 31 Apache Shiro Develo
- Page 37 and 38: Java applet 33 there are frequently
- Page 39 and 40: Java applet 35 } } g.drawString("He
- Page 41 and 42: Java applet 37 The 2002 Sun - Micro
- Page 43 and 44: Java applet 39 [18] W3.org (http:/
- Page 45 and 46: Associació d'Usuaris de Java de Ca
- Page 47 and 48: Associació d'Usuaris de Java de Ca
- Page 49 and 50: Associació d'Usuaris de Java de Ca
- Page 51 and 52: Associació d'Usuaris de Java de Ca
- Page 53 and 54: Bean Scripting Framework 49 Bean Sc
- Page 55 and 56: CJAN 51 Ostensibly, CJAN.org failed
- Page 57 and 58: Chainsaw (log file viewer) 53 Chain
- Page 59 and 60: clone (Java method) 55 Alternatives
- Page 61 and 62: clone (Java method) 57 } } abstract
- Page 63 and 64: Comparison of Java and C Sharp 59 A
- Page 65 and 66: Comparison of Java and C Sharp 61 R
- Page 67 and 68: Comparison of Java and C Sharp 63 T
- Page 69 and 70: Comparison of Java and C Sharp 65 f
- Page 71: e="6.73"> = 42; = null; Comparison
- Page 75 and 76: Comparison of Java and C Sharp 71 I
- Page 77 and 78: Comparison of Java and C Sharp 73 t
- Page 79 and 80: Comparison of Java and C Sharp 75 N
- Page 81 and 82: Comparison of Java and C Sharp 77 L
- Page 83 and 84: Comparison of Java and C Sharp 79 T
- Page 85 and 86: Comparison of Java and C Sharp 81 C
- Page 87 and 88: Comparison of Java and C++ 83 C++ J
- Page 89 and 90: Comparison of Java and C++ 85 e="7.
- Page 91 and 92: Comparison of Java and C++ 87 the c
- Page 93 and 94: Comparison of Java and C++ 89 • D
- Page 95 and 96: Comparison of Java and C++ 91 Sever
- Page 97 and 98: Comparison of the Java and .NET pla
- Page 99 and 100: Comparison of the Java and .NET pla
- Page 101 and 102: Comparison of the Java and .NET pla
- Page 103 and 104: Comparison of the Java and .NET pla
- Page 105 and 106: Constant interface 101 } public sta
- Page 107 and 108: Java 4K Game Programming Contest 10
- Page 109 and 110: Java 4K Game Programming Contest 10
- Page 111 and 112: CookXml 107 Creators, setters, adde
- Page 113 and 114: Cougaar 109 Cougaar Cougaar is a Ja
- Page 115 and 116: Devoxx 111 Related links • Devoxx
- Page 117 and 118: Elastic Path 113 References [1] htt
- Page 119 and 120: Electronic Disturbance Theater 115
- Page 121 and 122: Event dispatching thread 117 • Sw
Comparison of Java and C Sharp 68<br />
Object handling<br />
Both C# and Java are designed from the ground up as object oriented languages using dynamic dispatch, with syntax<br />
similar to C++ (C++ in turn derives from C). Neither language is a superset of C or C++, however. Both mainly use<br />
garbage collection as a means of reclaiming memory resources, rather than explicit deallocation of memory (though<br />
C# requires explicit deallocation for graphical, GDI+ objects, in which case it uses the IDisposable interface). Both<br />
include thread synchronization mechanisms as part of their language syntax.<br />
In both languages objects are created with a new.<br />
References<br />
In both languages references are a central concept. All instances of classes are by reference.<br />
While not directly evident in the language syntax per se, both languages support the concept of weak references. An<br />
instance which is only referenced by weak references is eligible for garbage collection just as if there were no<br />
references at all. In both languages this feature is exposed through the associated libraries, even though it is really a<br />
core runtime feature.<br />
In addition to weak references, Java has soft references. Soft references are much like weak references, but the JVM<br />
will not deallocate softly-referenced objects until the memory is actually needed.<br />
Object initialization<br />
In both C# and Java, an object's fields can be initialized either by variable initializers (expressions that can be<br />
assigned to variables where they are defined) or by constructors (special subroutines that are executed when an<br />
object is being created). In addition, Java contains instance initializers, which are anonymous blocks of code with no<br />
arguments that are run before the constructor is executed.<br />
C# initializes object fields in the following order when creating an object:<br />
1. Derived static fields<br />
2. Derived static constructor<br />
3. Derived instance fields<br />
4. Base static fields<br />
5. Base static constructor<br />
6. Base instance fields<br />
7. Base instance constructor<br />
8. Derived instance constructor<br />
Some of the above fields may not be applicable (e.g. if an object does not have static fields). Derived fields are those<br />
that are defined in the object's direct class while base fields is a term for the fields that are defined in one of the<br />
object's superclasses. Note that an object representation in memory contains all fields defined in its class or any of its<br />
superclasses, even if some fields in superclasses are defined as private.<br />
It is guaranteed that any field initializers take effect before any constructors are called, since both instance<br />
constructor of the object's class and its super classes are called after field initializers are called. There is, however, a<br />
potential trap in object initialization when a virtual method is called from a base constructor. The overridden method<br />
in a subclass may reference a field that is defined in the subclass, but this field may not been initialized because the<br />
cubclass' constructor that contains field initialization is called after the constructor of its base class.<br />
In Java, the order of initialization is as follows:<br />
1. Invocation of another constructor (either of the object's class or of object's superclass)<br />
2. Instance variable initializers and instance initializers (in the order they appear listed in source code)<br />
3. The constructor body