 |
Business | Industries | Finance | Tax |
| Index: > A B C D E F G H I J K L M N O P Q R S T U V W X Y Z |
|
|||||
| First Prev [ 1 2 3 4 5 6 ] Next Last |
Java has been lauded for what some see as being simpler than other popular object-oriented languages such as C++, its garbage collection mechanisms as simplifying memory management, and having a consistent set of classes available across supported platforms. However, natural objections arise to some of these positive points of Java, such as garbage collection encouraging lazy programming and its efficiency concerns.
Yet, underlying Java, there tends to be more subtle concerns with the implementation of the language in particular. Java is closely modeled on Objective-C, a dynamically typed hybrid object-oriented programming language. Java implements an Objective-C like generic class, Object, which can be used in container classes . However Java is not truly dynamically typed, which can result in forced clumsy use of the class. For example, if we have a container class with class methods Object pop() and void push(Object o), and instance called stack, when we add say an Integer with the push method, we must always invoke it as
stack.push(new Integer(number))and we must always retrieve the element as
Integer x = ((Integer) stack.pop());This may not seem such a bad thing, but the chaining of method calls can become cumbersome, for example, one could well write
int x = ((Integer) ((Node) linkedlist.node()).data()).intValue();Some argue that having this style of type restrictions enforces type safety, but that casting breaks the discipline of strong typing. However, Java objects know their own class, and cannot be cast into incorrect classes or interfaces; any attempt to do so generates a ClassCastException, so in fact strong typing is always preserved. Storing an incorrect type in a container may only be discovered at runtime, but it will never corrupt the data by treating it as a different type, as happens all too often in C/C++.
In response to such criticisms, Java 2 Version 5 (the renamed version 1.5; see below) has support for generic programming, eliminating the need for such casts. In addition to generics another language feature, known as Autoboxing eliminates the need for an explicit promotion between primitive and Object types. The J2SE 5.0 example can then be re-written as
stack.push(number)and retrieved without the cast
Integer x = stack.pop();and without the explicit conversion
int x = (linkedlist.node()).data();In Objective-C, by comparison, the above method calls are written:
[stack push:number] Integer *x = [stack pop] int x = [linkedlist node] data] intValue]Since Objective-C uses dynamic typing, the casts need not be explicitly specified by the programmer.
Versions of Java prior to 1.4 only supported stream-based [linkedlist node] data] intValue] Since Objective-C uses dynamic typing, the casts need not be explicitly specified by the programmer.
Versions of Java prior to 1.4 only supported stream-based blocking I/O . This required a thread per stream being handled, as no other processing could take place while the active thread blocked waiting for input or output. This was a major scalability and performance issue for anyone needing to implement any Java network service. Since the introduction of NIO (New IO) in Java 1.4, this scalability problem has been rectified by the introduction of a non-blocking I/O framework (though there are a number of open issues in the NIO API as implemented by Sun).
The non-blocking IO framework, though considerably more complex than the original blocking IO framework, allows any number of "channels" to be handled by a single thread. The framework is based on the Reactor Pattern.
The following code snippet shows how user input is accepted from a keyboard and displayed back using stream-based blocking IO. Note that the main thread will block while waiting for input from standard input. If one wanted, for instance, to display a blinking cursor, another thread would have to be created to create the blinking effect.
public static void main(String[] args) throws java.io.IOException { char a; System.out.println("Welcome user, please enter a letter"); a = (char) System.in.read(); System.out.println("Your letter was " + a); }Sun has defined 3 platforms targeting different application environments and segmented many of its APIs so that they belong to one of the platforms. The platforms are:
The classes in the Java APIs are organized into separate groups called packages. Each package contains a set of related interfaces, classes and exceptions. Refer to the separate platforms for a description of the packages available.
The set of APIs is controlled by Sun Microsystems in cooperation with others through its Java Community Process program. Companies or individuals participating in this process can influence the design and development of the APIs, but Sun retains ownership and control of the APIs. This process has been a subject of controversy.
| Politics | Business | Finance |
 |
 |
 |
|