Introduction to Web Services
Web services, in the general meaning of the term, are services offered on the Web. In a typical Web services scenario, a business application uses the SOAP protocol over HTTP to send a request to a service at an URL. The service receives the request, processes it, and returns a response. An often-cited example of a Web service is that of a stock quote service, in which the request asks for the current price of a specified stock and the response returns the stock price. This is one of the simplest forms of a Web service: The request is fulfilled almost immediately; the request and response are parts of the same method call.
Another example could be a service that maps out an efficient route for the delivery of goods. In this case, a business sends a request with the delivery destinations, which the service then processes to determine the most cost-effective delivery route. The time it takes to return the response depends on the complexity of the routing; therefore, the response will probably be sent as an operation separate from the request.
Web services and their consumers are typically businesses, making Web services predominantly business-to-business (B-to-B) transactions. An enterprise can be the Web service provider and also the consumer of other Web services. For example, a wholesale distributor of spices is in the consumer role when it uses a Web service to check on the availability of vanilla beans and in the provider role when it supplies prospective customers with prices for vanilla beans.
The Role of XML and the Java Platform
Web services depend on the ability of parties to communicate with each other even if they are using different information systems. XML (eXtensible Markup Language), which makes data portable, is a key technology in addressing this need. Enterprises have discovered the benefits of using XML for the integration of data -- both internally for sharing legacy data among departments and externally for sharing data with other enterprises. As a result, XML is increasingly being used for enterprise application integration (EAI) in tightly coupled and loosely coupled systems. Thanks to its ability to integrate data, XML has become the underpinning for Web-related computing.
Overview of the Java APIs for XML (JAX APIs)
You can use the JAX APIs to develop Web applications entirely in the Java programming language. The APIs fall into two broad categories: those that deal directly with processing XML documents and those that deal with procedures.
Document-oriented
- Java API for XML Processing (JAXP) -- Processes XML documents with parsers.
- Java Architecture for XML Binding (JAXB) -- Processes XML documents with schema-derived JavaBeans component classes.
Procedure-oriented
- Java API for XML-based RPC (JAX-RPC) -- Sends SOAP method calls to remote parties over the Internet and receives the results.
- Java API for XML Messaging (SAAJ) -- Sends SOAP messages over the Internet in a standard way.
- Java API for XML Registries (JAXR) -- Provides a standard way to access business registries and share information.
Perhaps the most important feature of JAX APIs is that they all support industry standards, ensuring interoperability.
Applet Security
What are applets prevented from doing?
In general, applets loaded over the net are prevented from reading and writing files on the client file system, and from making network connections except to the originating host.
In addition, applets loaded over the net are prevented from starting other programs on the client. Applets loaded over the net are also not allowed to load libraries, or to define native method calls. If an applet could define native method calls, that would give the applet direct access to the underlying computer.
There are other specific capabilities denied to applets loaded over the net, but most of the applet security policy is described by those two paragraphs above. Read on for the gory details.
Can applets read or write files?
In Java-enabled browsers, untrusted applets cannot read or write files at all. By default, downloaded applets are considered untrusted. There are two ways for an applet to be considered trusted:
The applet is installed on the local hard disk, in a directory on the CLASSPATH used by the program that you are using to run the applet. Usually, this is a Java-enabled browser, but it could be the appletviewer, or other Java programs that know how to load applets.
The applet is signed by an identity marked as trusted in your identity database. For more information on signed applets, refer to an example of using signed applets, and to a short description on using javakey.
Sun's appletviewer allows applets to read files that reside in directories on the access control lists.
If the file is not on the client's access control list, then applets cannot access the file in any way. Specifically, applets cannot
check for the existence of the file
read the file
write the file
rename the file
create a directory on the client file system
list the files in this file (as if it were a directory)
check the file's type
check the timestamp when the file was last modified
check the file's size
How do I let an applet read a file?
Applets loaded into a Java-enabled browser can't read files.
Sun's appletviewer allows applets to read files that are named on the access control list for reading. The access control list for reading is null by default, in the JDK. You can allow applets to read directories or files by naming them in the acl.read property in your ~/.hotjava/properties file.
Note: The "~" (tilde) symbol is used on UNIX systems to refer to your home directory. If you install a web browser on your F:\ drive on your PC, and create a top-level directory named .hotjava, then your properties file is found in F:\.hotjava\properties.
For example, to allow any files in the directory home/me to be read by applets loaded into the appletviewer, add this line to your ~/.hotjava/properties file.
acl.read=/home/me
You can specify one file to be read: acl.read=/home/me/somedir/somefile
Use ":" to separate entries: acl.read=/home/foo:/home/me/somedir/somefile
Allowing an applet to read a directory means that it can read all the files in that directory, including any files in any subdirectories that might be hanging off that directory.
How do I let an applet write a file?
Applets loaded into a Java-enabled browser can't write files.
Sun's appletviewer allows applets to write files that are named on the access control list for writing. The access control list for writing is empty by default.
You can allow applets to write to your /tmp directory by setting the acl.write property in your ~/.hotjava/properties file: acl.write=/tmp
You can allow applets to write to a particular file by naming it explicitly:
acl.write=/home/me/somedir/somefile
Use : to separate entries: acl.write=/tmp:/home/me/somedir/somefile
Bear in mind that if you open up your file system for writing by applets, there is no way to limit the amount of disk space an applet might use.
What system properties can be read by applets, and how?
In both Java-enabled browsers and the appletviewer, applets can read these system properties by invoking System.getProperty(String key):
key meaning
java.version Java version number
java.vendor Java vendor-specific string
java.vendor.url Java vendor URL
java.class.version Java class version number
os.name Operating system name
os.arch Operating system architecture
os.version Operating system version
file.separator File separator (eg, "/")
path.separator Path separator (eg, ":")
line.separator Line separator
Applets are prevented from reading these system properties:
key meaning
java.home Java installation directory
java.class.path Java classpath
user.name User account name
user.home User home directory
user.dir User's current working directory
To read a system property from within an applet, simply invoke System.getProperty(key) on the property you are interested in.
For example,
String s = System.getProperty("os.name");
How do I hide system properties that applets are allowed to read by default?
There's no way to hide the above ten system properties from applets loaded into a Java-enabled browser. The reason is that the browsers don't consult any external files as part their Java configuration, as a security precaution, including the ~/.hotjava/properties file.
From the appletviewer, you can prevent applets from finding out anything about your system by redefining the property in your ~/.hotjava/properties file. For example, to hide the name of the operating system that you are using, add this line to your ~/.hotjava/properties file: os.name=null
How can I allow applets to read system properties that they aren't allowed to read by default?
There's no way to allow an applet loaded into a Java-enabled browser to read system properties that they aren't allowed to read by default.
To allow applets loaded into the appletviewer to read the property named by key, add the property key.applet=true to your ~/.hotjava/property file. For example, to allow applets to record your user name, add this line to your ~/.hotjava/properties file:
user.name.applet=true
How can an applet open a network connection to a computer on the internet?
Applets are not allowed to open network connections to any computer, except for the host that provided the .class files. This is either the host where the html page came from, or the host specified in the codebase parameter in the applet tag, with codebase taking precendence.
For example, if you try to do this from an applet that did not originate from the machine foo.com, it will fail with a security exception:
Socket s = new Socket("foo.com", 25, true);
How can an applet open a network connection to its originating host?
Be sure to name the originating host exactly as it was specified when the applet was loaded into the browser.
That is, if you load an HTML page using the URL
http://foo.state.edu/~me/appletPage.html
then your applet will be able to connect to its host only by using the name foo.state.edu. Using the IP address for foo.state.edu won't work, and using a "shorthand" form of the host name, like foo.state instead of foo.state.edu, won't work.
How can an applet maintain persistent state?
There is no explicit support in the JDK applet API for persistent state on the client side. However, an applet can maintain its own persistent state on the server side. That is, it can create files on the server side and read files from the server side.
Can an applet start another program on the client?
No, applets loaded over the net are not allowed to start programs on the client. That is, an applet that you visit can't start some rogue process on your PC. In UNIX terminology, applets are not allowed to exec or fork processes. In particular, this means that applets can't invoke some program to list the contents of your file system, and it means that applets can't invoke System.exit() in an attempt to kill your web browser. Applets are also not allowed to manipulate threads outside the applet's own thread group.
What features of the Java language help people build secure applets?
Java programs do not use pointers explicitly. Objects are accessed by getting a handle to the object. Effectively, this is like getting a pointer to an object, but Java does not allow the equivalent of pointer arithmetic on object handles. Object handles cannot be modified in any way by the Java applet or application.
C and C++ programmers are used to manipulating pointers to implement strings and to implement arrays. Java has high-level support for both strings and arrays, so programmers don't need to resort to pointer arithmetic in order to use those data structures.
Arrays are bounds-checked at runtime. Using a negative index causes a runtime exception, and using an index that is larger than the size of the array causes a runtime exception. Once an array object is created, its length never changes.
Strings in Java are immutable. A string is zero or more characters enclosed in double quotes, and it's an instance of the String class. Using immutable strings can help prevent common runtime errors that could be exploited by hostile applets.
The Java compiler checks that all type casts are legal. Java is a strongly typed language, unlike C or C++, and objects cannot be cast to a subclass without an explicit runtime check.
The final modifier can be used when initializing a variable, to prevent runtime modification of that variable. The compiler catches attempts to modify final variables.
Before a method is invoked on an object, the compiler checks that the object is the correct type for that method. For example,
invoking t.currentThread() when t is not a Thread object causes a compile time error.
Java provides four access modifiers for methods and variables defined within classes and makes sure that these access barriers are not violated.
public: a public method is accessible anywhere the class name is accessible
protected: a protected method is accessible by a child of a class as long as it is trying to access fields in a similarly typed class.
For example,
class Parent { protected int x; }
class Child extends Parent { ... }
The class Child can access the field "x" only on objects that are of type Child (or a subset of Child.)
private: a private method is accessible only within its defining class
default: if no modifier is specified, then by default, a method is accessible only within its defining package
For example, programmers can choose to implement sensitive functions as private methods. The compiler and the runtime checks ensure that no objects outside the class can invoke the private methods.
What is the difference between applets loaded over the net and applets loaded via the file system?
There are two different ways that applets are loaded by a Java system. The way an applet enters the system affects what it is allowed to do.
If an applet is loaded over the net, then it is loaded by the applet class loader, and is subject to the restrictions enforced by the applet security manager.
If an applet resides on the client's local disk, and in a directory that is on the client's CLASSPATH, then it is loaded by the file system loader. The most important differences are
applets loaded via the file system are allowed to read and write files
applets loaded via the file system are allowed to load libraries on the client
applets loaded via the file system are allowed to exec processes
applets loaded via the file system are allowed to exit the virtual machine
applets loaded via the file system are not passed through the byte code verifier
Java-enabled browsers use the applet class loader to load applets specified with file: URLs. So, the restrictions and protections that accrue from the class loader and its associated security manager are now in effect for applets loaded via file: URLs.
This means that if you specify the URL like so:
Location: file:/home/me/public_html/something.html
and the file something.html contains an applet, the browser loads it using its applet class loader.
What's the applet class loader, and what does it buy me?
Applets loaded over the net are loaded by the applet class loader. For example, the appletviewer's applet class loader is implemented by the class sun.applet.AppletClassLoader.
The class loader enforces the Java name space hierarchy. The class loader guarantees that a unique namespace exists for classes that come from the local file system, and that a unique namespace exists for each network source. When a browser loads an applet over the net, that applet's classes are placed in a private namespace associated with the applet's origin. Thus, applets loaded from different network sources are partitioned from each other.
Also, classes loaded by the class loader are passed through the verifier. The verifier checks that the class file conforms to the Java language specification - it doesn't assume that the class file was produced by a "friendly" or "trusted" compiler. On the contrary, it checks the class file for purposeful violations of the language type rules and name space restrictions. The verifier ensures that
There are no stack overflows or underflows.
All register accesses and stores are valid.
The parameters to all bytecode instructions are correct.
There is no illegal data conversion.
The verifier accomplishes that by doing a data-flow analysis of the bytecode instruction stream, along with checking the class file format, object signatures, and special analysis of finally clauses that are used for Java exception handling.
Details on the verifier's design and implementation were presented in a paper by Frank Yellin at the December 1995 WWW conference in Boston.
A web browser uses only one class loader, which is established at start-up. Thereafter, the system class loader cannot be extended, overloaded, overridden or replaced. Applets cannot create or reference their own class loader.
What's the applet security manager, and what does it buy me?
The applet security manager is the Java mechanism for enforcing the applet restrictions described above. The appletviewer's applet security manager is implemented by sun.applet.AppletSecurity.
A browser may only have one security manager. The security manager is established at startup, and it cannot thereafter be replaced, overloaded, overridden, or extended. Applets cannot create or reference their own security manager.
Is there a summary of applet capabilities?
The following table is not an exhaustive list of applet capabilities. It's meant to answer the questions we hear most often about what applets can and cannot do.
Key:
NN: Netscape Navigator 4.x, loading unsigned applets over the Net
NL: Netscape Navigator 4.x, loading unsigned applets from the Local file system
AN: Appletviewer, JDK 1.x, loading applets over the Net
AL: Appletviewer, JDK 1.x, loading applets from the Local file system
JS: Java Standalone applications
Stricter ------------------------> Less strict
NN NL AN AL JS
read file in /home/me, no no no yes yes
acl.read=null
read file in /home/me, no no yes yes yes
acl.read=/home/me
write file in /tmp, no no no yes yes
acl.write=null
write file in /tmp, no no yes yes yes
acl.write=/tmp
get file info, no no no yes yes
acl.read=null
acl.write=null
get file info, no no yes yes yes
acl.read=/home/me
acl.write=/tmp
delete file, no no no no yes
using File.delete()
delete file, no no no yes yes
using exec /usr/bin/rm
read the user.name no yes no yes yes
property
connect to port no no no yes yes
on client
connect to port no no no yes yes
on 3rd host
load library no yes no yes yes
exit(-1) no no no yes yes
create a popup no yes no yes yes
window without
a warning
If other languages are compiled to Java bytecodes, how does that affect the applet security model?
The verifier is independent of Sun's reference implementation of the Java compiler and the high-level specification of the Java language. It verifies bytecodes generated by other Java compilers. It also verifies bytecodes generated by compiling other languages into the bytecode format. Bytecodes imported over the net that pass the verifier can be trusted to run on the Java virtual machine. In order to pass the verifier, bytecodes have to conform to the strict typing, the object signatures, the class file format, and the predictability of the runtime stack that are all defined by the Java language implementation
In general, applets loaded over the net are prevented from reading and writing files on the client file system, and from making network connections except to the originating host.
In addition, applets loaded over the net are prevented from starting other programs on the client. Applets loaded over the net are also not allowed to load libraries, or to define native method calls. If an applet could define native method calls, that would give the applet direct access to the underlying computer.
There are other specific capabilities denied to applets loaded over the net, but most of the applet security policy is described by those two paragraphs above. Read on for the gory details.
Can applets read or write files?
In Java-enabled browsers, untrusted applets cannot read or write files at all. By default, downloaded applets are considered untrusted. There are two ways for an applet to be considered trusted:
The applet is installed on the local hard disk, in a directory on the CLASSPATH used by the program that you are using to run the applet. Usually, this is a Java-enabled browser, but it could be the appletviewer, or other Java programs that know how to load applets.
The applet is signed by an identity marked as trusted in your identity database. For more information on signed applets, refer to an example of using signed applets, and to a short description on using javakey.
Sun's appletviewer allows applets to read files that reside in directories on the access control lists.
If the file is not on the client's access control list, then applets cannot access the file in any way. Specifically, applets cannot
check for the existence of the file
read the file
write the file
rename the file
create a directory on the client file system
list the files in this file (as if it were a directory)
check the file's type
check the timestamp when the file was last modified
check the file's size
How do I let an applet read a file?
Applets loaded into a Java-enabled browser can't read files.
Sun's appletviewer allows applets to read files that are named on the access control list for reading. The access control list for reading is null by default, in the JDK. You can allow applets to read directories or files by naming them in the acl.read property in your ~/.hotjava/properties file.
Note: The "~" (tilde) symbol is used on UNIX systems to refer to your home directory. If you install a web browser on your F:\ drive on your PC, and create a top-level directory named .hotjava, then your properties file is found in F:\.hotjava\properties.
For example, to allow any files in the directory home/me to be read by applets loaded into the appletviewer, add this line to your ~/.hotjava/properties file.
acl.read=/home/me
You can specify one file to be read: acl.read=/home/me/somedir/somefile
Use ":" to separate entries: acl.read=/home/foo:/home/me/somedir/somefile
Allowing an applet to read a directory means that it can read all the files in that directory, including any files in any subdirectories that might be hanging off that directory.
How do I let an applet write a file?
Applets loaded into a Java-enabled browser can't write files.
Sun's appletviewer allows applets to write files that are named on the access control list for writing. The access control list for writing is empty by default.
You can allow applets to write to your /tmp directory by setting the acl.write property in your ~/.hotjava/properties file: acl.write=/tmp
You can allow applets to write to a particular file by naming it explicitly:
acl.write=/home/me/somedir/somefile
Use : to separate entries: acl.write=/tmp:/home/me/somedir/somefile
Bear in mind that if you open up your file system for writing by applets, there is no way to limit the amount of disk space an applet might use.
What system properties can be read by applets, and how?
In both Java-enabled browsers and the appletviewer, applets can read these system properties by invoking System.getProperty(String key):
key meaning
java.version Java version number
java.vendor Java vendor-specific string
java.vendor.url Java vendor URL
java.class.version Java class version number
os.name Operating system name
os.arch Operating system architecture
os.version Operating system version
file.separator File separator (eg, "/")
path.separator Path separator (eg, ":")
line.separator Line separator
Applets are prevented from reading these system properties:
key meaning
java.home Java installation directory
java.class.path Java classpath
user.name User account name
user.home User home directory
user.dir User's current working directory
To read a system property from within an applet, simply invoke System.getProperty(key) on the property you are interested in.
For example,
String s = System.getProperty("os.name");
How do I hide system properties that applets are allowed to read by default?
There's no way to hide the above ten system properties from applets loaded into a Java-enabled browser. The reason is that the browsers don't consult any external files as part their Java configuration, as a security precaution, including the ~/.hotjava/properties file.
From the appletviewer, you can prevent applets from finding out anything about your system by redefining the property in your ~/.hotjava/properties file. For example, to hide the name of the operating system that you are using, add this line to your ~/.hotjava/properties file: os.name=null
How can I allow applets to read system properties that they aren't allowed to read by default?
There's no way to allow an applet loaded into a Java-enabled browser to read system properties that they aren't allowed to read by default.
To allow applets loaded into the appletviewer to read the property named by key, add the property key.applet=true to your ~/.hotjava/property file. For example, to allow applets to record your user name, add this line to your ~/.hotjava/properties file:
user.name.applet=true
How can an applet open a network connection to a computer on the internet?
Applets are not allowed to open network connections to any computer, except for the host that provided the .class files. This is either the host where the html page came from, or the host specified in the codebase parameter in the applet tag, with codebase taking precendence.
For example, if you try to do this from an applet that did not originate from the machine foo.com, it will fail with a security exception:
Socket s = new Socket("foo.com", 25, true);
How can an applet open a network connection to its originating host?
Be sure to name the originating host exactly as it was specified when the applet was loaded into the browser.
That is, if you load an HTML page using the URL
http://foo.state.edu/~me/appletPage.html
then your applet will be able to connect to its host only by using the name foo.state.edu. Using the IP address for foo.state.edu won't work, and using a "shorthand" form of the host name, like foo.state instead of foo.state.edu, won't work.
How can an applet maintain persistent state?
There is no explicit support in the JDK applet API for persistent state on the client side. However, an applet can maintain its own persistent state on the server side. That is, it can create files on the server side and read files from the server side.
Can an applet start another program on the client?
No, applets loaded over the net are not allowed to start programs on the client. That is, an applet that you visit can't start some rogue process on your PC. In UNIX terminology, applets are not allowed to exec or fork processes. In particular, this means that applets can't invoke some program to list the contents of your file system, and it means that applets can't invoke System.exit() in an attempt to kill your web browser. Applets are also not allowed to manipulate threads outside the applet's own thread group.
What features of the Java language help people build secure applets?
Java programs do not use pointers explicitly. Objects are accessed by getting a handle to the object. Effectively, this is like getting a pointer to an object, but Java does not allow the equivalent of pointer arithmetic on object handles. Object handles cannot be modified in any way by the Java applet or application.
C and C++ programmers are used to manipulating pointers to implement strings and to implement arrays. Java has high-level support for both strings and arrays, so programmers don't need to resort to pointer arithmetic in order to use those data structures.
Arrays are bounds-checked at runtime. Using a negative index causes a runtime exception, and using an index that is larger than the size of the array causes a runtime exception. Once an array object is created, its length never changes.
Strings in Java are immutable. A string is zero or more characters enclosed in double quotes, and it's an instance of the String class. Using immutable strings can help prevent common runtime errors that could be exploited by hostile applets.
The Java compiler checks that all type casts are legal. Java is a strongly typed language, unlike C or C++, and objects cannot be cast to a subclass without an explicit runtime check.
The final modifier can be used when initializing a variable, to prevent runtime modification of that variable. The compiler catches attempts to modify final variables.
Before a method is invoked on an object, the compiler checks that the object is the correct type for that method. For example,
invoking t.currentThread() when t is not a Thread object causes a compile time error.
Java provides four access modifiers for methods and variables defined within classes and makes sure that these access barriers are not violated.
public: a public method is accessible anywhere the class name is accessible
protected: a protected method is accessible by a child of a class as long as it is trying to access fields in a similarly typed class.
For example,
class Parent { protected int x; }
class Child extends Parent { ... }
The class Child can access the field "x" only on objects that are of type Child (or a subset of Child.)
private: a private method is accessible only within its defining class
default: if no modifier is specified, then by default, a method is accessible only within its defining package
For example, programmers can choose to implement sensitive functions as private methods. The compiler and the runtime checks ensure that no objects outside the class can invoke the private methods.
What is the difference between applets loaded over the net and applets loaded via the file system?
There are two different ways that applets are loaded by a Java system. The way an applet enters the system affects what it is allowed to do.
If an applet is loaded over the net, then it is loaded by the applet class loader, and is subject to the restrictions enforced by the applet security manager.
If an applet resides on the client's local disk, and in a directory that is on the client's CLASSPATH, then it is loaded by the file system loader. The most important differences are
applets loaded via the file system are allowed to read and write files
applets loaded via the file system are allowed to load libraries on the client
applets loaded via the file system are allowed to exec processes
applets loaded via the file system are allowed to exit the virtual machine
applets loaded via the file system are not passed through the byte code verifier
Java-enabled browsers use the applet class loader to load applets specified with file: URLs. So, the restrictions and protections that accrue from the class loader and its associated security manager are now in effect for applets loaded via file: URLs.
This means that if you specify the URL like so:
Location: file:/home/me/public_html/something.html
and the file something.html contains an applet, the browser loads it using its applet class loader.
What's the applet class loader, and what does it buy me?
Applets loaded over the net are loaded by the applet class loader. For example, the appletviewer's applet class loader is implemented by the class sun.applet.AppletClassLoader.
The class loader enforces the Java name space hierarchy. The class loader guarantees that a unique namespace exists for classes that come from the local file system, and that a unique namespace exists for each network source. When a browser loads an applet over the net, that applet's classes are placed in a private namespace associated with the applet's origin. Thus, applets loaded from different network sources are partitioned from each other.
Also, classes loaded by the class loader are passed through the verifier. The verifier checks that the class file conforms to the Java language specification - it doesn't assume that the class file was produced by a "friendly" or "trusted" compiler. On the contrary, it checks the class file for purposeful violations of the language type rules and name space restrictions. The verifier ensures that
There are no stack overflows or underflows.
All register accesses and stores are valid.
The parameters to all bytecode instructions are correct.
There is no illegal data conversion.
The verifier accomplishes that by doing a data-flow analysis of the bytecode instruction stream, along with checking the class file format, object signatures, and special analysis of finally clauses that are used for Java exception handling.
Details on the verifier's design and implementation were presented in a paper by Frank Yellin at the December 1995 WWW conference in Boston.
A web browser uses only one class loader, which is established at start-up. Thereafter, the system class loader cannot be extended, overloaded, overridden or replaced. Applets cannot create or reference their own class loader.
What's the applet security manager, and what does it buy me?
The applet security manager is the Java mechanism for enforcing the applet restrictions described above. The appletviewer's applet security manager is implemented by sun.applet.AppletSecurity.
A browser may only have one security manager. The security manager is established at startup, and it cannot thereafter be replaced, overloaded, overridden, or extended. Applets cannot create or reference their own security manager.
Is there a summary of applet capabilities?
The following table is not an exhaustive list of applet capabilities. It's meant to answer the questions we hear most often about what applets can and cannot do.
Key:
NN: Netscape Navigator 4.x, loading unsigned applets over the Net
NL: Netscape Navigator 4.x, loading unsigned applets from the Local file system
AN: Appletviewer, JDK 1.x, loading applets over the Net
AL: Appletviewer, JDK 1.x, loading applets from the Local file system
JS: Java Standalone applications
Stricter ------------------------> Less strict
NN NL AN AL JS
read file in /home/me, no no no yes yes
acl.read=null
read file in /home/me, no no yes yes yes
acl.read=/home/me
write file in /tmp, no no no yes yes
acl.write=null
write file in /tmp, no no yes yes yes
acl.write=/tmp
get file info, no no no yes yes
acl.read=null
acl.write=null
get file info, no no yes yes yes
acl.read=/home/me
acl.write=/tmp
delete file, no no no no yes
using File.delete()
delete file, no no no yes yes
using exec /usr/bin/rm
read the user.name no yes no yes yes
property
connect to port no no no yes yes
on client
connect to port no no no yes yes
on 3rd host
load library no yes no yes yes
exit(-1) no no no yes yes
create a popup no yes no yes yes
window without
a warning
If other languages are compiled to Java bytecodes, how does that affect the applet security model?
The verifier is independent of Sun's reference implementation of the Java compiler and the high-level specification of the Java language. It verifies bytecodes generated by other Java compilers. It also verifies bytecodes generated by compiling other languages into the bytecode format. Bytecodes imported over the net that pass the verifier can be trusted to run on the Java virtual machine. In order to pass the verifier, bytecodes have to conform to the strict typing, the object signatures, the class file format, and the predictability of the runtime stack that are all defined by the Java language implementation
Web Services Essentials
Introduction to Web Services
Web services, in the general meaning of the term, are services offered on the Web. In a typical Web services scenario, a business application uses the SOAP protocol over HTTP to send a request to a service at an URL. The service receives the request, processes it, and returns a response. An often-cited example of a Web service is that of a stock quote service, in which the request asks for the current price of a specified stock and the response returns the stock price. This is one of the simplest forms of a Web service: The request is fulfilled almost immediately; the request and response are parts of the same method call.
Another example could be a service that maps out an efficient route for the delivery of goods. In this case, a business sends a request with the delivery destinations, which the service then processes to determine the most cost-effective delivery route. The time it takes to return the response depends on the complexity of the routing; therefore, the response will probably be sent as an operation separate from the request.
Web services and their consumers are typically businesses, making Web services predominantly business-to-business (B-to-B) transactions. An enterprise can be the Web service provider and also the consumer of other Web services. For example, a wholesale distributor of spices is in the consumer role when it uses a Web service to check on the availability of vanilla beans and in the provider role when it supplies prospective customers with prices for vanilla beans.
The Role of XML and the Java Platform
Web services depend on the ability of parties to communicate with each other even if they are using different information systems. XML (eXtensible Markup Language), which makes data portable, is a key technology in addressing this need. Enterprises have discovered the benefits of using XML for the integration of data -- both internally for sharing legacy data among departments and externally for sharing data with other enterprises. As a result, XML is increasingly being used for enterprise application integration (EAI) in tightly coupled and loosely coupled systems. Thanks to its ability to integrate data, XML has become the underpinning for Web-related computing.
Overview of the Java APIs for XML (JAX APIs)
You can use the JAX APIs to develop Web applications entirely in the Java programming language. The APIs fall into two broad categories: those that deal directly with processing XML documents and those that deal with procedures.
Document-oriented
- Java API for XML Processing (JAXP) -- Processes XML documents with parsers.
- Java Architecture for XML Binding (JAXB) -- Processes XML documents with schema-derived JavaBeans component classes.
Procedure-oriented
- Java API for XML-based RPC (JAX-RPC) -- Sends SOAP method calls to remote parties over the Internet and receives the results.
- Java API for XML Messaging (SAAJ) -- Sends SOAP messages over the Internet in a standard way.
- Java API for XML Registries (JAXR) -- Provides a standard way to access business registries and share information.
Perhaps the most important feature of JAX APIs is that they all support industry standards, ensuring interoperability.
Web services, in the general meaning of the term, are services offered on the Web. In a typical Web services scenario, a business application uses the SOAP protocol over HTTP to send a request to a service at an URL. The service receives the request, processes it, and returns a response. An often-cited example of a Web service is that of a stock quote service, in which the request asks for the current price of a specified stock and the response returns the stock price. This is one of the simplest forms of a Web service: The request is fulfilled almost immediately; the request and response are parts of the same method call.
Another example could be a service that maps out an efficient route for the delivery of goods. In this case, a business sends a request with the delivery destinations, which the service then processes to determine the most cost-effective delivery route. The time it takes to return the response depends on the complexity of the routing; therefore, the response will probably be sent as an operation separate from the request.
Web services and their consumers are typically businesses, making Web services predominantly business-to-business (B-to-B) transactions. An enterprise can be the Web service provider and also the consumer of other Web services. For example, a wholesale distributor of spices is in the consumer role when it uses a Web service to check on the availability of vanilla beans and in the provider role when it supplies prospective customers with prices for vanilla beans.
The Role of XML and the Java Platform
Web services depend on the ability of parties to communicate with each other even if they are using different information systems. XML (eXtensible Markup Language), which makes data portable, is a key technology in addressing this need. Enterprises have discovered the benefits of using XML for the integration of data -- both internally for sharing legacy data among departments and externally for sharing data with other enterprises. As a result, XML is increasingly being used for enterprise application integration (EAI) in tightly coupled and loosely coupled systems. Thanks to its ability to integrate data, XML has become the underpinning for Web-related computing.
Overview of the Java APIs for XML (JAX APIs)
You can use the JAX APIs to develop Web applications entirely in the Java programming language. The APIs fall into two broad categories: those that deal directly with processing XML documents and those that deal with procedures.
Document-oriented
- Java API for XML Processing (JAXP) -- Processes XML documents with parsers.
- Java Architecture for XML Binding (JAXB) -- Processes XML documents with schema-derived JavaBeans component classes.
Procedure-oriented
- Java API for XML-based RPC (JAX-RPC) -- Sends SOAP method calls to remote parties over the Internet and receives the results.
- Java API for XML Messaging (SAAJ) -- Sends SOAP messages over the Internet in a standard way.
- Java API for XML Registries (JAXR) -- Provides a standard way to access business registries and share information.
Perhaps the most important feature of JAX APIs is that they all support industry standards, ensuring interoperability.
Applet Security
What are applets prevented from doing?
In general, applets loaded over the net are prevented from reading and writing files on the client file system, and from making network connections except to the originating host.
In addition, applets loaded over the net are prevented from starting other programs on the client. Applets loaded over the net are also not allowed to load libraries, or to define native method calls. If an applet could define native method calls, that would give the applet direct access to the underlying computer.
There are other specific capabilities denied to applets loaded over the net, but most of the applet security policy is described by those two paragraphs above. Read on for the gory details.
Can applets read or write files?
In Java-enabled browsers, untrusted applets cannot read or write files at all. By default, downloaded applets are considered untrusted. There are two ways for an applet to be considered trusted:
The applet is installed on the local hard disk, in a directory on the CLASSPATH used by the program that you are using to run the applet. Usually, this is a Java-enabled browser, but it could be the appletviewer, or other Java programs that know how to load applets.
The applet is signed by an identity marked as trusted in your identity database. For more information on signed applets, refer to an example of using signed applets, and to a short description on using javakey.
Sun's appletviewer allows applets to read files that reside in directories on the access control lists.
If the file is not on the client's access control list, then applets cannot access the file in any way. Specifically, applets cannot
check for the existence of the file
read the file
write the file
rename the file
create a directory on the client file system
list the files in this file (as if it were a directory)
check the file's type
check the timestamp when the file was last modified
check the file's size
How do I let an applet read a file?
Applets loaded into a Java-enabled browser can't read files.
Sun's appletviewer allows applets to read files that are named on the access control list for reading. The access control list for reading is null by default, in the JDK. You can allow applets to read directories or files by naming them in the acl.read property in your ~/.hotjava/properties file.
Note: The "~" (tilde) symbol is used on UNIX systems to refer to your home directory. If you install a web browser on your F:\ drive on your PC, and create a top-level directory named .hotjava, then your properties file is found in F:\.hotjava\properties.
For example, to allow any files in the directory home/me to be read by applets loaded into the appletviewer, add this line to your ~/.hotjava/properties file.
acl.read=/home/me
You can specify one file to be read: acl.read=/home/me/somedir/somefile
Use ":" to separate entries: acl.read=/home/foo:/home/me/somedir/somefile
Allowing an applet to read a directory means that it can read all the files in that directory, including any files in any subdirectories that might be hanging off that directory.
How do I let an applet write a file?
Applets loaded into a Java-enabled browser can't write files.
Sun's appletviewer allows applets to write files that are named on the access control list for writing. The access control list for writing is empty by default.
You can allow applets to write to your /tmp directory by setting the acl.write property in your ~/.hotjava/properties file: acl.write=/tmp
You can allow applets to write to a particular file by naming it explicitly:
acl.write=/home/me/somedir/somefile
Use : to separate entries: acl.write=/tmp:/home/me/somedir/somefile
Bear in mind that if you open up your file system for writing by applets, there is no way to limit the amount of disk space an applet might use.
What system properties can be read by applets, and how?
In both Java-enabled browsers and the appletviewer, applets can read these system properties by invoking System.getProperty(String key):
key meaning
java.version Java version number
java.vendor Java vendor-specific string
java.vendor.url Java vendor URL
java.class.version Java class version number
os.name Operating system name
os.arch Operating system architecture
os.version Operating system version
file.separator File separator (eg, "/")
path.separator Path separator (eg, ":")
line.separator Line separator
Applets are prevented from reading these system properties:
key meaning
java.home Java installation directory
java.class.path Java classpath
user.name User account name
user.home User home directory
user.dir User's current working directory
To read a system property from within an applet, simply invoke System.getProperty(key) on the property you are interested in.
For example,
String s = System.getProperty("os.name");
How do I hide system properties that applets are allowed to read by default?
There's no way to hide the above ten system properties from applets loaded into a Java-enabled browser. The reason is that the browsers don't consult any external files as part their Java configuration, as a security precaution, including the ~/.hotjava/properties file.
From the appletviewer, you can prevent applets from finding out anything about your system by redefining the property in your ~/.hotjava/properties file. For example, to hide the name of the operating system that you are using, add this line to your ~/.hotjava/properties file: os.name=null
How can I allow applets to read system properties that they aren't allowed to read by default?
There's no way to allow an applet loaded into a Java-enabled browser to read system properties that they aren't allowed to read by default.
To allow applets loaded into the appletviewer to read the property named by key, add the property key.applet=true to your ~/.hotjava/property file. For example, to allow applets to record your user name, add this line to your ~/.hotjava/properties file:
user.name.applet=true
How can an applet open a network connection to a computer on the internet?
Applets are not allowed to open network connections to any computer, except for the host that provided the .class files. This is either the host where the html page came from, or the host specified in the codebase parameter in the applet tag, with codebase taking precendence.
For example, if you try to do this from an applet that did not originate from the machine foo.com, it will fail with a security exception:
Socket s = new Socket("foo.com", 25, true);
How can an applet open a network connection to its originating host?
Be sure to name the originating host exactly as it was specified when the applet was loaded into the browser.
That is, if you load an HTML page using the URL
http://foo.state.edu/~me/appletPage.html
then your applet will be able to connect to its host only by using the name foo.state.edu. Using the IP address for foo.state.edu won't work, and using a "shorthand" form of the host name, like foo.state instead of foo.state.edu, won't work.
How can an applet maintain persistent state?
There is no explicit support in the JDK applet API for persistent state on the client side. However, an applet can maintain its own persistent state on the server side. That is, it can create files on the server side and read files from the server side.
Can an applet start another program on the client?
No, applets loaded over the net are not allowed to start programs on the client. That is, an applet that you visit can't start some rogue process on your PC. In UNIX terminology, applets are not allowed to exec or fork processes. In particular, this means that applets can't invoke some program to list the contents of your file system, and it means that applets can't invoke System.exit() in an attempt to kill your web browser. Applets are also not allowed to manipulate threads outside the applet's own thread group.
What features of the Java language help people build secure applets?
Java programs do not use pointers explicitly. Objects are accessed by getting a handle to the object. Effectively, this is like getting a pointer to an object, but Java does not allow the equivalent of pointer arithmetic on object handles. Object handles cannot be modified in any way by the Java applet or application.
C and C++ programmers are used to manipulating pointers to implement strings and to implement arrays. Java has high-level support for both strings and arrays, so programmers don't need to resort to pointer arithmetic in order to use those data structures.
Arrays are bounds-checked at runtime. Using a negative index causes a runtime exception, and using an index that is larger than the size of the array causes a runtime exception. Once an array object is created, its length never changes.
Strings in Java are immutable. A string is zero or more characters enclosed in double quotes, and it's an instance of the String class. Using immutable strings can help prevent common runtime errors that could be exploited by hostile applets.
The Java compiler checks that all type casts are legal. Java is a strongly typed language, unlike C or C++, and objects cannot be cast to a subclass without an explicit runtime check.
The final modifier can be used when initializing a variable, to prevent runtime modification of that variable. The compiler catches attempts to modify final variables.
Before a method is invoked on an object, the compiler checks that the object is the correct type for that method. For example,
invoking t.currentThread() when t is not a Thread object causes a compile time error.
Java provides four access modifiers for methods and variables defined within classes and makes sure that these access barriers are not violated.
public: a public method is accessible anywhere the class name is accessible
protected: a protected method is accessible by a child of a class as long as it is trying to access fields in a similarly typed class.
For example,
class Parent { protected int x; }
class Child extends Parent { ... }
The class Child can access the field "x" only on objects that are of type Child (or a subset of Child.)
private: a private method is accessible only within its defining class
default: if no modifier is specified, then by default, a method is accessible only within its defining package
For example, programmers can choose to implement sensitive functions as private methods. The compiler and the runtime checks ensure that no objects outside the class can invoke the private methods.
What is the difference between applets loaded over the net and applets loaded via the file system?
There are two different ways that applets are loaded by a Java system. The way an applet enters the system affects what it is allowed to do.
If an applet is loaded over the net, then it is loaded by the applet class loader, and is subject to the restrictions enforced by the applet security manager.
If an applet resides on the client's local disk, and in a directory that is on the client's CLASSPATH, then it is loaded by the file system loader. The most important differences are
applets loaded via the file system are allowed to read and write files
applets loaded via the file system are allowed to load libraries on the client
applets loaded via the file system are allowed to exec processes
applets loaded via the file system are allowed to exit the virtual machine
applets loaded via the file system are not passed through the byte code verifier
Java-enabled browsers use the applet class loader to load applets specified with file: URLs. So, the restrictions and protections that accrue from the class loader and its associated security manager are now in effect for applets loaded via file: URLs.
This means that if you specify the URL like so:
Location: file:/home/me/public_html/something.html
and the file something.html contains an applet, the browser loads it using its applet class loader.
What's the applet class loader, and what does it buy me?
Applets loaded over the net are loaded by the applet class loader. For example, the appletviewer's applet class loader is implemented by the class sun.applet.AppletClassLoader.
The class loader enforces the Java name space hierarchy. The class loader guarantees that a unique namespace exists for classes that come from the local file system, and that a unique namespace exists for each network source. When a browser loads an applet over the net, that applet's classes are placed in a private namespace associated with the applet's origin. Thus, applets loaded from different network sources are partitioned from each other.
Also, classes loaded by the class loader are passed through the verifier. The verifier checks that the class file conforms to the Java language specification - it doesn't assume that the class file was produced by a "friendly" or "trusted" compiler. On the contrary, it checks the class file for purposeful violations of the language type rules and name space restrictions. The verifier ensures that
There are no stack overflows or underflows.
All register accesses and stores are valid.
The parameters to all bytecode instructions are correct.
There is no illegal data conversion.
The verifier accomplishes that by doing a data-flow analysis of the bytecode instruction stream, along with checking the class file format, object signatures, and special analysis of finally clauses that are used for Java exception handling.
Details on the verifier's design and implementation were presented in a paper by Frank Yellin at the December 1995 WWW conference in Boston.
A web browser uses only one class loader, which is established at start-up. Thereafter, the system class loader cannot be extended, overloaded, overridden or replaced. Applets cannot create or reference their own class loader.
What's the applet security manager, and what does it buy me?
The applet security manager is the Java mechanism for enforcing the applet restrictions described above. The appletviewer's applet security manager is implemented by sun.applet.AppletSecurity.
A browser may only have one security manager. The security manager is established at startup, and it cannot thereafter be replaced, overloaded, overridden, or extended. Applets cannot create or reference their own security manager.
Is there a summary of applet capabilities?
The following table is not an exhaustive list of applet capabilities. It's meant to answer the questions we hear most often about what applets can and cannot do.
Key:
NN: Netscape Navigator 4.x, loading unsigned applets over the Net
NL: Netscape Navigator 4.x, loading unsigned applets from the Local file system
AN: Appletviewer, JDK 1.x, loading applets over the Net
AL: Appletviewer, JDK 1.x, loading applets from the Local file system
JS: Java Standalone applications
Stricter ------------------------> Less strict
NN NL AN AL JS
read file in /home/me, no no no yes yes
acl.read=null
read file in /home/me, no no yes yes yes
acl.read=/home/me
write file in /tmp, no no no yes yes
acl.write=null
write file in /tmp, no no yes yes yes
acl.write=/tmp
get file info, no no no yes yes
acl.read=null
acl.write=null
get file info, no no yes yes yes
acl.read=/home/me
acl.write=/tmp
delete file, no no no no yes
using File.delete()
delete file, no no no yes yes
using exec /usr/bin/rm
read the user.name no yes no yes yes
property
connect to port no no no yes yes
on client
connect to port no no no yes yes
on 3rd host
load library no yes no yes yes
exit(-1) no no no yes yes
create a popup no yes no yes yes
window without
a warning
If other languages are compiled to Java bytecodes, how does that affect the applet security model?
The verifier is independent of Sun's reference implementation of the Java compiler and the high-level specification of the Java language. It verifies bytecodes generated by other Java compilers. It also verifies bytecodes generated by compiling other languages into the bytecode format. Bytecodes imported over the net that pass the verifier can be trusted to run on the Java virtual machine. In order to pass the verifier, bytecodes have to conform to the strict typing, the object signatures, the class file format, and the predictability of the runtime stack that are all defined by the Java language implementation
In general, applets loaded over the net are prevented from reading and writing files on the client file system, and from making network connections except to the originating host.
In addition, applets loaded over the net are prevented from starting other programs on the client. Applets loaded over the net are also not allowed to load libraries, or to define native method calls. If an applet could define native method calls, that would give the applet direct access to the underlying computer.
There are other specific capabilities denied to applets loaded over the net, but most of the applet security policy is described by those two paragraphs above. Read on for the gory details.
Can applets read or write files?
In Java-enabled browsers, untrusted applets cannot read or write files at all. By default, downloaded applets are considered untrusted. There are two ways for an applet to be considered trusted:
The applet is installed on the local hard disk, in a directory on the CLASSPATH used by the program that you are using to run the applet. Usually, this is a Java-enabled browser, but it could be the appletviewer, or other Java programs that know how to load applets.
The applet is signed by an identity marked as trusted in your identity database. For more information on signed applets, refer to an example of using signed applets, and to a short description on using javakey.
Sun's appletviewer allows applets to read files that reside in directories on the access control lists.
If the file is not on the client's access control list, then applets cannot access the file in any way. Specifically, applets cannot
check for the existence of the file
read the file
write the file
rename the file
create a directory on the client file system
list the files in this file (as if it were a directory)
check the file's type
check the timestamp when the file was last modified
check the file's size
How do I let an applet read a file?
Applets loaded into a Java-enabled browser can't read files.
Sun's appletviewer allows applets to read files that are named on the access control list for reading. The access control list for reading is null by default, in the JDK. You can allow applets to read directories or files by naming them in the acl.read property in your ~/.hotjava/properties file.
Note: The "~" (tilde) symbol is used on UNIX systems to refer to your home directory. If you install a web browser on your F:\ drive on your PC, and create a top-level directory named .hotjava, then your properties file is found in F:\.hotjava\properties.
For example, to allow any files in the directory home/me to be read by applets loaded into the appletviewer, add this line to your ~/.hotjava/properties file.
acl.read=/home/me
You can specify one file to be read: acl.read=/home/me/somedir/somefile
Use ":" to separate entries: acl.read=/home/foo:/home/me/somedir/somefile
Allowing an applet to read a directory means that it can read all the files in that directory, including any files in any subdirectories that might be hanging off that directory.
How do I let an applet write a file?
Applets loaded into a Java-enabled browser can't write files.
Sun's appletviewer allows applets to write files that are named on the access control list for writing. The access control list for writing is empty by default.
You can allow applets to write to your /tmp directory by setting the acl.write property in your ~/.hotjava/properties file: acl.write=/tmp
You can allow applets to write to a particular file by naming it explicitly:
acl.write=/home/me/somedir/somefile
Use : to separate entries: acl.write=/tmp:/home/me/somedir/somefile
Bear in mind that if you open up your file system for writing by applets, there is no way to limit the amount of disk space an applet might use.
What system properties can be read by applets, and how?
In both Java-enabled browsers and the appletviewer, applets can read these system properties by invoking System.getProperty(String key):
key meaning
java.version Java version number
java.vendor Java vendor-specific string
java.vendor.url Java vendor URL
java.class.version Java class version number
os.name Operating system name
os.arch Operating system architecture
os.version Operating system version
file.separator File separator (eg, "/")
path.separator Path separator (eg, ":")
line.separator Line separator
Applets are prevented from reading these system properties:
key meaning
java.home Java installation directory
java.class.path Java classpath
user.name User account name
user.home User home directory
user.dir User's current working directory
To read a system property from within an applet, simply invoke System.getProperty(key) on the property you are interested in.
For example,
String s = System.getProperty("os.name");
How do I hide system properties that applets are allowed to read by default?
There's no way to hide the above ten system properties from applets loaded into a Java-enabled browser. The reason is that the browsers don't consult any external files as part their Java configuration, as a security precaution, including the ~/.hotjava/properties file.
From the appletviewer, you can prevent applets from finding out anything about your system by redefining the property in your ~/.hotjava/properties file. For example, to hide the name of the operating system that you are using, add this line to your ~/.hotjava/properties file: os.name=null
How can I allow applets to read system properties that they aren't allowed to read by default?
There's no way to allow an applet loaded into a Java-enabled browser to read system properties that they aren't allowed to read by default.
To allow applets loaded into the appletviewer to read the property named by key, add the property key.applet=true to your ~/.hotjava/property file. For example, to allow applets to record your user name, add this line to your ~/.hotjava/properties file:
user.name.applet=true
How can an applet open a network connection to a computer on the internet?
Applets are not allowed to open network connections to any computer, except for the host that provided the .class files. This is either the host where the html page came from, or the host specified in the codebase parameter in the applet tag, with codebase taking precendence.
For example, if you try to do this from an applet that did not originate from the machine foo.com, it will fail with a security exception:
Socket s = new Socket("foo.com", 25, true);
How can an applet open a network connection to its originating host?
Be sure to name the originating host exactly as it was specified when the applet was loaded into the browser.
That is, if you load an HTML page using the URL
http://foo.state.edu/~me/appletPage.html
then your applet will be able to connect to its host only by using the name foo.state.edu. Using the IP address for foo.state.edu won't work, and using a "shorthand" form of the host name, like foo.state instead of foo.state.edu, won't work.
How can an applet maintain persistent state?
There is no explicit support in the JDK applet API for persistent state on the client side. However, an applet can maintain its own persistent state on the server side. That is, it can create files on the server side and read files from the server side.
Can an applet start another program on the client?
No, applets loaded over the net are not allowed to start programs on the client. That is, an applet that you visit can't start some rogue process on your PC. In UNIX terminology, applets are not allowed to exec or fork processes. In particular, this means that applets can't invoke some program to list the contents of your file system, and it means that applets can't invoke System.exit() in an attempt to kill your web browser. Applets are also not allowed to manipulate threads outside the applet's own thread group.
What features of the Java language help people build secure applets?
Java programs do not use pointers explicitly. Objects are accessed by getting a handle to the object. Effectively, this is like getting a pointer to an object, but Java does not allow the equivalent of pointer arithmetic on object handles. Object handles cannot be modified in any way by the Java applet or application.
C and C++ programmers are used to manipulating pointers to implement strings and to implement arrays. Java has high-level support for both strings and arrays, so programmers don't need to resort to pointer arithmetic in order to use those data structures.
Arrays are bounds-checked at runtime. Using a negative index causes a runtime exception, and using an index that is larger than the size of the array causes a runtime exception. Once an array object is created, its length never changes.
Strings in Java are immutable. A string is zero or more characters enclosed in double quotes, and it's an instance of the String class. Using immutable strings can help prevent common runtime errors that could be exploited by hostile applets.
The Java compiler checks that all type casts are legal. Java is a strongly typed language, unlike C or C++, and objects cannot be cast to a subclass without an explicit runtime check.
The final modifier can be used when initializing a variable, to prevent runtime modification of that variable. The compiler catches attempts to modify final variables.
Before a method is invoked on an object, the compiler checks that the object is the correct type for that method. For example,
invoking t.currentThread() when t is not a Thread object causes a compile time error.
Java provides four access modifiers for methods and variables defined within classes and makes sure that these access barriers are not violated.
public: a public method is accessible anywhere the class name is accessible
protected: a protected method is accessible by a child of a class as long as it is trying to access fields in a similarly typed class.
For example,
class Parent { protected int x; }
class Child extends Parent { ... }
The class Child can access the field "x" only on objects that are of type Child (or a subset of Child.)
private: a private method is accessible only within its defining class
default: if no modifier is specified, then by default, a method is accessible only within its defining package
For example, programmers can choose to implement sensitive functions as private methods. The compiler and the runtime checks ensure that no objects outside the class can invoke the private methods.
What is the difference between applets loaded over the net and applets loaded via the file system?
There are two different ways that applets are loaded by a Java system. The way an applet enters the system affects what it is allowed to do.
If an applet is loaded over the net, then it is loaded by the applet class loader, and is subject to the restrictions enforced by the applet security manager.
If an applet resides on the client's local disk, and in a directory that is on the client's CLASSPATH, then it is loaded by the file system loader. The most important differences are
applets loaded via the file system are allowed to read and write files
applets loaded via the file system are allowed to load libraries on the client
applets loaded via the file system are allowed to exec processes
applets loaded via the file system are allowed to exit the virtual machine
applets loaded via the file system are not passed through the byte code verifier
Java-enabled browsers use the applet class loader to load applets specified with file: URLs. So, the restrictions and protections that accrue from the class loader and its associated security manager are now in effect for applets loaded via file: URLs.
This means that if you specify the URL like so:
Location: file:/home/me/public_html/something.html
and the file something.html contains an applet, the browser loads it using its applet class loader.
What's the applet class loader, and what does it buy me?
Applets loaded over the net are loaded by the applet class loader. For example, the appletviewer's applet class loader is implemented by the class sun.applet.AppletClassLoader.
The class loader enforces the Java name space hierarchy. The class loader guarantees that a unique namespace exists for classes that come from the local file system, and that a unique namespace exists for each network source. When a browser loads an applet over the net, that applet's classes are placed in a private namespace associated with the applet's origin. Thus, applets loaded from different network sources are partitioned from each other.
Also, classes loaded by the class loader are passed through the verifier. The verifier checks that the class file conforms to the Java language specification - it doesn't assume that the class file was produced by a "friendly" or "trusted" compiler. On the contrary, it checks the class file for purposeful violations of the language type rules and name space restrictions. The verifier ensures that
There are no stack overflows or underflows.
All register accesses and stores are valid.
The parameters to all bytecode instructions are correct.
There is no illegal data conversion.
The verifier accomplishes that by doing a data-flow analysis of the bytecode instruction stream, along with checking the class file format, object signatures, and special analysis of finally clauses that are used for Java exception handling.
Details on the verifier's design and implementation were presented in a paper by Frank Yellin at the December 1995 WWW conference in Boston.
A web browser uses only one class loader, which is established at start-up. Thereafter, the system class loader cannot be extended, overloaded, overridden or replaced. Applets cannot create or reference their own class loader.
What's the applet security manager, and what does it buy me?
The applet security manager is the Java mechanism for enforcing the applet restrictions described above. The appletviewer's applet security manager is implemented by sun.applet.AppletSecurity.
A browser may only have one security manager. The security manager is established at startup, and it cannot thereafter be replaced, overloaded, overridden, or extended. Applets cannot create or reference their own security manager.
Is there a summary of applet capabilities?
The following table is not an exhaustive list of applet capabilities. It's meant to answer the questions we hear most often about what applets can and cannot do.
Key:
NN: Netscape Navigator 4.x, loading unsigned applets over the Net
NL: Netscape Navigator 4.x, loading unsigned applets from the Local file system
AN: Appletviewer, JDK 1.x, loading applets over the Net
AL: Appletviewer, JDK 1.x, loading applets from the Local file system
JS: Java Standalone applications
Stricter ------------------------> Less strict
NN NL AN AL JS
read file in /home/me, no no no yes yes
acl.read=null
read file in /home/me, no no yes yes yes
acl.read=/home/me
write file in /tmp, no no no yes yes
acl.write=null
write file in /tmp, no no yes yes yes
acl.write=/tmp
get file info, no no no yes yes
acl.read=null
acl.write=null
get file info, no no yes yes yes
acl.read=/home/me
acl.write=/tmp
delete file, no no no no yes
using File.delete()
delete file, no no no yes yes
using exec /usr/bin/rm
read the user.name no yes no yes yes
property
connect to port no no no yes yes
on client
connect to port no no no yes yes
on 3rd host
load library no yes no yes yes
exit(-1) no no no yes yes
create a popup no yes no yes yes
window without
a warning
If other languages are compiled to Java bytecodes, how does that affect the applet security model?
The verifier is independent of Sun's reference implementation of the Java compiler and the high-level specification of the Java language. It verifies bytecodes generated by other Java compilers. It also verifies bytecodes generated by compiling other languages into the bytecode format. Bytecodes imported over the net that pass the verifier can be trusted to run on the Java virtual machine. In order to pass the verifier, bytecodes have to conform to the strict typing, the object signatures, the class file format, and the predictability of the runtime stack that are all defined by the Java language implementation
Java Technology and Web Services
The Web services are Web-based enterprise applications that use open, XML-based standards and transport protocols to exchange data with calling clients. Java 2 Platform, Enterprise Edition (J2EE) provides the APIs and tools you need to create and deploy interoperable Web services and clients.
Java Technology and Web Services is organized into these subcategories:
Java Web Services Developer Pack (Java WSDP)
Java API for XML-Based RPC (JAX-RPC)
Java API for XML Registries (JAXR)
Java API for XML Processing (JAXP)
Java Architecture for XML Binding (JAXB)
SOAP with Attachments API for Java (SAAJ)
XML and Web Services Security
Web Services Overview:
- Extensible Markup Language (XML)
- Web Services/XML APIs
- Java Platform Tools
The Java 2 Platform, Enterprise Edition platform provides the APIs and tools you need to quickly design, develop, test, and deploy Web services and clients that fully interoperate with other Web services and clients running on any platform. This full interoperability is possible because application data is translated "behind-the-scenes" to a standardized XML-based data stream.
A brief overview of XML, APIs, and tools is presented here. See also The J2EE Tutorial for detailed information with examples.
Extensible Markup Language (XML)
Extensible Markup Language (XML) is a cross-platform, extensible, and text-based standard for representing data. When XML data is exchanged between parties, the parties are free to create their own tags to describe the data, set up schemas to specify which tags can be used in a particular kind of XML document, and use XML style sheets to manage the display and handling of the data.
Web Services/XML APIs
It is easy to write Web services and clients with the J2EE XML APIs. All you do is pass parameter data to the method calls and process the data returned, or for document-oriented web services, send documents containing the service data back and forth. No low-level programming is needed. The following list describes the Web services/XML APIs.
The Java API for XML Processing (JAXP) supports the processing of XML documents using Document Object Model (DOM), Simple API for XML Parsing (SAX), and XML Style sheet Language Transformation (XSLT). The JAXP API enables applications to parse and transform XML documents independently of a particular XML processing implementation.
The Java API for XML Registries (JAXR) lets you access business and general-purpose registries over the Web. JAXR supports the ebXML Registry/Repository standards and the UDDI specifications.
The Java API for XML-based RPC (JAX-RPC) uses the SOAP standard and HTTP so client programs can make XML-based remote procedure calls (RPCs) over the Internet. JAX-RPC also supports WSDL so you can import and export WSDL documents. With JAX-RPC and a WSDL, you can easily interoperate with clients and services running on Java-based or non-Java-based platforms such as .NET.
The SOAP with Attachments API for Java (SAAJ) enables you to produce and consume messages conforming to the SOAP 1.1 specification and SOAP with Attachments note.
Java Platform Tools
Web Services/XML works with an array of tools including Integrated Development Environments (IDEs), performance and testing tools, and performance monitoring tools.
Java Technology and Web Services is organized into these subcategories:
Java Web Services Developer Pack (Java WSDP)
Java API for XML-Based RPC (JAX-RPC)
Java API for XML Registries (JAXR)
Java API for XML Processing (JAXP)
Java Architecture for XML Binding (JAXB)
SOAP with Attachments API for Java (SAAJ)
XML and Web Services Security
Web Services Overview:
- Extensible Markup Language (XML)
- Web Services/XML APIs
- Java Platform Tools
The Java 2 Platform, Enterprise Edition platform provides the APIs and tools you need to quickly design, develop, test, and deploy Web services and clients that fully interoperate with other Web services and clients running on any platform. This full interoperability is possible because application data is translated "behind-the-scenes" to a standardized XML-based data stream.
A brief overview of XML, APIs, and tools is presented here. See also The J2EE Tutorial for detailed information with examples.
Extensible Markup Language (XML)
Extensible Markup Language (XML) is a cross-platform, extensible, and text-based standard for representing data. When XML data is exchanged between parties, the parties are free to create their own tags to describe the data, set up schemas to specify which tags can be used in a particular kind of XML document, and use XML style sheets to manage the display and handling of the data.
Web Services/XML APIs
It is easy to write Web services and clients with the J2EE XML APIs. All you do is pass parameter data to the method calls and process the data returned, or for document-oriented web services, send documents containing the service data back and forth. No low-level programming is needed. The following list describes the Web services/XML APIs.
The Java API for XML Processing (JAXP) supports the processing of XML documents using Document Object Model (DOM), Simple API for XML Parsing (SAX), and XML Style sheet Language Transformation (XSLT). The JAXP API enables applications to parse and transform XML documents independently of a particular XML processing implementation.
The Java API for XML Registries (JAXR) lets you access business and general-purpose registries over the Web. JAXR supports the ebXML Registry/Repository standards and the UDDI specifications.
The Java API for XML-based RPC (JAX-RPC) uses the SOAP standard and HTTP so client programs can make XML-based remote procedure calls (RPCs) over the Internet. JAX-RPC also supports WSDL so you can import and export WSDL documents. With JAX-RPC and a WSDL, you can easily interoperate with clients and services running on Java-based or non-Java-based platforms such as .NET.
The SOAP with Attachments API for Java (SAAJ) enables you to produce and consume messages conforming to the SOAP 1.1 specification and SOAP with Attachments note.
Java Platform Tools
Web Services/XML works with an array of tools including Integrated Development Environments (IDEs), performance and testing tools, and performance monitoring tools.
Java Technology and Web Services
The Web services are Web-based enterprise applications that use open, XML-based standards and transport protocols to exchange data with calling clients. Java 2 Platform, Enterprise Edition (J2EE) provides the APIs and tools you need to create and deploy interoperable Web services and clients.
Java Technology and Web Services is organized into these subcategories:
Java Web Services Developer Pack (Java WSDP)
Java API for XML-Based RPC (JAX-RPC)
Java API for XML Registries (JAXR)
Java API for XML Processing (JAXP)
Java Architecture for XML Binding (JAXB)
SOAP with Attachments API for Java (SAAJ)
XML and Web Services Security
Web Services Overview:
- Extensible Markup Language (XML)
- Web Services/XML APIs
- Java Platform Tools
The Java 2 Platform, Enterprise Edition platform provides the APIs and tools you need to quickly design, develop, test, and deploy Web services and clients that fully interoperate with other Web services and clients running on any platform. This full interoperability is possible because application data is translated "behind-the-scenes" to a standardized XML-based data stream.
A brief overview of XML, APIs, and tools is presented here. See also The J2EE Tutorial for detailed information with examples.
Extensible Markup Language (XML)
Extensible Markup Language (XML) is a cross-platform, extensible, and text-based standard for representing data. When XML data is exchanged between parties, the parties are free to create their own tags to describe the data, set up schemas to specify which tags can be used in a particular kind of XML document, and use XML style sheets to manage the display and handling of the data.
Web Services/XML APIs
It is easy to write Web services and clients with the J2EE XML APIs. All you do is pass parameter data to the method calls and process the data returned, or for document-oriented web services, send documents containing the service data back and forth. No low-level programming is needed. The following list describes the Web services/XML APIs.
The Java API for XML Processing (JAXP) supports the processing of XML documents using Document Object Model (DOM), Simple API for XML Parsing (SAX), and XML Style sheet Language Transformation (XSLT). The JAXP API enables applications to parse and transform XML documents independently of a particular XML processing implementation.
The Java API for XML Registries (JAXR) lets you access business and general-purpose registries over the Web. JAXR supports the ebXML Registry/Repository standards and the UDDI specifications.
The Java API for XML-based RPC (JAX-RPC) uses the SOAP standard and HTTP so client programs can make XML-based remote procedure calls (RPCs) over the Internet. JAX-RPC also supports WSDL so you can import and export WSDL documents. With JAX-RPC and a WSDL, you can easily interoperate with clients and services running on Java-based or non-Java-based platforms such as .NET.
The SOAP with Attachments API for Java (SAAJ) enables you to produce and consume messages conforming to the SOAP 1.1 specification and SOAP with Attachments note.
Java Platform Tools
Web Services/XML works with an array of tools including Integrated Development Environments (IDEs), performance and testing tools, and performance monitoring tools.
Java Technology and Web Services is organized into these subcategories:
Java Web Services Developer Pack (Java WSDP)
Java API for XML-Based RPC (JAX-RPC)
Java API for XML Registries (JAXR)
Java API for XML Processing (JAXP)
Java Architecture for XML Binding (JAXB)
SOAP with Attachments API for Java (SAAJ)
XML and Web Services Security
Web Services Overview:
- Extensible Markup Language (XML)
- Web Services/XML APIs
- Java Platform Tools
The Java 2 Platform, Enterprise Edition platform provides the APIs and tools you need to quickly design, develop, test, and deploy Web services and clients that fully interoperate with other Web services and clients running on any platform. This full interoperability is possible because application data is translated "behind-the-scenes" to a standardized XML-based data stream.
A brief overview of XML, APIs, and tools is presented here. See also The J2EE Tutorial for detailed information with examples.
Extensible Markup Language (XML)
Extensible Markup Language (XML) is a cross-platform, extensible, and text-based standard for representing data. When XML data is exchanged between parties, the parties are free to create their own tags to describe the data, set up schemas to specify which tags can be used in a particular kind of XML document, and use XML style sheets to manage the display and handling of the data.
Web Services/XML APIs
It is easy to write Web services and clients with the J2EE XML APIs. All you do is pass parameter data to the method calls and process the data returned, or for document-oriented web services, send documents containing the service data back and forth. No low-level programming is needed. The following list describes the Web services/XML APIs.
The Java API for XML Processing (JAXP) supports the processing of XML documents using Document Object Model (DOM), Simple API for XML Parsing (SAX), and XML Style sheet Language Transformation (XSLT). The JAXP API enables applications to parse and transform XML documents independently of a particular XML processing implementation.
The Java API for XML Registries (JAXR) lets you access business and general-purpose registries over the Web. JAXR supports the ebXML Registry/Repository standards and the UDDI specifications.
The Java API for XML-based RPC (JAX-RPC) uses the SOAP standard and HTTP so client programs can make XML-based remote procedure calls (RPCs) over the Internet. JAX-RPC also supports WSDL so you can import and export WSDL documents. With JAX-RPC and a WSDL, you can easily interoperate with clients and services running on Java-based or non-Java-based platforms such as .NET.
The SOAP with Attachments API for Java (SAAJ) enables you to produce and consume messages conforming to the SOAP 1.1 specification and SOAP with Attachments note.
Java Platform Tools
Web Services/XML works with an array of tools including Integrated Development Environments (IDEs), performance and testing tools, and performance monitoring tools.
JDBC - ODBC Questions......
1. What's the JDBC 2.0 API?
The JDBC 2.0 API is the latest update of the JDBC API. It contains many new features, including scrollable result sets and the new SQL:1999 (formerly SQL 3) data types. There are two parts to the JDBC 2.0 API:
the JDBC 2.0 core API (the java.sql package), which is included in the JavaTM 2 SDK, Standard Edition
the JDBC 2.0 Optional Package API (the javax.sql package), which is available separately or as part of the Java 2 SDK, Enterprise Edition
2. Does the JDBC-ODBC Bridge support the new features in the JDBC 2.0 API?
No, the JDBC-ODBC Bridge that is included in the Java 2 Platform initial release does not support the new features in the JDBC 2.0 API. However, Sun and Merant are working to produce a new version of the Bridge that does support the new features. Note that we do not recommend using the Bridge except for experimental purposes or when you have no other driver available.
3. Can the JDBC-ODBC Bridge be used with applets?
Use of the JDBC-ODBC bridge from an untrusted applet running in a browser, such as Netscape Navigator, isn't allowed. The JDBC-ODBC bridge doesn't allow untrusted code to call it for security reasons. This is good because it means that an untrusted applet that is downloaded by the browser can't circumvent Java security by calling ODBC. Remember that ODBC is native code, so once ODBC is called, the Java programming language can't guarantee that a security violation won't occur. On the other hand, Pure Java JDBC drivers work well with applets. They are fully downloadable and do not require any client-side configuration.
Finally, we would like to note that it is possible to use the JDBC-ODBC bridge with applets that will be run in appletviewer since appletviewer assumes that applets are trusted. It is also possible to use the JDBC-ODBC bridge with applets that are run in the HotJavaTM browser (available from Java Software), since HotJava provides an option to turn off applet security. In general, it is dangerous to turn applet security off, but it may be appropriate in certain controlled situations, such as for applets that will only be used in a secure intranet environment. Remember to exercise caution if you choose this option, and use an all-Java JDBC driver whenever possible to avoid security problems.
4. How do I start debugging problems related to the JDBC API?
A good way to find out what JDBC calls are doing is to enable JDBC tracing. The JDBC trace contains a detailed listing of the activity occurring in the system that is related to JDBC operations.
If you use the DriverManager facility to establish your database connection, you use the DriverManager.setLogWriter method to enable tracing of JDBC operations. If you use a DataSource object to get a connection, you use the DataSource.setLogWriter method to enable tracing. (For pooled connections, you use the ConnectionPoolDataSource.setLogWriter method, and for connections that can participate in distributed transactions, you use the XADataSource.setLogWriter method.)
5. How can I use the JDBC API to access a desktop database like Microsoft Access over the network?
Most desktop databases currently require a JDBC solution that uses ODBC underneath. This is because the vendors of these database products haven't implemented all-Java JDBC drivers.
The best approach is to use a commercial JDBC driver that supports ODBC and the database you want to use. See the JDBC drivers page for a list of available JDBC drivers.
The JDBC-ODBC bridge from Sun's Java Software does not provide network access to desktop databases by itself. The JDBC-ODBC bridge loads ODBC as a local DLL, and typical ODBC drivers for desktop databases like Access aren't networked. The JDBC-ODBC bridge can be used together with the RMI-JDBC bridge , however, to access a desktop database like Access over the net. This RMI-JDBC-ODBC solution is free.
6. Does the JDK include the JDBC API and the JDBC-ODBC Bridge?
Yes, the JDK 1.1 and the Java 2 SDK, Standard Edition (formerly known as the JDK 1.2), contain both the JDBC API and the JDBC-ODBC Bridge. The Java 2 SDK, Standard Edition, contains the JDBC 2.0 core API, which is the latest version. It does not include the JDBC 2.0 Optional Package, which is part of the Java 2 SDK, Enterprise Edition, or which you can download separately.
Note that the version of the JDBC API and the JDBC-ODBC Bridge provided for separate download on the JDBC download page are only for use with the JDK 1.0.2.
7. What JDBC technology-enabled drivers are available?
See our web page on JDBC technology-enabled drivers for a current listing.
8. What documentation is available for the JDBC API?
See the JDBC technology home page for links to information about JDBC technology. This page links to information about features and benefits, a list of new features, a section on getting started, online tutorials, a section on driver requirements, and other information in addition to the specifications and javadoc documentation.
9. Are there any ODBC drivers that do not work with the JDBC-ODBC Bridge?
Most ODBC 2.0 drivers should work with the Bridge. Since there is some variation in functionality between ODBC drivers, the functionality of the bridge may be affected. The bridge works with popular PC databases, such as Microsoft Access and FoxPro.
10. Does the JDBC-ODBC Bridge work with Microsoft J++?
No, J++ does not support the JDBC-ODBC bridge since it doesn't implement the Java Native Interface (JNI). Any all-Java JDBC driver should work with J++, however.
11. What causes the "No suitable driver" error?
"No suitable driver" is an error that usually occurs during a call to the DriverManager.getConnection method. The cause can be failing to load the appropriate JDBC drivers before calling the getConnection method, or it can be specifying an invalid JDBC URL--one that isn't recognized by your JDBC driver. Your best bet is to check the documentation for your JDBC driver or contact your JDBC driver vendor if you suspect that the URL you are specifying is not being recognized by your JDBC driver.
In addition, when you are using the JDBC-ODBC Bridge, this error can occur if one or more the the shared libraries needed by the Bridge cannot be loaded. If you think this is the cause, check your configuration to be sure that the shared libraries are accessible to the Bridge.
12. Why isn't the java.sql.DriverManager class being found?
This problem can be caused by running a JDBC applet in a browser that supports the JDK 1.0.2, such as Netscape Navigator 3.0. The JDK 1.0.2 does not contain the JDBC API, so the DriverManager class typically isn't found by the Java virtual machine running in the browser.
Here's a solution that doesn't require any additional configuration of your web clients. Remember that classes in the java.* packages cannot be downloaded by most browsers for security reasons. Because of this, many vendors of all-Java JDBC drivers supply versions of the java.sql.* classes that have been renamed to jdbc.sql.*, along with a version of their driver that uses these modified classes. If you import jdbc.sql.* in your applet code instead of java.sql.*, and add the jdbc.sql.* classes provided by your JDBC driver vendor to your applet's codebase, then all of the JDBC classes needed by the applet can be downloaded by the browser at run time, including the DriverManager class.
This solution will allow your applet to work in any client browser that supports the JDK 1.0.2. Your applet will also work in browsers that support the JDK 1.1, although you may want to switch to the JDK 1.1 classes for performance reasons. Also, keep in mind that the solution outlined here is just an example and that other solutions are possible.
13. Why doesn't calling the method Class.forName load my JDBC driver?
There is a bug in the JDK 1.1.x that can cause the method Class.forName to fail. A workaround is to explicitly call the method DriverManager.registerDriver(new YourDriverClass()). The exact problem in the JDK is a race condition in the class loader that prevents the static section of code in the driver class from executing and registering the driver with the DriverManager.
14. Why do the java.sql and java.math packages fail to download java.* packages? Is there a workaround?
For security reasons, browsers will not download java.* packages. In order to use the JDBC API with browsers that have not been upgraded to JDK1.1 or beyond, we recommend that the java.sql and java.math packages be renamed jdbc.sql and jdbc.math. Most vendors supplying JDBC technology-enabled drivers that are written purely in the Java programming language already provide versions of these renamed packages. When JDK 1.1 support has been added to your browser, you should convert your applets back to the java.* package names.
15. Why is the precision of java.math.BigDecimal limited to 18 digits in the JDK 1.0.2 add-on version of the JDBC API?
In JDK 1.1, java.math.BigInteger is implemented in C. It supports a precision of thousands of digits. The same is true for BigDecigmal.
The version of BigInteger provided with the JDK 1.0.2 add-on version of the JDBC API is a simplified version written in the Java programming language, and it is limited to 18 digits. Because the implementation of BigDecimal is based on BigInteger, it also is limited to this precision.
In the JDBC 2.0 API, you can use a new version of the method ResultSet.getBigDecimal that does not take a scale parameter and returns a BigDecimal with full precision.
16. Can the JDBC API be added to JDK 1.0.2?
Yes. Download the JDBC 1.22 API from the JDBC download page and follow the installation instructions in the release notes.
If you are using any version of the JDK from 1.1 on, the JDBC API is already included, and you should not download the JDBC 1.22 API.
17. How do I retrieve a whole row of data at once, instead of calling an individual ResultSet.getXXX method for each column?
The ResultSet.getXXX methods are the only way to retrieve data from a ResultSet object, which means that you have to make a method call for each column of a row. It is unlikely that this is the cause of a performance problem, however, because it is difficult to see how a column could be fetched without at least the cost of a function call in any scenario. We welcome input from developers on this issue.
18. Why does the ODBC driver manager return 'Data source name not found and no default driver specified Vendor: 0'
This type of error occurs during an attempt to connect to a database with the bridge. First, note that the error is coming from the ODBC driver manager. This indicates that the bridge-which is a normal ODBC client-has successfully called ODBC, so the problem isn't due to native libraries not being present. In this case, it appears that the error is due to the fact that an ODBC DSN (data source name) needs to be configured on the client machine. Developers often forget to do this, thinking that the bridge will magically find the DSN they configured on their remote server machine
19. Are all the required JDBC drivers to establish connectivity to my database part of the JDK?
No. There aren't any JDBC technology-enabled drivers bundled with the JDK 1.1.x or Java 2 Platform releases other than the JDBC-ODBC Bridge. So, developers need to get a driver and install it before they can connect to a database. We are considering bundling JDBC technology- enabled drivers in the future.
20. Is the JDBC-ODBC Bridge multi-threaded?
No. The JDBC-ODBC Bridge does not support concurrent access from different threads. The JDBC-ODBC Bridge uses synchronized methods to serialize all of the calls that it makes to ODBC. Multi-threaded Java programs may use the Bridge, but they won't get the advantages of multi-threading. In addition, deadlocks can occur between locks held in the database and the semaphore used by the Bridge. We are thinking about removing the synchronized methods in the future. They were added originally to make things simple for folks writing Java programs that use a single-threaded ODBC driver.
21. Does the JDBC-ODBC Bridge support multiple concurrent open statements per connection?
No. You can open only one Statement object per connection when you are using the JDBC-ODBC Bridge.
22. Does the JDBC-ODBC Bridge developed by Merant and Sun support result sets that contain Japanese Characters (DBCS)?
Yes, but we haven't tested this ourselves. The version of the Bridge in the Java 2 SDK, Standard Edition, and Java 2 SDK, Enterprise Edition, also supports a new charSet Connection property for specifying the character encoding used by the underlying DBMS.
23. Why can't I invoke the ResultSet methods afterLast and beforeFirst when the method next works?
You are probably using a driver implemented for the JDBC 1.0 API. You need to upgrade to a JDBC 2.0 driver that implements scrollable result sets. Also be sure that your code has created scrollable result sets and that the DBMS you are using supports them.
24. How can I retrieve a String or other object type without creating a new object each time?
Creating and garbage collecting potentially large numbers of objects (millions) unnecessarily can really hurt performance. It may be better to provide a way to retrieve data like strings using the JDBC API without always allocating a new object.
We are studying this issue to see if it is an area in which the JDBC API should be improved. Stay tuned, and please send us any comments you have on this question.
25. There is a method getColumnCount in the JDBC API. Is there a similar method to find the number of rows in a result set?
No, but it is easy to find the number of rows. If you are using a scrollable result set, rs, you can call the methods rs.last and then rs.getRow to find out how many rows rs has. If the result is not scrollable, you can either count the rows by iterating through the result set or get the number of rows by submitting a query with a COUNT column in the SELECT clause.
26. I would like to download the JDBC-ODBC Bridge for the Java 2 SDK, Standard Edition (formerly JDK 1.2). I'm a beginner with the JDBC API, and I would like to start with the Bridge. How do I do it?
The JDBC-ODBC Bridge is bundled with the Java 2 SDK, Standard Edition, so there is no need to download it separately.
27. If I use the JDBC API, do I have to use ODBC underneath?
No, this is just one of many possible solutions. We recommend using a pure Java JDBC technology-enabled driver, type 3 or 4, in order to get all of the benefits of the Java programming language and the JDBC API.
28. Once I have the Java 2 SDK, Standard Edition, from Sun, what else do I need to connect to a database?
You still need to get and install a JDBC technology-enabled driver that supports the database that you are using. There are many drivers available from a variety of sources. You can also try using the JDBC-ODBC Bridge if you have ODBC connectivity set up already. The Bridge comes with the Java 2 SDK, Standard Edition, and Enterprise Edition, and it doesn't require any extra setup itself. The Bridge is a normal ODBC client. Note, however, that you should use the JDBC-ODBC Bridge only for experimental prototyping or when you have no other driver available.
The JDBC 2.0 API is the latest update of the JDBC API. It contains many new features, including scrollable result sets and the new SQL:1999 (formerly SQL 3) data types. There are two parts to the JDBC 2.0 API:
the JDBC 2.0 core API (the java.sql package), which is included in the JavaTM 2 SDK, Standard Edition
the JDBC 2.0 Optional Package API (the javax.sql package), which is available separately or as part of the Java 2 SDK, Enterprise Edition
2. Does the JDBC-ODBC Bridge support the new features in the JDBC 2.0 API?
No, the JDBC-ODBC Bridge that is included in the Java 2 Platform initial release does not support the new features in the JDBC 2.0 API. However, Sun and Merant are working to produce a new version of the Bridge that does support the new features. Note that we do not recommend using the Bridge except for experimental purposes or when you have no other driver available.
3. Can the JDBC-ODBC Bridge be used with applets?
Use of the JDBC-ODBC bridge from an untrusted applet running in a browser, such as Netscape Navigator, isn't allowed. The JDBC-ODBC bridge doesn't allow untrusted code to call it for security reasons. This is good because it means that an untrusted applet that is downloaded by the browser can't circumvent Java security by calling ODBC. Remember that ODBC is native code, so once ODBC is called, the Java programming language can't guarantee that a security violation won't occur. On the other hand, Pure Java JDBC drivers work well with applets. They are fully downloadable and do not require any client-side configuration.
Finally, we would like to note that it is possible to use the JDBC-ODBC bridge with applets that will be run in appletviewer since appletviewer assumes that applets are trusted. It is also possible to use the JDBC-ODBC bridge with applets that are run in the HotJavaTM browser (available from Java Software), since HotJava provides an option to turn off applet security. In general, it is dangerous to turn applet security off, but it may be appropriate in certain controlled situations, such as for applets that will only be used in a secure intranet environment. Remember to exercise caution if you choose this option, and use an all-Java JDBC driver whenever possible to avoid security problems.
4. How do I start debugging problems related to the JDBC API?
A good way to find out what JDBC calls are doing is to enable JDBC tracing. The JDBC trace contains a detailed listing of the activity occurring in the system that is related to JDBC operations.
If you use the DriverManager facility to establish your database connection, you use the DriverManager.setLogWriter method to enable tracing of JDBC operations. If you use a DataSource object to get a connection, you use the DataSource.setLogWriter method to enable tracing. (For pooled connections, you use the ConnectionPoolDataSource.setLogWriter method, and for connections that can participate in distributed transactions, you use the XADataSource.setLogWriter method.)
5. How can I use the JDBC API to access a desktop database like Microsoft Access over the network?
Most desktop databases currently require a JDBC solution that uses ODBC underneath. This is because the vendors of these database products haven't implemented all-Java JDBC drivers.
The best approach is to use a commercial JDBC driver that supports ODBC and the database you want to use. See the JDBC drivers page for a list of available JDBC drivers.
The JDBC-ODBC bridge from Sun's Java Software does not provide network access to desktop databases by itself. The JDBC-ODBC bridge loads ODBC as a local DLL, and typical ODBC drivers for desktop databases like Access aren't networked. The JDBC-ODBC bridge can be used together with the RMI-JDBC bridge , however, to access a desktop database like Access over the net. This RMI-JDBC-ODBC solution is free.
6. Does the JDK include the JDBC API and the JDBC-ODBC Bridge?
Yes, the JDK 1.1 and the Java 2 SDK, Standard Edition (formerly known as the JDK 1.2), contain both the JDBC API and the JDBC-ODBC Bridge. The Java 2 SDK, Standard Edition, contains the JDBC 2.0 core API, which is the latest version. It does not include the JDBC 2.0 Optional Package, which is part of the Java 2 SDK, Enterprise Edition, or which you can download separately.
Note that the version of the JDBC API and the JDBC-ODBC Bridge provided for separate download on the JDBC download page are only for use with the JDK 1.0.2.
7. What JDBC technology-enabled drivers are available?
See our web page on JDBC technology-enabled drivers for a current listing.
8. What documentation is available for the JDBC API?
See the JDBC technology home page for links to information about JDBC technology. This page links to information about features and benefits, a list of new features, a section on getting started, online tutorials, a section on driver requirements, and other information in addition to the specifications and javadoc documentation.
9. Are there any ODBC drivers that do not work with the JDBC-ODBC Bridge?
Most ODBC 2.0 drivers should work with the Bridge. Since there is some variation in functionality between ODBC drivers, the functionality of the bridge may be affected. The bridge works with popular PC databases, such as Microsoft Access and FoxPro.
10. Does the JDBC-ODBC Bridge work with Microsoft J++?
No, J++ does not support the JDBC-ODBC bridge since it doesn't implement the Java Native Interface (JNI). Any all-Java JDBC driver should work with J++, however.
11. What causes the "No suitable driver" error?
"No suitable driver" is an error that usually occurs during a call to the DriverManager.getConnection method. The cause can be failing to load the appropriate JDBC drivers before calling the getConnection method, or it can be specifying an invalid JDBC URL--one that isn't recognized by your JDBC driver. Your best bet is to check the documentation for your JDBC driver or contact your JDBC driver vendor if you suspect that the URL you are specifying is not being recognized by your JDBC driver.
In addition, when you are using the JDBC-ODBC Bridge, this error can occur if one or more the the shared libraries needed by the Bridge cannot be loaded. If you think this is the cause, check your configuration to be sure that the shared libraries are accessible to the Bridge.
12. Why isn't the java.sql.DriverManager class being found?
This problem can be caused by running a JDBC applet in a browser that supports the JDK 1.0.2, such as Netscape Navigator 3.0. The JDK 1.0.2 does not contain the JDBC API, so the DriverManager class typically isn't found by the Java virtual machine running in the browser.
Here's a solution that doesn't require any additional configuration of your web clients. Remember that classes in the java.* packages cannot be downloaded by most browsers for security reasons. Because of this, many vendors of all-Java JDBC drivers supply versions of the java.sql.* classes that have been renamed to jdbc.sql.*, along with a version of their driver that uses these modified classes. If you import jdbc.sql.* in your applet code instead of java.sql.*, and add the jdbc.sql.* classes provided by your JDBC driver vendor to your applet's codebase, then all of the JDBC classes needed by the applet can be downloaded by the browser at run time, including the DriverManager class.
This solution will allow your applet to work in any client browser that supports the JDK 1.0.2. Your applet will also work in browsers that support the JDK 1.1, although you may want to switch to the JDK 1.1 classes for performance reasons. Also, keep in mind that the solution outlined here is just an example and that other solutions are possible.
13. Why doesn't calling the method Class.forName load my JDBC driver?
There is a bug in the JDK 1.1.x that can cause the method Class.forName to fail. A workaround is to explicitly call the method DriverManager.registerDriver(new YourDriverClass()). The exact problem in the JDK is a race condition in the class loader that prevents the static section of code in the driver class from executing and registering the driver with the DriverManager.
14. Why do the java.sql and java.math packages fail to download java.* packages? Is there a workaround?
For security reasons, browsers will not download java.* packages. In order to use the JDBC API with browsers that have not been upgraded to JDK1.1 or beyond, we recommend that the java.sql and java.math packages be renamed jdbc.sql and jdbc.math. Most vendors supplying JDBC technology-enabled drivers that are written purely in the Java programming language already provide versions of these renamed packages. When JDK 1.1 support has been added to your browser, you should convert your applets back to the java.* package names.
15. Why is the precision of java.math.BigDecimal limited to 18 digits in the JDK 1.0.2 add-on version of the JDBC API?
In JDK 1.1, java.math.BigInteger is implemented in C. It supports a precision of thousands of digits. The same is true for BigDecigmal.
The version of BigInteger provided with the JDK 1.0.2 add-on version of the JDBC API is a simplified version written in the Java programming language, and it is limited to 18 digits. Because the implementation of BigDecimal is based on BigInteger, it also is limited to this precision.
In the JDBC 2.0 API, you can use a new version of the method ResultSet.getBigDecimal that does not take a scale parameter and returns a BigDecimal with full precision.
16. Can the JDBC API be added to JDK 1.0.2?
Yes. Download the JDBC 1.22 API from the JDBC download page and follow the installation instructions in the release notes.
If you are using any version of the JDK from 1.1 on, the JDBC API is already included, and you should not download the JDBC 1.22 API.
17. How do I retrieve a whole row of data at once, instead of calling an individual ResultSet.getXXX method for each column?
The ResultSet.getXXX methods are the only way to retrieve data from a ResultSet object, which means that you have to make a method call for each column of a row. It is unlikely that this is the cause of a performance problem, however, because it is difficult to see how a column could be fetched without at least the cost of a function call in any scenario. We welcome input from developers on this issue.
18. Why does the ODBC driver manager return 'Data source name not found and no default driver specified Vendor: 0'
This type of error occurs during an attempt to connect to a database with the bridge. First, note that the error is coming from the ODBC driver manager. This indicates that the bridge-which is a normal ODBC client-has successfully called ODBC, so the problem isn't due to native libraries not being present. In this case, it appears that the error is due to the fact that an ODBC DSN (data source name) needs to be configured on the client machine. Developers often forget to do this, thinking that the bridge will magically find the DSN they configured on their remote server machine
19. Are all the required JDBC drivers to establish connectivity to my database part of the JDK?
No. There aren't any JDBC technology-enabled drivers bundled with the JDK 1.1.x or Java 2 Platform releases other than the JDBC-ODBC Bridge. So, developers need to get a driver and install it before they can connect to a database. We are considering bundling JDBC technology- enabled drivers in the future.
20. Is the JDBC-ODBC Bridge multi-threaded?
No. The JDBC-ODBC Bridge does not support concurrent access from different threads. The JDBC-ODBC Bridge uses synchronized methods to serialize all of the calls that it makes to ODBC. Multi-threaded Java programs may use the Bridge, but they won't get the advantages of multi-threading. In addition, deadlocks can occur between locks held in the database and the semaphore used by the Bridge. We are thinking about removing the synchronized methods in the future. They were added originally to make things simple for folks writing Java programs that use a single-threaded ODBC driver.
21. Does the JDBC-ODBC Bridge support multiple concurrent open statements per connection?
No. You can open only one Statement object per connection when you are using the JDBC-ODBC Bridge.
22. Does the JDBC-ODBC Bridge developed by Merant and Sun support result sets that contain Japanese Characters (DBCS)?
Yes, but we haven't tested this ourselves. The version of the Bridge in the Java 2 SDK, Standard Edition, and Java 2 SDK, Enterprise Edition, also supports a new charSet Connection property for specifying the character encoding used by the underlying DBMS.
23. Why can't I invoke the ResultSet methods afterLast and beforeFirst when the method next works?
You are probably using a driver implemented for the JDBC 1.0 API. You need to upgrade to a JDBC 2.0 driver that implements scrollable result sets. Also be sure that your code has created scrollable result sets and that the DBMS you are using supports them.
24. How can I retrieve a String or other object type without creating a new object each time?
Creating and garbage collecting potentially large numbers of objects (millions) unnecessarily can really hurt performance. It may be better to provide a way to retrieve data like strings using the JDBC API without always allocating a new object.
We are studying this issue to see if it is an area in which the JDBC API should be improved. Stay tuned, and please send us any comments you have on this question.
25. There is a method getColumnCount in the JDBC API. Is there a similar method to find the number of rows in a result set?
No, but it is easy to find the number of rows. If you are using a scrollable result set, rs, you can call the methods rs.last and then rs.getRow to find out how many rows rs has. If the result is not scrollable, you can either count the rows by iterating through the result set or get the number of rows by submitting a query with a COUNT column in the SELECT clause.
26. I would like to download the JDBC-ODBC Bridge for the Java 2 SDK, Standard Edition (formerly JDK 1.2). I'm a beginner with the JDBC API, and I would like to start with the Bridge. How do I do it?
The JDBC-ODBC Bridge is bundled with the Java 2 SDK, Standard Edition, so there is no need to download it separately.
27. If I use the JDBC API, do I have to use ODBC underneath?
No, this is just one of many possible solutions. We recommend using a pure Java JDBC technology-enabled driver, type 3 or 4, in order to get all of the benefits of the Java programming language and the JDBC API.
28. Once I have the Java 2 SDK, Standard Edition, from Sun, what else do I need to connect to a database?
You still need to get and install a JDBC technology-enabled driver that supports the database that you are using. There are many drivers available from a variety of sources. You can also try using the JDBC-ODBC Bridge if you have ODBC connectivity set up already. The Bridge comes with the Java 2 SDK, Standard Edition, and Enterprise Edition, and it doesn't require any extra setup itself. The Bridge is a normal ODBC client. Note, however, that you should use the JDBC-ODBC Bridge only for experimental prototyping or when you have no other driver available.
JDBC - ODBC Questions......
1. What's the JDBC 2.0 API?
The JDBC 2.0 API is the latest update of the JDBC API. It contains many new features, including scrollable result sets and the new SQL:1999 (formerly SQL 3) data types. There are two parts to the JDBC 2.0 API:
the JDBC 2.0 core API (the java.sql package), which is included in the JavaTM 2 SDK, Standard Edition
the JDBC 2.0 Optional Package API (the javax.sql package), which is available separately or as part of the Java 2 SDK, Enterprise Edition
2. Does the JDBC-ODBC Bridge support the new features in the JDBC 2.0 API?
No, the JDBC-ODBC Bridge that is included in the Java 2 Platform initial release does not support the new features in the JDBC 2.0 API. However, Sun and Merant are working to produce a new version of the Bridge that does support the new features. Note that we do not recommend using the Bridge except for experimental purposes or when you have no other driver available.
3. Can the JDBC-ODBC Bridge be used with applets?
Use of the JDBC-ODBC bridge from an untrusted applet running in a browser, such as Netscape Navigator, isn't allowed. The JDBC-ODBC bridge doesn't allow untrusted code to call it for security reasons. This is good because it means that an untrusted applet that is downloaded by the browser can't circumvent Java security by calling ODBC. Remember that ODBC is native code, so once ODBC is called, the Java programming language can't guarantee that a security violation won't occur. On the other hand, Pure Java JDBC drivers work well with applets. They are fully downloadable and do not require any client-side configuration.
Finally, we would like to note that it is possible to use the JDBC-ODBC bridge with applets that will be run in appletviewer since appletviewer assumes that applets are trusted. It is also possible to use the JDBC-ODBC bridge with applets that are run in the HotJavaTM browser (available from Java Software), since HotJava provides an option to turn off applet security. In general, it is dangerous to turn applet security off, but it may be appropriate in certain controlled situations, such as for applets that will only be used in a secure intranet environment. Remember to exercise caution if you choose this option, and use an all-Java JDBC driver whenever possible to avoid security problems.
4. How do I start debugging problems related to the JDBC API?
A good way to find out what JDBC calls are doing is to enable JDBC tracing. The JDBC trace contains a detailed listing of the activity occurring in the system that is related to JDBC operations.
If you use the DriverManager facility to establish your database connection, you use the DriverManager.setLogWriter method to enable tracing of JDBC operations. If you use a DataSource object to get a connection, you use the DataSource.setLogWriter method to enable tracing. (For pooled connections, you use the ConnectionPoolDataSource.setLogWriter method, and for connections that can participate in distributed transactions, you use the XADataSource.setLogWriter method.)
5. How can I use the JDBC API to access a desktop database like Microsoft Access over the network?
Most desktop databases currently require a JDBC solution that uses ODBC underneath. This is because the vendors of these database products haven't implemented all-Java JDBC drivers.
The best approach is to use a commercial JDBC driver that supports ODBC and the database you want to use. See the JDBC drivers page for a list of available JDBC drivers.
The JDBC-ODBC bridge from Sun's Java Software does not provide network access to desktop databases by itself. The JDBC-ODBC bridge loads ODBC as a local DLL, and typical ODBC drivers for desktop databases like Access aren't networked. The JDBC-ODBC bridge can be used together with the RMI-JDBC bridge , however, to access a desktop database like Access over the net. This RMI-JDBC-ODBC solution is free.
6. Does the JDK include the JDBC API and the JDBC-ODBC Bridge?
Yes, the JDK 1.1 and the Java 2 SDK, Standard Edition (formerly known as the JDK 1.2), contain both the JDBC API and the JDBC-ODBC Bridge. The Java 2 SDK, Standard Edition, contains the JDBC 2.0 core API, which is the latest version. It does not include the JDBC 2.0 Optional Package, which is part of the Java 2 SDK, Enterprise Edition, or which you can download separately.
Note that the version of the JDBC API and the JDBC-ODBC Bridge provided for separate download on the JDBC download page are only for use with the JDK 1.0.2.
7. What JDBC technology-enabled drivers are available?
See our web page on JDBC technology-enabled drivers for a current listing.
8. What documentation is available for the JDBC API?
See the JDBC technology home page for links to information about JDBC technology. This page links to information about features and benefits, a list of new features, a section on getting started, online tutorials, a section on driver requirements, and other information in addition to the specifications and javadoc documentation.
9. Are there any ODBC drivers that do not work with the JDBC-ODBC Bridge?
Most ODBC 2.0 drivers should work with the Bridge. Since there is some variation in functionality between ODBC drivers, the functionality of the bridge may be affected. The bridge works with popular PC databases, such as Microsoft Access and FoxPro.
10. Does the JDBC-ODBC Bridge work with Microsoft J++?
No, J++ does not support the JDBC-ODBC bridge since it doesn't implement the Java Native Interface (JNI). Any all-Java JDBC driver should work with J++, however.
11. What causes the "No suitable driver" error?
"No suitable driver" is an error that usually occurs during a call to the DriverManager.getConnection method. The cause can be failing to load the appropriate JDBC drivers before calling the getConnection method, or it can be specifying an invalid JDBC URL--one that isn't recognized by your JDBC driver. Your best bet is to check the documentation for your JDBC driver or contact your JDBC driver vendor if you suspect that the URL you are specifying is not being recognized by your JDBC driver.
In addition, when you are using the JDBC-ODBC Bridge, this error can occur if one or more the the shared libraries needed by the Bridge cannot be loaded. If you think this is the cause, check your configuration to be sure that the shared libraries are accessible to the Bridge.
12. Why isn't the java.sql.DriverManager class being found?
This problem can be caused by running a JDBC applet in a browser that supports the JDK 1.0.2, such as Netscape Navigator 3.0. The JDK 1.0.2 does not contain the JDBC API, so the DriverManager class typically isn't found by the Java virtual machine running in the browser.
Here's a solution that doesn't require any additional configuration of your web clients. Remember that classes in the java.* packages cannot be downloaded by most browsers for security reasons. Because of this, many vendors of all-Java JDBC drivers supply versions of the java.sql.* classes that have been renamed to jdbc.sql.*, along with a version of their driver that uses these modified classes. If you import jdbc.sql.* in your applet code instead of java.sql.*, and add the jdbc.sql.* classes provided by your JDBC driver vendor to your applet's codebase, then all of the JDBC classes needed by the applet can be downloaded by the browser at run time, including the DriverManager class.
This solution will allow your applet to work in any client browser that supports the JDK 1.0.2. Your applet will also work in browsers that support the JDK 1.1, although you may want to switch to the JDK 1.1 classes for performance reasons. Also, keep in mind that the solution outlined here is just an example and that other solutions are possible.
13. Why doesn't calling the method Class.forName load my JDBC driver?
There is a bug in the JDK 1.1.x that can cause the method Class.forName to fail. A workaround is to explicitly call the method DriverManager.registerDriver(new YourDriverClass()). The exact problem in the JDK is a race condition in the class loader that prevents the static section of code in the driver class from executing and registering the driver with the DriverManager.
14. Why do the java.sql and java.math packages fail to download java.* packages? Is there a workaround?
For security reasons, browsers will not download java.* packages. In order to use the JDBC API with browsers that have not been upgraded to JDK1.1 or beyond, we recommend that the java.sql and java.math packages be renamed jdbc.sql and jdbc.math. Most vendors supplying JDBC technology-enabled drivers that are written purely in the Java programming language already provide versions of these renamed packages. When JDK 1.1 support has been added to your browser, you should convert your applets back to the java.* package names.
15. Why is the precision of java.math.BigDecimal limited to 18 digits in the JDK 1.0.2 add-on version of the JDBC API?
In JDK 1.1, java.math.BigInteger is implemented in C. It supports a precision of thousands of digits. The same is true for BigDecigmal.
The version of BigInteger provided with the JDK 1.0.2 add-on version of the JDBC API is a simplified version written in the Java programming language, and it is limited to 18 digits. Because the implementation of BigDecimal is based on BigInteger, it also is limited to this precision.
In the JDBC 2.0 API, you can use a new version of the method ResultSet.getBigDecimal that does not take a scale parameter and returns a BigDecimal with full precision.
16. Can the JDBC API be added to JDK 1.0.2?
Yes. Download the JDBC 1.22 API from the JDBC download page and follow the installation instructions in the release notes.
If you are using any version of the JDK from 1.1 on, the JDBC API is already included, and you should not download the JDBC 1.22 API.
17. How do I retrieve a whole row of data at once, instead of calling an individual ResultSet.getXXX method for each column?
The ResultSet.getXXX methods are the only way to retrieve data from a ResultSet object, which means that you have to make a method call for each column of a row. It is unlikely that this is the cause of a performance problem, however, because it is difficult to see how a column could be fetched without at least the cost of a function call in any scenario. We welcome input from developers on this issue.
18. Why does the ODBC driver manager return 'Data source name not found and no default driver specified Vendor: 0'
This type of error occurs during an attempt to connect to a database with the bridge. First, note that the error is coming from the ODBC driver manager. This indicates that the bridge-which is a normal ODBC client-has successfully called ODBC, so the problem isn't due to native libraries not being present. In this case, it appears that the error is due to the fact that an ODBC DSN (data source name) needs to be configured on the client machine. Developers often forget to do this, thinking that the bridge will magically find the DSN they configured on their remote server machine
19. Are all the required JDBC drivers to establish connectivity to my database part of the JDK?
No. There aren't any JDBC technology-enabled drivers bundled with the JDK 1.1.x or Java 2 Platform releases other than the JDBC-ODBC Bridge. So, developers need to get a driver and install it before they can connect to a database. We are considering bundling JDBC technology- enabled drivers in the future.
20. Is the JDBC-ODBC Bridge multi-threaded?
No. The JDBC-ODBC Bridge does not support concurrent access from different threads. The JDBC-ODBC Bridge uses synchronized methods to serialize all of the calls that it makes to ODBC. Multi-threaded Java programs may use the Bridge, but they won't get the advantages of multi-threading. In addition, deadlocks can occur between locks held in the database and the semaphore used by the Bridge. We are thinking about removing the synchronized methods in the future. They were added originally to make things simple for folks writing Java programs that use a single-threaded ODBC driver.
21. Does the JDBC-ODBC Bridge support multiple concurrent open statements per connection?
No. You can open only one Statement object per connection when you are using the JDBC-ODBC Bridge.
22. Does the JDBC-ODBC Bridge developed by Merant and Sun support result sets that contain Japanese Characters (DBCS)?
Yes, but we haven't tested this ourselves. The version of the Bridge in the Java 2 SDK, Standard Edition, and Java 2 SDK, Enterprise Edition, also supports a new charSet Connection property for specifying the character encoding used by the underlying DBMS.
23. Why can't I invoke the ResultSet methods afterLast and beforeFirst when the method next works?
You are probably using a driver implemented for the JDBC 1.0 API. You need to upgrade to a JDBC 2.0 driver that implements scrollable result sets. Also be sure that your code has created scrollable result sets and that the DBMS you are using supports them.
24. How can I retrieve a String or other object type without creating a new object each time?
Creating and garbage collecting potentially large numbers of objects (millions) unnecessarily can really hurt performance. It may be better to provide a way to retrieve data like strings using the JDBC API without always allocating a new object.
We are studying this issue to see if it is an area in which the JDBC API should be improved. Stay tuned, and please send us any comments you have on this question.
25. There is a method getColumnCount in the JDBC API. Is there a similar method to find the number of rows in a result set?
No, but it is easy to find the number of rows. If you are using a scrollable result set, rs, you can call the methods rs.last and then rs.getRow to find out how many rows rs has. If the result is not scrollable, you can either count the rows by iterating through the result set or get the number of rows by submitting a query with a COUNT column in the SELECT clause.
26. I would like to download the JDBC-ODBC Bridge for the Java 2 SDK, Standard Edition (formerly JDK 1.2). I'm a beginner with the JDBC API, and I would like to start with the Bridge. How do I do it?
The JDBC-ODBC Bridge is bundled with the Java 2 SDK, Standard Edition, so there is no need to download it separately.
27. If I use the JDBC API, do I have to use ODBC underneath?
No, this is just one of many possible solutions. We recommend using a pure Java JDBC technology-enabled driver, type 3 or 4, in order to get all of the benefits of the Java programming language and the JDBC API.
28. Once I have the Java 2 SDK, Standard Edition, from Sun, what else do I need to connect to a database?
You still need to get and install a JDBC technology-enabled driver that supports the database that you are using. There are many drivers available from a variety of sources. You can also try using the JDBC-ODBC Bridge if you have ODBC connectivity set up already. The Bridge comes with the Java 2 SDK, Standard Edition, and Enterprise Edition, and it doesn't require any extra setup itself. The Bridge is a normal ODBC client. Note, however, that you should use the JDBC-ODBC Bridge only for experimental prototyping or when you have no other driver available.
The JDBC 2.0 API is the latest update of the JDBC API. It contains many new features, including scrollable result sets and the new SQL:1999 (formerly SQL 3) data types. There are two parts to the JDBC 2.0 API:
the JDBC 2.0 core API (the java.sql package), which is included in the JavaTM 2 SDK, Standard Edition
the JDBC 2.0 Optional Package API (the javax.sql package), which is available separately or as part of the Java 2 SDK, Enterprise Edition
2. Does the JDBC-ODBC Bridge support the new features in the JDBC 2.0 API?
No, the JDBC-ODBC Bridge that is included in the Java 2 Platform initial release does not support the new features in the JDBC 2.0 API. However, Sun and Merant are working to produce a new version of the Bridge that does support the new features. Note that we do not recommend using the Bridge except for experimental purposes or when you have no other driver available.
3. Can the JDBC-ODBC Bridge be used with applets?
Use of the JDBC-ODBC bridge from an untrusted applet running in a browser, such as Netscape Navigator, isn't allowed. The JDBC-ODBC bridge doesn't allow untrusted code to call it for security reasons. This is good because it means that an untrusted applet that is downloaded by the browser can't circumvent Java security by calling ODBC. Remember that ODBC is native code, so once ODBC is called, the Java programming language can't guarantee that a security violation won't occur. On the other hand, Pure Java JDBC drivers work well with applets. They are fully downloadable and do not require any client-side configuration.
Finally, we would like to note that it is possible to use the JDBC-ODBC bridge with applets that will be run in appletviewer since appletviewer assumes that applets are trusted. It is also possible to use the JDBC-ODBC bridge with applets that are run in the HotJavaTM browser (available from Java Software), since HotJava provides an option to turn off applet security. In general, it is dangerous to turn applet security off, but it may be appropriate in certain controlled situations, such as for applets that will only be used in a secure intranet environment. Remember to exercise caution if you choose this option, and use an all-Java JDBC driver whenever possible to avoid security problems.
4. How do I start debugging problems related to the JDBC API?
A good way to find out what JDBC calls are doing is to enable JDBC tracing. The JDBC trace contains a detailed listing of the activity occurring in the system that is related to JDBC operations.
If you use the DriverManager facility to establish your database connection, you use the DriverManager.setLogWriter method to enable tracing of JDBC operations. If you use a DataSource object to get a connection, you use the DataSource.setLogWriter method to enable tracing. (For pooled connections, you use the ConnectionPoolDataSource.setLogWriter method, and for connections that can participate in distributed transactions, you use the XADataSource.setLogWriter method.)
5. How can I use the JDBC API to access a desktop database like Microsoft Access over the network?
Most desktop databases currently require a JDBC solution that uses ODBC underneath. This is because the vendors of these database products haven't implemented all-Java JDBC drivers.
The best approach is to use a commercial JDBC driver that supports ODBC and the database you want to use. See the JDBC drivers page for a list of available JDBC drivers.
The JDBC-ODBC bridge from Sun's Java Software does not provide network access to desktop databases by itself. The JDBC-ODBC bridge loads ODBC as a local DLL, and typical ODBC drivers for desktop databases like Access aren't networked. The JDBC-ODBC bridge can be used together with the RMI-JDBC bridge , however, to access a desktop database like Access over the net. This RMI-JDBC-ODBC solution is free.
6. Does the JDK include the JDBC API and the JDBC-ODBC Bridge?
Yes, the JDK 1.1 and the Java 2 SDK, Standard Edition (formerly known as the JDK 1.2), contain both the JDBC API and the JDBC-ODBC Bridge. The Java 2 SDK, Standard Edition, contains the JDBC 2.0 core API, which is the latest version. It does not include the JDBC 2.0 Optional Package, which is part of the Java 2 SDK, Enterprise Edition, or which you can download separately.
Note that the version of the JDBC API and the JDBC-ODBC Bridge provided for separate download on the JDBC download page are only for use with the JDK 1.0.2.
7. What JDBC technology-enabled drivers are available?
See our web page on JDBC technology-enabled drivers for a current listing.
8. What documentation is available for the JDBC API?
See the JDBC technology home page for links to information about JDBC technology. This page links to information about features and benefits, a list of new features, a section on getting started, online tutorials, a section on driver requirements, and other information in addition to the specifications and javadoc documentation.
9. Are there any ODBC drivers that do not work with the JDBC-ODBC Bridge?
Most ODBC 2.0 drivers should work with the Bridge. Since there is some variation in functionality between ODBC drivers, the functionality of the bridge may be affected. The bridge works with popular PC databases, such as Microsoft Access and FoxPro.
10. Does the JDBC-ODBC Bridge work with Microsoft J++?
No, J++ does not support the JDBC-ODBC bridge since it doesn't implement the Java Native Interface (JNI). Any all-Java JDBC driver should work with J++, however.
11. What causes the "No suitable driver" error?
"No suitable driver" is an error that usually occurs during a call to the DriverManager.getConnection method. The cause can be failing to load the appropriate JDBC drivers before calling the getConnection method, or it can be specifying an invalid JDBC URL--one that isn't recognized by your JDBC driver. Your best bet is to check the documentation for your JDBC driver or contact your JDBC driver vendor if you suspect that the URL you are specifying is not being recognized by your JDBC driver.
In addition, when you are using the JDBC-ODBC Bridge, this error can occur if one or more the the shared libraries needed by the Bridge cannot be loaded. If you think this is the cause, check your configuration to be sure that the shared libraries are accessible to the Bridge.
12. Why isn't the java.sql.DriverManager class being found?
This problem can be caused by running a JDBC applet in a browser that supports the JDK 1.0.2, such as Netscape Navigator 3.0. The JDK 1.0.2 does not contain the JDBC API, so the DriverManager class typically isn't found by the Java virtual machine running in the browser.
Here's a solution that doesn't require any additional configuration of your web clients. Remember that classes in the java.* packages cannot be downloaded by most browsers for security reasons. Because of this, many vendors of all-Java JDBC drivers supply versions of the java.sql.* classes that have been renamed to jdbc.sql.*, along with a version of their driver that uses these modified classes. If you import jdbc.sql.* in your applet code instead of java.sql.*, and add the jdbc.sql.* classes provided by your JDBC driver vendor to your applet's codebase, then all of the JDBC classes needed by the applet can be downloaded by the browser at run time, including the DriverManager class.
This solution will allow your applet to work in any client browser that supports the JDK 1.0.2. Your applet will also work in browsers that support the JDK 1.1, although you may want to switch to the JDK 1.1 classes for performance reasons. Also, keep in mind that the solution outlined here is just an example and that other solutions are possible.
13. Why doesn't calling the method Class.forName load my JDBC driver?
There is a bug in the JDK 1.1.x that can cause the method Class.forName to fail. A workaround is to explicitly call the method DriverManager.registerDriver(new YourDriverClass()). The exact problem in the JDK is a race condition in the class loader that prevents the static section of code in the driver class from executing and registering the driver with the DriverManager.
14. Why do the java.sql and java.math packages fail to download java.* packages? Is there a workaround?
For security reasons, browsers will not download java.* packages. In order to use the JDBC API with browsers that have not been upgraded to JDK1.1 or beyond, we recommend that the java.sql and java.math packages be renamed jdbc.sql and jdbc.math. Most vendors supplying JDBC technology-enabled drivers that are written purely in the Java programming language already provide versions of these renamed packages. When JDK 1.1 support has been added to your browser, you should convert your applets back to the java.* package names.
15. Why is the precision of java.math.BigDecimal limited to 18 digits in the JDK 1.0.2 add-on version of the JDBC API?
In JDK 1.1, java.math.BigInteger is implemented in C. It supports a precision of thousands of digits. The same is true for BigDecigmal.
The version of BigInteger provided with the JDK 1.0.2 add-on version of the JDBC API is a simplified version written in the Java programming language, and it is limited to 18 digits. Because the implementation of BigDecimal is based on BigInteger, it also is limited to this precision.
In the JDBC 2.0 API, you can use a new version of the method ResultSet.getBigDecimal that does not take a scale parameter and returns a BigDecimal with full precision.
16. Can the JDBC API be added to JDK 1.0.2?
Yes. Download the JDBC 1.22 API from the JDBC download page and follow the installation instructions in the release notes.
If you are using any version of the JDK from 1.1 on, the JDBC API is already included, and you should not download the JDBC 1.22 API.
17. How do I retrieve a whole row of data at once, instead of calling an individual ResultSet.getXXX method for each column?
The ResultSet.getXXX methods are the only way to retrieve data from a ResultSet object, which means that you have to make a method call for each column of a row. It is unlikely that this is the cause of a performance problem, however, because it is difficult to see how a column could be fetched without at least the cost of a function call in any scenario. We welcome input from developers on this issue.
18. Why does the ODBC driver manager return 'Data source name not found and no default driver specified Vendor: 0'
This type of error occurs during an attempt to connect to a database with the bridge. First, note that the error is coming from the ODBC driver manager. This indicates that the bridge-which is a normal ODBC client-has successfully called ODBC, so the problem isn't due to native libraries not being present. In this case, it appears that the error is due to the fact that an ODBC DSN (data source name) needs to be configured on the client machine. Developers often forget to do this, thinking that the bridge will magically find the DSN they configured on their remote server machine
19. Are all the required JDBC drivers to establish connectivity to my database part of the JDK?
No. There aren't any JDBC technology-enabled drivers bundled with the JDK 1.1.x or Java 2 Platform releases other than the JDBC-ODBC Bridge. So, developers need to get a driver and install it before they can connect to a database. We are considering bundling JDBC technology- enabled drivers in the future.
20. Is the JDBC-ODBC Bridge multi-threaded?
No. The JDBC-ODBC Bridge does not support concurrent access from different threads. The JDBC-ODBC Bridge uses synchronized methods to serialize all of the calls that it makes to ODBC. Multi-threaded Java programs may use the Bridge, but they won't get the advantages of multi-threading. In addition, deadlocks can occur between locks held in the database and the semaphore used by the Bridge. We are thinking about removing the synchronized methods in the future. They were added originally to make things simple for folks writing Java programs that use a single-threaded ODBC driver.
21. Does the JDBC-ODBC Bridge support multiple concurrent open statements per connection?
No. You can open only one Statement object per connection when you are using the JDBC-ODBC Bridge.
22. Does the JDBC-ODBC Bridge developed by Merant and Sun support result sets that contain Japanese Characters (DBCS)?
Yes, but we haven't tested this ourselves. The version of the Bridge in the Java 2 SDK, Standard Edition, and Java 2 SDK, Enterprise Edition, also supports a new charSet Connection property for specifying the character encoding used by the underlying DBMS.
23. Why can't I invoke the ResultSet methods afterLast and beforeFirst when the method next works?
You are probably using a driver implemented for the JDBC 1.0 API. You need to upgrade to a JDBC 2.0 driver that implements scrollable result sets. Also be sure that your code has created scrollable result sets and that the DBMS you are using supports them.
24. How can I retrieve a String or other object type without creating a new object each time?
Creating and garbage collecting potentially large numbers of objects (millions) unnecessarily can really hurt performance. It may be better to provide a way to retrieve data like strings using the JDBC API without always allocating a new object.
We are studying this issue to see if it is an area in which the JDBC API should be improved. Stay tuned, and please send us any comments you have on this question.
25. There is a method getColumnCount in the JDBC API. Is there a similar method to find the number of rows in a result set?
No, but it is easy to find the number of rows. If you are using a scrollable result set, rs, you can call the methods rs.last and then rs.getRow to find out how many rows rs has. If the result is not scrollable, you can either count the rows by iterating through the result set or get the number of rows by submitting a query with a COUNT column in the SELECT clause.
26. I would like to download the JDBC-ODBC Bridge for the Java 2 SDK, Standard Edition (formerly JDK 1.2). I'm a beginner with the JDBC API, and I would like to start with the Bridge. How do I do it?
The JDBC-ODBC Bridge is bundled with the Java 2 SDK, Standard Edition, so there is no need to download it separately.
27. If I use the JDBC API, do I have to use ODBC underneath?
No, this is just one of many possible solutions. We recommend using a pure Java JDBC technology-enabled driver, type 3 or 4, in order to get all of the benefits of the Java programming language and the JDBC API.
28. Once I have the Java 2 SDK, Standard Edition, from Sun, what else do I need to connect to a database?
You still need to get and install a JDBC technology-enabled driver that supports the database that you are using. There are many drivers available from a variety of sources. You can also try using the JDBC-ODBC Bridge if you have ODBC connectivity set up already. The Bridge comes with the Java 2 SDK, Standard Edition, and Enterprise Edition, and it doesn't require any extra setup itself. The Bridge is a normal ODBC client. Note, however, that you should use the JDBC-ODBC Bridge only for experimental prototyping or when you have no other driver available.
What makes a plugin secure?
What makes a plugin secure?
Here are some characteristics of a secure plugin:
1. It is digitally signed by the publisher by a third party issued certificate. This way the user at least knows where the plugin in coming from.
2. Inform the user of any actions which can lead to any changes in the system before hand and allow user to reject the proposed actions.
3. Give user the option to save current system settings such that the user can go back to it after the plugin has finished execution if the user so desires.
Items 2 and 3 above are sometimes the responsiblity of the application installing and using the plugin and not the plugin itself. From the end user perspective they are the same. So the the word plugin here can mean either just the plugin or the plugin together with web application driving it.
Both java applets and activex components are plugins. Both are written to the disk and saved for future use. ActiveX components can be used by applications other than the web browser while for most practical purposes, java applets can only be used from a web browser (there are stanalone java applet hosting programs out there but they are mostly used by developers and not by end users). The ActiveX component installation requires modification to system registery and hence the end user must have administrative privilege in order to install it while Java applets don't need any adminitrative privilege for installation. One can argue that this makes a signed Java Applet a bigger security threat than an ActiveX component since even a user with minimum previlege can download and run it without the knowledge of the system adminstrator. The only way to avoid this situation is to set the browser to not allow Java Applets all together.
Here are some characteristics of a secure plugin:
1. It is digitally signed by the publisher by a third party issued certificate. This way the user at least knows where the plugin in coming from.
2. Inform the user of any actions which can lead to any changes in the system before hand and allow user to reject the proposed actions.
3. Give user the option to save current system settings such that the user can go back to it after the plugin has finished execution if the user so desires.
Items 2 and 3 above are sometimes the responsiblity of the application installing and using the plugin and not the plugin itself. From the end user perspective they are the same. So the the word plugin here can mean either just the plugin or the plugin together with web application driving it.
Both java applets and activex components are plugins. Both are written to the disk and saved for future use. ActiveX components can be used by applications other than the web browser while for most practical purposes, java applets can only be used from a web browser (there are stanalone java applet hosting programs out there but they are mostly used by developers and not by end users). The ActiveX component installation requires modification to system registery and hence the end user must have administrative privilege in order to install it while Java applets don't need any adminitrative privilege for installation. One can argue that this makes a signed Java Applet a bigger security threat than an ActiveX component since even a user with minimum previlege can download and run it without the knowledge of the system adminstrator. The only way to avoid this situation is to set the browser to not allow Java Applets all together.
What makes a plugin secure?
What makes a plugin secure?
Here are some characteristics of a secure plugin:
1. It is digitally signed by the publisher by a third party issued certificate. This way the user at least knows where the plugin in coming from.
2. Inform the user of any actions which can lead to any changes in the system before hand and allow user to reject the proposed actions.
3. Give user the option to save current system settings such that the user can go back to it after the plugin has finished execution if the user so desires.
Items 2 and 3 above are sometimes the responsiblity of the application installing and using the plugin and not the plugin itself. From the end user perspective they are the same. So the the word plugin here can mean either just the plugin or the plugin together with web application driving it.
Both java applets and activex components are plugins. Both are written to the disk and saved for future use. ActiveX components can be used by applications other than the web browser while for most practical purposes, java applets can only be used from a web browser (there are stanalone java applet hosting programs out there but they are mostly used by developers and not by end users). The ActiveX component installation requires modification to system registery and hence the end user must have administrative privilege in order to install it while Java applets don't need any adminitrative privilege for installation. One can argue that this makes a signed Java Applet a bigger security threat than an ActiveX component since even a user with minimum previlege can download and run it without the knowledge of the system adminstrator. The only way to avoid this situation is to set the browser to not allow Java Applets all together.
Here are some characteristics of a secure plugin:
1. It is digitally signed by the publisher by a third party issued certificate. This way the user at least knows where the plugin in coming from.
2. Inform the user of any actions which can lead to any changes in the system before hand and allow user to reject the proposed actions.
3. Give user the option to save current system settings such that the user can go back to it after the plugin has finished execution if the user so desires.
Items 2 and 3 above are sometimes the responsiblity of the application installing and using the plugin and not the plugin itself. From the end user perspective they are the same. So the the word plugin here can mean either just the plugin or the plugin together with web application driving it.
Both java applets and activex components are plugins. Both are written to the disk and saved for future use. ActiveX components can be used by applications other than the web browser while for most practical purposes, java applets can only be used from a web browser (there are stanalone java applet hosting programs out there but they are mostly used by developers and not by end users). The ActiveX component installation requires modification to system registery and hence the end user must have administrative privilege in order to install it while Java applets don't need any adminitrative privilege for installation. One can argue that this makes a signed Java Applet a bigger security threat than an ActiveX component since even a user with minimum previlege can download and run it without the knowledge of the system adminstrator. The only way to avoid this situation is to set the browser to not allow Java Applets all together.
Smart phone – is it really smart?
“Smart phones are meant for the people who are smart enough to upgrade & utilize the device,not for the dumb people who wants to use the phone as a style statement/Trendy device….” – comment left on pluggd.in
As a mobile enthusiast, we all tend to believe that smartphone users are really smart as us. Smart phone users ‘actually’ know what a widget/app is and how to install/use widgets and other apps in the mobile.
Case in point – whenever we have talked about Nokia’s strategy (or the lack of it), a whole lot of Nokia fanboys have tried to put forth their smart logic by putting themselves, i.e. developer in the shoes of the end user.
For instance:
“the N900 is an enthusiast device..the N900 is more of a mini-computer converted to a phone, rather than a phone with “smart” capabilities. As such, the average Indian consumer (read: 95% of the market) would not be interested in the N900. Seriously… Show me ten people who wouldn’t mind using their phone ONLY in Landscape mode. Please. And don’t tell me you didn’t know that the N900 uses Portrait mode ONLY for calls, and Landscape mode for everything else? Also, it’s Linux-based. Definitely more of an enthusiast/developer-oriented handset.”- comment
“you can do more with a nokia phone than iPhone….
#1 Install PcSuite/Ovi in your PC or Upgrade your phone from the phone itself….
#2 Goto Ovi stores…. Install apps & Games… Most of the apps are free…
#3 Even if u r not satisfied develop ur own apps….” – comment
“The N8 isnt for the iPhone crowd. Anyone with an unbiased view would have realised that by now. Heck it isnt even a flagship device, so I do not understand why people like you think that every phone Nokia launches is to “combat an iPhone”.
The N8 is more for the convergence crowd. People like me, who’d like to take decent pictures, great video and still be able to “do it all” just with one device. A better term for it, in this regard, would be an “Imaging Flagship” device, i’ll give you that.” -
Ask a ‘typical’ smartphone user what a landscape mode is? Ask Nokia whether N900 is ‘actually’ meant to be an enthusiast device (can they justify the price then)?
Who are the Smartphone users?
As far as India is concerned, a typical businessman who loves to showoff his new toy to friends/business partners (and be the center of attraction) and ofcourse, a few ‘self-actualized’ geeks who love to play with new toys.
What’s the mix, as far as sales is concerned? i.e. geeks vs. businessmen who buy a smartphone? 10:90? 20:80? 80:20?
The segment that drives the max amount of smartphone sales?
Needless to say, it’s the less-actualized ones who are influenced with TV/print ads and wanna grab the toy before anybody else.
A whole lot of geeks do not get the fact that smartphone users aren’t so smart enough to use the features of the phone (they don’t even care about it, just the way a lot of us use trendy phones just for calls/smses only).
Smartphone users do not care so much about the widgets/apps – unless you make apps an integral part of the mobile experience, which is what Apple has done and Nokia has failed to.
So next time you get into this debate, first roam around places like Ahmedabad, Panipat, Delhi, Chennai, Mumbai etc – meet few smartphone owners and ask them if they have heard of something called as ’mobile application‘.
Till then, stop assuming yourself as the end customer.
Note to Nokia Fanboys: Lately we have built a love-hate relationship, but leaving aside that, look beyond yourself. Unlike iPhone app developers (who are also consumers), Nokia fans have a different customer segment – so understand that, before you inculcate blind fanboyism.
As a mobile enthusiast, we all tend to believe that smartphone users are really smart as us. Smart phone users ‘actually’ know what a widget/app is and how to install/use widgets and other apps in the mobile.
Case in point – whenever we have talked about Nokia’s strategy (or the lack of it), a whole lot of Nokia fanboys have tried to put forth their smart logic by putting themselves, i.e. developer in the shoes of the end user.
For instance:
“the N900 is an enthusiast device..the N900 is more of a mini-computer converted to a phone, rather than a phone with “smart” capabilities. As such, the average Indian consumer (read: 95% of the market) would not be interested in the N900. Seriously… Show me ten people who wouldn’t mind using their phone ONLY in Landscape mode. Please. And don’t tell me you didn’t know that the N900 uses Portrait mode ONLY for calls, and Landscape mode for everything else? Also, it’s Linux-based. Definitely more of an enthusiast/developer-oriented handset.”- comment
“you can do more with a nokia phone than iPhone….
#1 Install PcSuite/Ovi in your PC or Upgrade your phone from the phone itself….
#2 Goto Ovi stores…. Install apps & Games… Most of the apps are free…
#3 Even if u r not satisfied develop ur own apps….” – comment
“The N8 isnt for the iPhone crowd. Anyone with an unbiased view would have realised that by now. Heck it isnt even a flagship device, so I do not understand why people like you think that every phone Nokia launches is to “combat an iPhone”.
The N8 is more for the convergence crowd. People like me, who’d like to take decent pictures, great video and still be able to “do it all” just with one device. A better term for it, in this regard, would be an “Imaging Flagship” device, i’ll give you that.” -
Ask a ‘typical’ smartphone user what a landscape mode is? Ask Nokia whether N900 is ‘actually’ meant to be an enthusiast device (can they justify the price then)?
Who are the Smartphone users?
As far as India is concerned, a typical businessman who loves to showoff his new toy to friends/business partners (and be the center of attraction) and ofcourse, a few ‘self-actualized’ geeks who love to play with new toys.
What’s the mix, as far as sales is concerned? i.e. geeks vs. businessmen who buy a smartphone? 10:90? 20:80? 80:20?
The segment that drives the max amount of smartphone sales?
Needless to say, it’s the less-actualized ones who are influenced with TV/print ads and wanna grab the toy before anybody else.
A whole lot of geeks do not get the fact that smartphone users aren’t so smart enough to use the features of the phone (they don’t even care about it, just the way a lot of us use trendy phones just for calls/smses only).
Smartphone users do not care so much about the widgets/apps – unless you make apps an integral part of the mobile experience, which is what Apple has done and Nokia has failed to.
So next time you get into this debate, first roam around places like Ahmedabad, Panipat, Delhi, Chennai, Mumbai etc – meet few smartphone owners and ask them if they have heard of something called as ’mobile application‘.
Till then, stop assuming yourself as the end customer.
Note to Nokia Fanboys: Lately we have built a love-hate relationship, but leaving aside that, look beyond yourself. Unlike iPhone app developers (who are also consumers), Nokia fans have a different customer segment – so understand that, before you inculcate blind fanboyism.
Smart phone – is it really smart?
“Smart phones are meant for the people who are smart enough to upgrade & utilize the device,not for the dumb people who wants to use the phone as a style statement/Trendy device….” – comment left on pluggd.in
As a mobile enthusiast, we all tend to believe that smartphone users are really smart as us. Smart phone users ‘actually’ know what a widget/app is and how to install/use widgets and other apps in the mobile.
Case in point – whenever we have talked about Nokia’s strategy (or the lack of it), a whole lot of Nokia fanboys have tried to put forth their smart logic by putting themselves, i.e. developer in the shoes of the end user.
For instance:
“the N900 is an enthusiast device..the N900 is more of a mini-computer converted to a phone, rather than a phone with “smart” capabilities. As such, the average Indian consumer (read: 95% of the market) would not be interested in the N900. Seriously… Show me ten people who wouldn’t mind using their phone ONLY in Landscape mode. Please. And don’t tell me you didn’t know that the N900 uses Portrait mode ONLY for calls, and Landscape mode for everything else? Also, it’s Linux-based. Definitely more of an enthusiast/developer-oriented handset.”- comment
“you can do more with a nokia phone than iPhone….
#1 Install PcSuite/Ovi in your PC or Upgrade your phone from the phone itself….
#2 Goto Ovi stores…. Install apps & Games… Most of the apps are free…
#3 Even if u r not satisfied develop ur own apps….” – comment
“The N8 isnt for the iPhone crowd. Anyone with an unbiased view would have realised that by now. Heck it isnt even a flagship device, so I do not understand why people like you think that every phone Nokia launches is to “combat an iPhone”.
The N8 is more for the convergence crowd. People like me, who’d like to take decent pictures, great video and still be able to “do it all” just with one device. A better term for it, in this regard, would be an “Imaging Flagship” device, i’ll give you that.” -
Ask a ‘typical’ smartphone user what a landscape mode is? Ask Nokia whether N900 is ‘actually’ meant to be an enthusiast device (can they justify the price then)?
Who are the Smartphone users?
As far as India is concerned, a typical businessman who loves to showoff his new toy to friends/business partners (and be the center of attraction) and ofcourse, a few ‘self-actualized’ geeks who love to play with new toys.
What’s the mix, as far as sales is concerned? i.e. geeks vs. businessmen who buy a smartphone? 10:90? 20:80? 80:20?
The segment that drives the max amount of smartphone sales?
Needless to say, it’s the less-actualized ones who are influenced with TV/print ads and wanna grab the toy before anybody else.
A whole lot of geeks do not get the fact that smartphone users aren’t so smart enough to use the features of the phone (they don’t even care about it, just the way a lot of us use trendy phones just for calls/smses only).
Smartphone users do not care so much about the widgets/apps – unless you make apps an integral part of the mobile experience, which is what Apple has done and Nokia has failed to.
So next time you get into this debate, first roam around places like Ahmedabad, Panipat, Delhi, Chennai, Mumbai etc – meet few smartphone owners and ask them if they have heard of something called as ’mobile application‘.
Till then, stop assuming yourself as the end customer.
Note to Nokia Fanboys: Lately we have built a love-hate relationship, but leaving aside that, look beyond yourself. Unlike iPhone app developers (who are also consumers), Nokia fans have a different customer segment – so understand that, before you inculcate blind fanboyism.
As a mobile enthusiast, we all tend to believe that smartphone users are really smart as us. Smart phone users ‘actually’ know what a widget/app is and how to install/use widgets and other apps in the mobile.
Case in point – whenever we have talked about Nokia’s strategy (or the lack of it), a whole lot of Nokia fanboys have tried to put forth their smart logic by putting themselves, i.e. developer in the shoes of the end user.
For instance:
“the N900 is an enthusiast device..the N900 is more of a mini-computer converted to a phone, rather than a phone with “smart” capabilities. As such, the average Indian consumer (read: 95% of the market) would not be interested in the N900. Seriously… Show me ten people who wouldn’t mind using their phone ONLY in Landscape mode. Please. And don’t tell me you didn’t know that the N900 uses Portrait mode ONLY for calls, and Landscape mode for everything else? Also, it’s Linux-based. Definitely more of an enthusiast/developer-oriented handset.”- comment
“you can do more with a nokia phone than iPhone….
#1 Install PcSuite/Ovi in your PC or Upgrade your phone from the phone itself….
#2 Goto Ovi stores…. Install apps & Games… Most of the apps are free…
#3 Even if u r not satisfied develop ur own apps….” – comment
“The N8 isnt for the iPhone crowd. Anyone with an unbiased view would have realised that by now. Heck it isnt even a flagship device, so I do not understand why people like you think that every phone Nokia launches is to “combat an iPhone”.
The N8 is more for the convergence crowd. People like me, who’d like to take decent pictures, great video and still be able to “do it all” just with one device. A better term for it, in this regard, would be an “Imaging Flagship” device, i’ll give you that.” -
Ask a ‘typical’ smartphone user what a landscape mode is? Ask Nokia whether N900 is ‘actually’ meant to be an enthusiast device (can they justify the price then)?
Who are the Smartphone users?
As far as India is concerned, a typical businessman who loves to showoff his new toy to friends/business partners (and be the center of attraction) and ofcourse, a few ‘self-actualized’ geeks who love to play with new toys.
What’s the mix, as far as sales is concerned? i.e. geeks vs. businessmen who buy a smartphone? 10:90? 20:80? 80:20?
The segment that drives the max amount of smartphone sales?
Needless to say, it’s the less-actualized ones who are influenced with TV/print ads and wanna grab the toy before anybody else.
A whole lot of geeks do not get the fact that smartphone users aren’t so smart enough to use the features of the phone (they don’t even care about it, just the way a lot of us use trendy phones just for calls/smses only).
Smartphone users do not care so much about the widgets/apps – unless you make apps an integral part of the mobile experience, which is what Apple has done and Nokia has failed to.
So next time you get into this debate, first roam around places like Ahmedabad, Panipat, Delhi, Chennai, Mumbai etc – meet few smartphone owners and ask them if they have heard of something called as ’mobile application‘.
Till then, stop assuming yourself as the end customer.
Note to Nokia Fanboys: Lately we have built a love-hate relationship, but leaving aside that, look beyond yourself. Unlike iPhone app developers (who are also consumers), Nokia fans have a different customer segment – so understand that, before you inculcate blind fanboyism.
Subscribe to:
Posts (Atom)
