|
|
JavaTM 2, Standard Edition, v. 1.4.2_03
for SCO® UNIX® Operating Systems
FCS - UnixWare 7.1.4 Beta - OpenServer 5.0.7
This release of Java 2 Standard Edition contains:
This product is hereafter referred to as either "J2SE 1.4.2 for SCO UNIX" or "J2SDK 1.4.2 for SCO UNIX", depending upon which context the reference occurs in.
J2SE 1.4.2 for SCO UNIX is a full implementation of the Sun MicrosystemsTM Java 2 Platform - the technology and environment described in the SunTM specifications of the Java 2 Platform, Standard Edition, v. 1.4.2_03. (The _03 suffix indicates the patch level of the Sun J2SE that J2SE 1.4.2 for SCO UNIX corresponds to.)
This product was originally known as the Java 2 Standard Edition for SCO Operating Systems. In May 2001, the operating systems business of SCO, Inc., was acquired by and made part of Caldera International, Inc., and this product became known as the Java 2 Standard Edition for Caldera UNIX Operating Systems. In August 2002, Caldera International, Inc. announced that it would be changing its name to The SCO Group, Inc. (a change completed in May 2003), and this product is now known as the Java 2 Standard Edition for SCO UNIX Operating Systems.
| Software: |
Supported SCO UNIX platforms:
|
| RAM: | 64 MB |
| Disk Space: | Minimum 75 MB |
J2SE 1.4.2 for SCO UNIX is not supported on older versions of the supported operating systems, such as SCO OpenServer Release 5.0.6 or UnixWare 7 Release 7.1.1, nor is it available for older operating systems, such as the SCO UnixWare 2 operating system.
J2SE 1.4.2 for SCO UNIX cannot be used with the older OSRcompat packages that were released together with older versions of UnixWare 7 and OpenServer.
For the most part the J2SE 1.4.2 is identical for all supported platforms, and everything in these release notes applies to all supported platforms unless otherwise noted.
[*] Package urwfonts is available
as part of the UnixWare 7.1.3 and
OpenServer 5.0.7 media kits and is automatically installed as
part of Initial System Load if Java is installed. It is also available in
the UnixWare 7.1.3 Update Pack 4 media or in
the UnixWare and OpenServer Development Kit 7.1.3 and is
downloadable from the
J2SE 1.3.1
web download
page http://www.sco.com/download/.
[**]
The required
runtime on OpenServer 5 are the libraries contained in the package set OSRcompat
version 8.0.1d provided along with this Beta release and in
the SCO OpenServer Release 5.0.7 Update Service Pack 3 or Maintenance Pack 3.
-->
J2SE 1.4.2 for SCO UNIX is a major new release compared to the previous J2SE 1.3.1 for SCO UNIX.
For a list of all the new Java features and enhancements from the J2SE 1.3 platform, see the Sun list at http://java.sun.com/j2se/1.4.2/docs/relnotes/features.html. Also see the Sun J2SE 1.4.2 Release Notes at http://java.sun.com/j2se/1.4.2/relnotes.html.
Potential compatibility problems between this J2SE 1.4.2 for SCO UNIX and the prior J2SE 1.3.1 for SCO UNIX are addressed by the Sun pages at http://java.sun.com/j2se/1.4.2/compatibility.html, http://java.sun.com/j2se/1.4.1/compatibility.html, and http://java.sun.com/j2se/1.4/compatibility.html.
The following changes specific to the J2SE 1.4.2 for SCO UNIX implementation have been made, relative to J2SE 1.3.1 for SCO UNIX:
THREADS_FLAG
environment variable is no longer used.
JVM_USE_RDTSC environment variable
is no longer used.
| Approx. Size | |||
j2jre142 |
urwfonts
runtime (above) |
51 MB |
Runtime Support:
java, the Java virtual machine interpreter (JVM);
the "client" and "server" dynamic compilers;
Java Foundation Classes (JFC) & Swing Package; and
basic API libraries:
language support,
I/O,
AWT,
networking,
utilities,
images,
media,
math,
compression,
and
security.
Distributed applications and database access:
|
j2sdk142 |
j2jre142 | 23 MB |
Development Tools:
appletviewer, the Java Applet Viewer;
javac, the Java Compiler;
jdb, the command-line Java debugger;
javah, the C Header and Stub File Generator
for native methods;
javap, the Java Class File Disassembler;
javadoc, the JAVA API Documentation Generator;
jar, the Java Archive (JAR) tool;
and assorted other commands used in Java development;
class libraries used in Java development;
header files used in native code development.
Also Java demo applets and applications;
demos of Swing functionality;
native method demos.
|
All J2SE 1.4.2 for SCO UNIX users must install the JRE package. It is the base package which other J2SE 1.4.2 for SCO UNIX packages depend upon.
One additional purpose of the JRE package is so that licensed independent software vendors (ISVs) can bundle it with their Java application, if desired. That way, the application and the Java version it has been tested on can be installed together on customer machines, rather than relying on whatever Java version is currently installed on those machines.
The j2jre142 package is by default installed in
/usr/java/, with that actually being a symbolic link
to /opt/java2-1.4.2/.
However, it is possible for an ISV or system administrator to change where the JRE is installed.
ISVs wanting to do this would change the value of BASEDIR
in the pkginfo file and then repackage the j2jre142
package with a different name. The JRE would then install into
BASEDIR.
System administrators wanting to do this would
copy /var/sadm/install/admin/default somewhere
else, modify the value of basedir there, and then tell
pkgadd to use that alternate file with the -a
option. Finally, if basedir=ask is set in that file, then the
pkgadd command will prompt the installer for the desired
package base directory.
Note that the other J2SE 1.4.2 packages require that the j2jre142
package be installed in /opt/java2-1.4.2.
/usr/java symbolic link will be set to
point to /opt/java2-1.4.2.
If you did not install J2SE 1.4.2 as part of the installation of UP4, you
may rerun the uli command as directed in the Update Pack 4
New Features and Notes document provided with Update Pack 4; this
time selecting the J2SE 1.4.2 packages desired.
A copy of these Release Notes will by installed in /opt/java2-1.4.2.
urwfonts package would have been install during UW 7.1.3
Initial System Load (ISL). If you do not currently have urwfonts
on your system, selecting installation of the J2SE 1.4.2 packages will cause
urwfonts to be installed prior to installation of the
j2jre142 package.
While the J2SE is accessed through the /usr/java/ pathname,
installation actually places its contents into /opt/java2-1.4.2/.
Then a symbolic link is made from /usr/java/ to
/opt/java2-1.4.2/.
For compatibility with older J2SE for SCO releases, a symbolic link is
also made from /usr/java2 to /opt/java2-1.4.2/.
Thus, for example, you may invoke the Java virtual machine with either
the command /usr/java/bin/java or the command
/usr/java2/bin/java.
You can have multiple versions of Java installed on your system at the same time. Installation of J2SE 1.4.2 will not automatically remove any previous versions of Java from your system.
If you already have, say,
J2SE 1.3.1 for SCO on your system, all that the installation
of J2SE 1.4.2 will do is change the /usr/java
(and /usr/java2) symbolic link from
/opt/java2-1.3.1 (the actual installation point of J2SE 1.3.1)
to /opt/java2-1.4.2/. You may still access J2SE 1.3.1 directly
by naming its actual installation point. For example, the command
/opt/java2-1.3.1/bin/java will start up the J2SE 1.3.1
virtual machine.
However, if you happen to
already have a JDK 1.1.8 or earlier 1.1.x for SCO version installed
on your system, then you may not want the /usr/java symbolic
link changed to point to J2SE 1.4.2 for SCO UNIX. For example, you may have
applications that do not run correctly under Java 2, whose scripts are
expecting Java 1.1.x to be in /usr/java.
In this case, the install will notify you of the potential conflict,
and give you a choice of whether you want /usr/java to
be changed to point to J2SE 1.4.2 for SCO UNIX
or whether you want it left alone. In the latter case, you would access
J2SE 1.4.2 for SCO UNIX via /usr/java2 rather than
/usr/java.
(The only exception to this is if you are installing J2SE 1.4.2 by default or upgrading your system from UnixWare 7 Release 7.1.1 or Open UNIX 8 Release 8.0.0 to UnixWare 7 Release 7.1.3 Update 4; the ISL or update is non-interactive and thus will always change the symbolic link. You can manually restore the symbolic link afterwards if you so desire.)
Being able to use /usr/java has several advantages:
It is the place where Java is accessed on many other systems,
and thus is often the place third-party
scripts will look for Java. It is the place where Java
first-class executable support on UnixWare
7.1.3 will
look for Java. And it is the place that is by default added to your
PATH environment variable when login accounts are created
on UnixWare 7.
Note however that even if /usr/java is changed to point to
J2SE 1.4.2 for SCO UNIX,
the actual installation point of /opt/jdk-1.1.x of any
JDK 1.1.x for SCO will be unchanged, and you can access its commands by
using a full pathname. For example
/opt/jdk-1.1.8/bin/java will start up the JDK 1.1.8 for
SCO virtual machine.
In addition to the packages in J2SE 1.4.2 for SCO UNIX,
SCO puts out other Java packages
including javaxcomm (Java serial I/O support),
javasoap (Java web services SOAP and XML support),
and javajsse (Java SSL support).
While not part of J2SE, these packages do install
within /usr/java/ because they provide APIs within
the javax extension namespace.
These packages will work together with J2SE 1.4.2 for SCO UNIX.
However, if you already have one or more of them installed in conjunction with
J2SE 1.3.1 for SCO UNIX, and then you install J2SE 1.4.2 for SCO UNIX
(thereby switching the /usr/java/ symbolic link to
/opt/java2-1.4.2/), you will have to re-install these
other packages again. That is because their current actual location
is within /opt/java2-1.3.1/, and thus they will not
be seen within /opt/java2-1.4.2/.
Do not remove these other packages first; just pkgadd
them a second time, and then they will be available for use with
both J2SE 1.3.1 and J2SE 1.4.2 for SCO UNIX.
Instead, you may browse Sun's complete documentation for Java 2 SDK, Standard Edition Version 1.4.2 at http://java.sun.com/j2se/1.4.2/docs/index.html. This contains the very latest and most accurate documentation for J2SE 1.4.2.
The Japanese version of the documentation may be found at http://java.sun.com/j2se/1.4/ja/docs/ja/index.html.
Both the English and Japanese versions of the documentation may be downloaded as a large HTML bundle at http://java.sun.com/j2se/1.4.2/download.html#docs.
Where the documentation differs depending upon the underlying operating system (such as with the SDK tool documentation), follow the "SolarisTM" version (not the "LinuxTM" or "Win32" versions).
Note that there are also useful
Sun and SCO UNIX demonstration uses of
J2SE 1.4.2 and J2SDK 1.4.2 at /usr/java/demo/ when
the j2sdk142 package has been installed.
After the Java 2 SE packages are installed, we recommend that you
set PATH in your .profile startup file
(or whatever startup file is used in your shell)
to include
the directory where the Java 2 commands are installed,
/usr/java/bin .
However, on UnixWare 7 modifying
your startup file may not be necessary, as
login accounts are usually created with /usr/java/bin
as part of the PATH.
SCO has provided a functional extension to the Sun Java 2 SE for use on UnixWare 7.1.3 platforms: Java classes as first-class executables. This extension does not affect the Java 2 APIs; it just affects how Java can be invoked.
When javac is used to compile one or more classes, it
will set the execute permissions bit on for the .class
file if the class contains a main method. (This happens
on all SCO UNIX platforms.)
Then, on UnixWare 7.1.3 you can execute a Java application simply by giving the name of the main class:
These two UNIX releases (and later releases) will look for$ foo.class
foo.class by use of the
PATH environment variable, just as it would for
any other executable. foo.class must also be
in the CLASSPATH, as in normal execution.
Furthermore, by making a hard link or symbolic link such as
you will be able to execute the application simply by saying$ ln -s foo.class foo
This gives you the ability let users invoke utilities without knowing the utilities are written in Java. For this to work you must keep the name prefix intact and the class file intact. That is, you have to keep$ foo
foo.class
somewhere, and then you can make a hard or soft link
of foo to it. foo can be in another directory,
but you can't change
the name; i.e., you can't link bar to it. That's because once the
system invokes the JVM, it expects to find a foo.class file there.
For this same reason you also can't just rename foo.class to
foo, because the JVM will still need a foo.class.
(You could copy foo.class to foo,
but that will of course waste disk space compared to a link.)
Of course, you can always use the traditional way of executing a Java application:
In this case,$ java foo
java must be in the PATH,
and foo.class must be in the CLASSPATH.
A dynamic compiler compiler improves Java performance by, as the program is executing (hence the name), compiling Java method bytecode to native Intel® IA-32 machine code. On subsequent executions of the method the machine code is executed instead of the bytecode being re-interpreted. Thus, a dynamic compiler is a run-time component, not a development component (as conventional language compilers are). Dynamic compilers are a transparent component: they are always there and always executing unless they are explicitly turned off by the user. Dynamic compilers are sometimes referred to as "just-in-time" (JIT) compilers (such as was used in prior classic VM-based J2SE for SCO UNIX implementations).
The HotSpot virtual machine in J2SE 1.4.2 for SCO UNIX
has two dynamic compilers: the client compiler and the server compiler.
They are selected by using -client or -server
as the first option after the java command. The client
compiler is the default.
The client compiler is generally intended for short- to medium-lived applications or for applications where quick start-up time is important; it does compiles quickly, but does not generate the most fully optimized code. The server compiler is generally intended for long-lived applications where start-up time is not an issue; it takes longer to do compiles, but generates the most optimized code.
As with any optimization choice, results will vary with individual applications, so measure both compilers on your application and see which is the more suitable to use.
You do not have read or use any of the information in the rest of this section in order to gain the benefit of the HotSpot dynamic compilers; the information is here only for those wanting a better understanding of what they do, or for those wanting to exercise further control over them, or for those trying to troubleshoot a problem within the VM.
The options described here apply to both the client and the server dynamic compilers:
java -XX:+PrintCompilation option.
java -Xcomp option.
java -Xint option.
java -XX:CompileOnly=name,name,... option,
where the argument is a series of comma-separated
package-name.class-name.method-name names.
java -XX:CompilerThreadPriority=n option,
where n is an operating system priority significantly
higher or lower than the default value of 96.
The HotSpot virtual machine and thus J2SE 1.4.2 for SCO UNIX has only one threads model: "native threads".
"Native threads" refers to a scheme
in which the Java virtual machine creates and
manages Java threads using the operating system threads library - named
libthread
on UnixWare 7 and SCO OpenServer Release ? - and each Java thread is mapped to
one threads library thread.
The user-space "green threads" model found in J2SE 1.3.1 and prior releases for SCO UNIX no longer exists.
The j2sdk142 package must be installed in order to compile
native methods.
C and C++ native methods must be compiled and linked with the UnixWare and OpenServer Development Kit (UDK) from SCO.
This means that native methods cannot be built with the SCO OpenServer Release 5 Development System. Some of the reasons for this requirement include:
long long data type,
to match the Java 64-bit long data type
libC.so) rather than an archive (libC.a)
SCO UNIX-specific
examples of the commands needed to build old- and new-style
native methods with C and C++ are
included in the demos part of the J2SDK 1.4.2 for SCO UNIX distribution
(when the j2sdk142 package is installed), in the directory
/usr/java/demo/native,under the subdirectories
jni_c_demo
jni_c++_demo
jni_invoc_demo.
mk script to run the example.
It is highly recommended that
you follow the command invocations given in all these examples, for unless
the native code is built correctly, it will not work as intended.
Another compiler system that can be used for building native methods is the GNU GCC compiler, described in general at http://gcc.gnu.org.
If JNI code is written in C, the GNU gcc compiler that generates code for the UDK environment may be used.
On UnixWare 7.1.3
this is the GNUgcc package within the
open source OSTools product set
that SCO builds and ships
as part of the UDK CD-ROM.
On SCO OpenServer Release 5, the regular
gcc for OpenServer
cannot be
used; instead, you must build the
OpenServer-hosted, UDK-targeted gcc described at
http://gcc.gnu.org/install/specific.html#ix86-*-udk.
The /usr/java/demo/native directories described above
may also be used to run native methods examples with the GNU gcc compiler.
Pass the option gcc into the
mk scripts.
If JNI code is written in C++, the GNU g++ compiler cannot be used. This is because the HotSpot virtual machine is written in C++ and built with the UDK C++ compiler. Thus, it depends upon the UDK C++ runtime environment. JNI code built by GNU g++ in turn depends upon the g++ runtime environment. These two environments are incompatible within the context of HotSpot and cannot exist within the same process.
Debugging of Java applications is done with the J2SDK-provided
jdb debugger, as described in the relevant Sun
documentation.
Debugging of C or C++ native methods, however, must be done with the UDK debugger. This is also applicable to isolating or troubleshooting potential problems within the JVM itself, since the lower layers of the JVM are implemented in C and C++, not Java.
Core dumps should never occur within Java. If they do, then either there is an application bug in a native method, or there is an internal bug within the JVM, or there is an internal bug within an SCO UNIX operating system library.
If there is a core dump resulting from an application bug in a native method, the JVM will print the message "An unexpected exception has been detected in native code outside the VM." It will then attempt to specify the native code function name and library name that the core dump occurred in, as well as supply a Java-level traceback from that point. This might be enough information to guide you to the source of the problem, but if not, you'll have to look at the core dump.
Java process core dumps can become large; you may need to
set ulimit -c unlimited to avoid having the core file
be truncated (typically to 16 MB). If core files do get truncated,
they will be unreadable by the UDK
debugger.
Once read in by the UDK debugger, core dumps from the JVM will usually have a few levels of signal handlers on the stack subsequent to the actual point of failure. An example would be:
$ debug -ic -c core.17311
Using /usr/java/bin/java as executable
Warning: No debugging information in /usr/java/bin/java
Core image of java (process p1) created
Created core image(s) of 8 thread(s) for process p1
CORE FILE [_kill]
SIGNALED 6 (abrt) in p1.1
0xbff97ffc (_kill+12:) jb 0xa4e
debug> stack
Stack Trace for p1.1, Program java
*[0] _kill(0x439f, 0x6) [0xbff97ffc]
[1] abort(presumed: 0xbfec8270, 0x804ef58, 0xbfde54ec) [0xbffd42fa]
[2] std::abort(void)(0x4, 0x8046114, 0) [0xbfa084ba]
[3] os::abort(int)(presumed: 0x1, 0x804ef58, 0) [0xbfde54e7]
[4] os::handle_unexpected_exception(Thread *, int, unsigned char *, void *)(presumed: 0x80513d0, 0x8, 0xb3885f80) [0xbfde3629]
[5] JVM_handle_solaris_signal(0x8, 0x8046e98, 0x8046a88, 0x1) [0xbfde8a4d]
[6] signalHandler(0x8, 0x8046e98, 0x8046a88) [0xbfde73c1]
[7] _thr_sigacthandler(presumed: 0x8, 0x8046e98, 0x8046a88) [0xbfef5616]
[8] do_some_stl(int)(n=8) [fib.C@45]
[9] Java_nfib_fib(env=0x8051470, cls=0x8047140, n=5) [fib.C@55]
[10] ?() [0xbbc47446]
debug>
The actual point of failure is at frame level [8] in this case.
(The core dump was produced by modifying the jni_c++_demo
native methods demo to do an intentional divide-by-zero.)
Note also
that you may not see the rest of the stack;
it often ends as shown. And if you do see it,
it is just be a bunch of
internal implementation routines inside the JVM (with names like
JavaCalls::call_virtual())
that won't tell you much. In other words, there is no debugging
tool available that will show you both the Java stack and the native
methods stack at the same time.
However,
you can make use of the JVM's Java thread dumps for this purpose.
These are what you see
when a Java process aborts;
you can also get one by doing ^\ (control-backslash) at the
command line as a Java application is running (this is especially useful
if a JVM process is hung, frozen, or looping) or equivalently by sending a
SIGQUIT signal to the process, such as with the
kill -3 command. (You can also get some
of the same information by grabbing with or running under jdb.)
You'll see entries in the Java threads dump like
Full thread dump Java HotSpot(TM) Client VM (SCO-UNIX-J2SE-1.4.2_*FCS-UW7_BETA-OSR5*_20031215 mixed mode):
...
"Thread-4" prio=5 tid=0x0812ad00 nid=0xd runnable [b378c000..b378c9c8]
at TL.foo(threadsloop.java:12)
at TL.run(threadsloop.java:24)
...
When you use the UDK debugger to look at the Java process (either via
a core dump or by grabbing a live process), use the
debugger ps
command to show the threads in the Java process. It will show both
an "ID" for each thread, of the form p1.nn,
and a "Thread" for each thread, which is an integer number that
is the thread_t thread-id in the UnixWare 7 threads library.
The "nid" number in the Java threads dump corresponds to the "Thread" number in the UDK debugger threads dump. From this you can see the "ID" for that thread; that ID is the identification name used in various debugger commands.
So to continue our example from above, one line of the debugger
ps output is:
which since "nid" 13 is "Thread" 13, tells us that Java thread "Thread-4" is the same as debugger thread "p1.9". Now we can use the debuggerdebug> ps Program ID Pid Thread State Function Location Command ... java p1.9 17613 13 Stopped _poll 0xbffc3aec /opt/java2-1.4.2/bin/java threadsloop 6 ...
stack command on that thread:
and voila we have both the Java stack and the native code stack for a given Java thread.debug> stack -p p1.9 Stack Trace for p1.9, Program java *[0] _poll(0xb378e560, 0, 0x2710) [0xbffc3aec] [1] _abi_select(0, 0xbfff8d4c, 0xbfff8d4c, 0xbfff8d4c, 0xb378e7d4) [0xbffc5474] [2] os_sleep(long long, int)(presumed: 0x2710, 0, 0x1) [0xbfde71da] [3] os::sleep(Thread *, long long, int)(0x812a420, 0x2710, 0, 0x1) [0xbfde85ce] [4] JVM_Sleep() [0xbfd666aa]
Of course, to do real native methods debugging you'll want to
run the JVM from within the debugger. To do this you'll need to invoke
the JVM executable directly.
(This is easier than it was in previous releases
of J2SE for SCO UNIX, because as of J2SE 1.4.x there are
no longer .java_wrapper scripts in front of the real executables.)
The basic idea is:
$ debug -ic # or can use graphical version debug> create /usr/java/bin/java my_app ... debug> run debug>
If you do a lot of this kind of debugging it can be useful to set up
an alias in your ~/.debugrc file, which
allows you to define a whole series
of convenience commands to set up a typical JVM debugging session.
An example of a full .debugrc alias
might be look something like:
alias c142 create -f none /opt/java2-1.4.2/bin/java $1 $2 $3 $4 $5 $6 $7 $8 ; set %stack_bounds=no ; signal -i cld poll alrm usr1 ; set %thread_change=ignore ; set %wait=no
The create -f none command tells the debugger to ignore child
processes caused by forks done within the X Window System libraries. The
stack_bounds setting avoids spurious warnings due to dynamically
compiled
code being executed. The signal -i command keeps the debugger
from stopping on innocuous signals that the JVM handles.
System.Properties
can be queried. Here are some of the values that will be returned
by default on all
SCO UNIX platforms:
java.home=/opt/java2-1.4.2/jre java.vendor=The SCO Group, Inc. java.vendor.url=http://www.sco.com/ java.vendor.url.bug=http://www.sco.com/support/ java.version=1.4.2 java.vm.vendor=Sun Microsystems Inc. java.vm.version=SCO-UNIX-J2SE-1.4.2_*FCS-UW7_BETA-OSR5*_20031215 java.class.version=48.0
while here are values that are specific to SCO OpenServer Release 5.0.7:
os.arch=IA32 os.name=OpenServer os.version=5.0.7 java.vm.info=mixed mode
UnixWare 7.1.3:
os.arch=IA32 os.name=UnixWare os.version=7.1.3 java.vm.info=mixed mode
SCO is committed to maintaining Java application compatibility across all platforms. SCO does not superset or subset the Java 2 APIs as defined by Sun.
Java Database Connectivity is a standard SQL database access interface for Java, providing uniform access for Java applications to a wide range of relational databases.
The J2SE API for applications accessing JDBC is the
java.sql package, which is included in J2SE 1.4.2 for SCO UNIX.
This conforms to the latest Sun JDBC 3.0 specification.
This API requires an implementation, including a JDBC driver,
in order to be used.
J2SDK 1.4.2 for SCO UNIX contains a SCO UNIX implementation of JDBC and includes a SCO UNIX JDBC driver. However, this implementation is out-of-date and relies upon a database interface product that is no longer supported. This implementation is only included and described in order to support SCO customers and ISVs who may already be using it. For all others, contact your database vendor or other ISV; they probably have a JDBC implementation for a given database that can be used with J2SE 1.4.2 for SCO UNIX.
This SCO UNIX JDBC implementation in J2SE 1.4.2 for SCO UNIX is compliant with the Sun JDBC 1.2 specification. It is not compliant with the later Sun JDBC 2.0 or current JDBC 3.0 specifications.
There is no need to separately install the SCO UNIX JDBC implementation,
since it is part of the j2sdk142 installation.
The SCO UNIX
JDBC implementation is included in the
/usr/java/jre/lib directory as sqlr.jar.
To use it, include the appropriate path to this jar file in your
CLASSPATH.
Documentation on how to use the SCO UNIX JDBC implementation is
installed as part of the j2sdk142 package and may be read at
file:/usr/java/scojdbc/doc/index.htm. Similarly, examples of how to use
this implementation may be found at
/usr/java/scojdbc/examples/.
This SCO UNIX JDBC implementation is built upon the former SCO, Inc. SQL-RetrieverTM product. It is necessary to separately install the SQL-Retriever product if you are interested in using it. The part of SCO that made SQL-Retriever is now known as Tarantella, Inc. As of April 2001, the SQL-Retriever product has been withdrawn from the market. However additional licenses for existing SQL-Retriever customers are available, new licenses for residual contractual requirements may still be available, and in any case if you already have it installed you can continue to use it. See http://www.tarantella.com/support/faq.html#sqlsupport for more information.
/usr/java/jre/lib/font.properties[.locale]
file of this release of J2SE 1.4.2 for SCO UNIX.
Even for European languages, only a limited number of scalable fonts
is available on SCO UNIX platforms. However, the SCO Open License Software
Supplement has a collection
of freely available X11 fonts in package
freefonts which helps alleviate this problem.
If using the default /usr/java/jre/lib/font.properties, it is necessary that
the Java logical font sansserif.0 or sansserif.plain.0
be specified and
be installed as a font on the X server platform displaying
the graphical user interface of the Java application.
If using any of the other font properties files, it is necessary that
Java logical fonts
serif.0 or serif.plain.0 and
serif.1 or serif.plain.1
are defined in the /usr/java/jre/lib/font.properties[.locale]
file and that they be installed as a font on the X server platform displaying
the graphical user interface of the Java application.
The consequences of missing fonts in Java 2 can be severe. For example,
without package urwfonts the
individual benchmark scores do not appear above their graph bars in
the once-commonly used CaffeineMark benchmark GUI harness. As another example,
the Java2D demo program gets spurious out of memory exceptions,
security exceptions,
and illegal argument exceptions, as well as not
displaying its fonts properly. For these reasons installation of
the urwfonts package
is required for J2SE 1.4.2 for SCO UNIX.
When a Java program requests a particular font of a particular size, Java 2 looks for scalable fonts first. If nothing could match, then Java 2 will try to find the fonts whose sizes and types are as close as possible, including trying the fixed-size fonts if their size is close enough. This, sometimes, could cause the font displayed to look not as you wanted, if no appropriate fonts could be found on the system the Java program is running on.
You may find useful information on these and other font issues from Sun at http://java.sun.com/j2se/1.3/docs/guide/intl/addingfonts.html and at http://java.sun.com/j2se/1.4.2/docs/api/java/awt/Font.html.
xhost +your_machine_name command.
a.out that
does a dlopen of a libuser.so that in turn
invokes the Java virtual machine, will not work. An a.out
that is linked with -luser but not -ljvm -lhpi
that calls a libuser.so that in turn invokes the Java
virtual machine, will also not work. Such an a.out must
always be linked against -ljvm -lhpi itself. (See
/usr/java/demo/jni_invoc_demo for the full set of system
libraries to link against.)
file(1) command
does not correctly recognize Java .class files.
This is not problem with J2SE 1.4.2 per se, but with the underlying
operating system.
MulticastSocket.leaveGroup method may not
relinquish the socket's membership in the group due to some
unknown operating system or hardware related problem.
Rebooting the machine will resolve this behavior.
jdb "run" command does not result in
the program under test starting to run. In this case,
issue a "threads" command, and then a "run" command.
LANG=fr_FR.ISO8859-1. However,
in order for J2SE 1.4.2 to change its default locale to the French one,
it needs for LANG=fr_FR to be set; the fr_FR.ISO8859-1
value will not work. Thus, you should do something like:
when invoking the JVM, to change the$ LANG=fr_FR /usr/java/bin/java my_app
LANG value for the JVM
(but not for any other OpenServer applications).
(This is not a problem with J2SE 1.4.2 per se,
but rather with the different locale setting conventions between UnixWare 7
and SCO OpenServer Release 5, and how those differences are reflected
through the OSRcompat package set.)
java.nio.channels.FileChannel.transferTo
method has the high-performance characteristics suggested by the Sun J2SE
documentation for the case where the target channel is a socket, but
not for the case where the target channel is a file. This is because
the implementation uses the UnixWare 7 sendv() API, which
is supported for file-to-stream writes but not for file-to-file writes.
Warning: Valid documents must have a <!DOCTYPE declaration.
followed by a bunch of errors.
A better XML parser is available from the Java web services package
javasoap that is contained within the SCOx Components CD
available as part of UnixWare 7 Release 7.1.3 Update Packs 3 and 4.
When that package is installed, the Apache Xerces-J Release 1.4.4 parser
(see
http://xml.apache.org/xerces-j/) will be installed.
Apache Xerces-J is installed into the extensions classpath
/usr/java/jre/lib/ext/xerces.jar,
so you do not have to name it on a classpath yourself. Moreover, because
the jar file has a service provider configuration file that
registers itself for the javax.xml.parsers.DocumentBuilderFactory
service, it effectively takes precedence over the J2SE 1.4.2 for SCO UNIX
parser in the bootstrap classpath. Thus, once package javasoap is
installed, Apache Xerces-J will become the XML parser that is used.
javasoap and javajsse
packages contained within the SCOx Components CD. These packages were
made to be used in conjunction with J2SE 1.3.1 for SCO UNIX, and the
following issues arise when using them with J2SE 1.4.2 for SCO UNIX
on UnixWare 7 Release 7.1.3 Update Pack 4
(they will be resolved in time for UnixWare 7 Release 7.1.4):
javasoap package has a dependency on J2SE 1.3.1 for
SCO UNIX package j2jre131 being installed. If J2SE 1.4.2
for SCO UNIX package j2jre142 is also installed, and if
the /usr/java/ symbolic link points to J2SE 1.4.2,
that is okay and javasoap will install into the J2SE 1.4.2
directories, but the j2jre131 package must be on the
system as well.
javasoap package contains a known problem in Apache Axis 1.0
when using with J2SE 1.4.x. It results in a
javax.servlet.ServletContext class not found error when trying
to run a program making SOAP calls. The
solution is to take the servlet.jar library
out of the SCOx Apache Tomcat 4.1.17 distribution (or download it
from an Apache web site) and drop it into the
/usr/java/jre/lib/ext/ directory.
javajsse package should not be installed or used with
J2SE 1.4.2 for SCO UNIX. This is because the J2SE 1.4.x specification
now contains the JSSE functionality within it, and javajsse is no
longer necessary (it is simply an earlier version of the same Sun
implementation). Indeed, installing it would cause harm, because
it will install an out-of-date version of the
/usr/java/jre/lib/security/java.security properties files.
In addition, there is a separate and distinct Java 2 Standard Edition, v. 1.3.1, for Linux implementation available for the Linux Kernel Personality on UnixWare. It too is a full implementation of the Sun Microsystems Java 2 Platform.
On UnixWare 7
when the Linux Kernel Personality feature
is installed, it is possible to run the Java implementation
for Linux
while in UNIX mode.
To do this, access the J2SE 1.3.1 for Linux
implementation through the /linux filesystem, as in this example:
$ /linux/opt/java-1.3.1/bin/java -version java version "1.3.1" Java(TM) 2 Runtime Environment, Standard Edition (build Caldera-1.3.1-02aFCS) Java HotSpot(TM) Client VM (build Caldera-1.3.1_02a-FCS, mixed mode)
(You cannot currently use the more natural /linux/usr/java/bin/java
because of a symbolic link not working across the filesystem divide. Of course,
you can also use the linux command to go into Linux mode,
after which you can access Java using /usr/java/bin/java.)
The J2SE 1.4.2 for SCO UNIX implementation described in these Release Notes may be still accessed as well, in the normal manner.
If native methods are used in conjunction with J2SE 1.3.1 for Linux, they must be built with the GNU GCC compilers present in the Linux distribution. They cannot be built with the UnixWare 7 GCC compilers or with the UDK compilers.
If a third-party J2SE 1.4.x for Linux implementation is installed
on a UnixWare 7 system via LKP, similar considerations apply to the above.
Note however that there are known problems with such third-party
implementations on UnixWare 7 LKP; for example, java.nio
functionality does not work.
The J2SE 1.3.1 for Linux implementation cannot be used on the SCO OpenServer 5 platform; the J2SE 1.4.2 for SCO UNIX implementation described in these Release Notes is the only Java implementation available for SCO OpenServer 5.
Copyright © 2004 The SCO Group, Inc. All Rights Reserved.
SCO, SCO OpenServer, UnixWare, Open UNIX, Caldera are trademarks or registered trademarks of The SCO Group, Inc. in the U.S.A. and other countries.
SQL-Retriever, Tarantella, and Tarantella Enterprise 3 are trademarks or registered trademarks of Tarantella, Inc. in the U.S.A. and other countries.
Sun, Sun Microsystems, Java, Java Development Kit, JDK, JavaBeans, JDBC, and HotSpot are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries, and are used under license.
UNIX and Motif are registered trademarks of The Open Group in the United States and other countries. Intel is a registered trademark of Intel Corporation. Netscape, Netscape Navigator, and Netscape Communicator are registered trademarks of Netscape Communications Corporation in the United States and other countries. NonStop is a registered trademark of Compaq Computer Corporation. X Window System is a trademark of the Massachusetts Institute of Technology. Apache is a trademark of the Apache Software Foundation. IBM is a registered trademark of the International Business Machines Corporation in the United States and other countries. Linux is a registered trademark of Linus Torvalds.
The SCO Group, Inc. reserves the right to change or modify any of the product or service specifications or features described herein without notice. This document is for information only. No express or implied representations or warranties are made in this document.