JavaTM 2, Standard Edition, v. 1.4.2_03
for SCO® UNIX® Operating Systems
FCS - UnixWare 7.1.4        Beta - OpenServer 5.0.7
Its status is FCS (First Customer Ship) for UnixWare 7.1.4 and UnixWare 7.1.3 Update Pack 4 and Beta for OpenServer 5.0.7 releases.
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.
Supported SCO UNIX platforms:
|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.
urwfonts is available
as part of the UnixWare 7.1.3 and 7.1.4 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 or 7.1.4 and is
downloadable from the
runtime on OpenServer 5.0.7 are the libraries contained in the package set
version 8.0.2 provided along with this release in
the SCO OpenServer Release 5.0.7 Maintenance Pack 2 as the "UDK Compatibility Libraries : UDKcompat - version 8.0.2Ac".
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_FLAGenvironment variable is no longer used.
JVM_USE_RDTSCenvironment variable is no longer used.
| || || |
Distributed applications and database access:
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.
j2jre142 package is by default installed in
/usr/java/, with that actually being a symbolic link
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
pkginfo file and then repackage the
package with a different name. The JRE would then install into
System administrators wanting to do this would
else, modify the value of
basedir there, and then tell
pkgadd to use that alternate file with the
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
package be installed in
and the prerequisite
packages are available on the OpenServer 5.0.7 Supplement 3 CD or
from the "Java 2 Standard Edition, v 1.4.2_xx for SCO UNIX Operating Systems"
on the SCO Products download site at
Software should be installed in the following order:
scoadmin softwareor double-click on the Software Manager icon in the desktop.
mkdir JRE SDKUnwind each tar file into the corresponding subdirectory.
cd JRE; tar -xf ../Java2_JRE_142.VOLS.tarRun the Software Manager with the command:
cd ../SDK; tar -xf ../Java2_SDK_142.VOLS.tar
scoadmin softwareor double-click on the Software Manager icon in the desktop.
If you choose not to install the J2SE 1.4.2 software at that time, you may install them later from the UW 7.1.4 Update CD 2 or the UW 7.1.4 UDK CD. Place either CD into the CD-ROM device and:
pkgadd -d cdrom1 j2jre142
pkgadd -d cdrom1 j2sdk142
/usr/javasymbolic link will be set to point to
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
urwfontspackage would have been install during UW 7.1.3 Initial System Load (ISL). If you do not currently have
urwfontson your system, selecting installation of the J2SE 1.4.2 packages will cause
urwfontsto be installed prior to installation of the
While the J2SE is accessed through the
installation actually places its contents into
Then a symbolic link is made from
For compatibility with older J2SE for SCO releases, a symbolic link is
also made from
Thus, for example, you may invoke the Java virtual machine with either
/usr/java/bin/java or the command
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/java2) symbolic link from
/opt/java2-1.3.1 (the actual installation point of J2SE 1.3.1)
/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
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
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
In this case, the install will notify you of the potential conflict,
and give you a choice of whether you want
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
(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
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
javaxcomm (Java serial I/O support),
javasoap (Java web services SOAP and XML support),
javajsse (Java SSL support).
While not part of J2SE, these packages do install
/usr/java/ because they provide APIs within
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
/opt/java2-1.3.1/, and thus they will not
be seen within
Do not remove these other packages first; just
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 " 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
j2sdk142 package has been installed.
After the Java 2 SE packages are installed, we recommend that you
PATH in your
.profile startup file
(or whatever startup file is used in your shell)
the directory where the Java 2 commands are installed,
However, on UnixWare 7 modifying
your startup file may not be necessary, as
login accounts are usually created with
as part of the
SCO has provided a functional extension to the Sun Java 2 SE for use on UnixWare 7 platforms: Java classes as first-class executables. This extension does not affect the Java 2 APIs; it just affects how Java can be invoked.
javac is used to compile one or more classes, it
will set the execute permissions bit on for the
file if the class contains a
main method. (This happens
on all SCO UNIX platforms.)
Then, on UnixWare 7 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.classby use of the
PATHenvironment variable, just as it would for any other executable.
foo.classmust 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.classsomewhere, and then you can make a hard or soft link of
foocan be in another directory, but you can't change the name; i.e., you can't link
barto it. That's because once the system invokes the JVM, it expects to find a
foo.classfile there. For this same reason you also can't just rename
foo, because the JVM will still need a
foo.class. (You could copy
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
javamust be in the
foo.classmust be in the
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
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: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
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.
j2sdk142 package must be installed in order to compile
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 longdata type, to match the Java 64-bit
libC.so) rather than an archive (
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
j2sdk142 package is installed), in the directory
/usr/java/demo/native,under the subdirectories
mkscript 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 and 7.1.4
this is the
GNUgcc package within the
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
used; instead, you must build the
gcc described at
/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
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
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
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
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 * _kill(0x439f, 0x6) [0xbff97ffc]  abort(presumed: 0xbfec8270, 0x804ef58, 0xbfde54ec) [0xbffd42fa]  std::abort(void)(0x4, 0x8046114, 0) [0xbfa084ba]  os::abort(int)(presumed: 0x1, 0x804ef58, 0) [0xbfde54e7]  os::handle_unexpected_exception(Thread *, int, unsigned char *, void *)(presumed: 0x80513d0, 0x8, 0xb3885f80) [0xbfde3629]  JVM_handle_solaris_signal(0x8, 0x8046e98, 0x8046a88, 0x1) [0xbfde8a4d]  signalHandler(0x8, 0x8046e98, 0x8046a88) [0xbfde73c1]  _thr_sigacthandler(presumed: 0x8, 0x8046e98, 0x8046a88) [0xbfef5616]  do_some_stl(int)(n=8) [fib.C@45]  Java_nfib_fib(env=0x8051470, cls=0x8047140, n=5) [fib.C@55]  ?() [0xbbc47446] debug>
The actual point of failure is at frame level  in this case.
(The core dump was produced by modifying the
native methods demo to do an intentional divide-by-zero.)
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
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.
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
The "nid=0xd" contains the "native id" or thread number (decimal 13 in this case), and is your link between this dump and what the UDK debugger produces.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
command to show the threads in the Java process. It will show both
an "ID" for each thread, of the form
and a "Thread" for each thread, which is an integer number that
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 ...
stackcommand 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 * _poll(0xb378e560, 0, 0x2710) [0xbffc3aec]  _abi_select(0, 0xbfff8d4c, 0xbfff8d4c, 0xbfff8d4c, 0xb378e7d4) [0xbffc5474]  os_sleep(long long, int)(presumed: 0x2710, 0, 0x1) [0xbfde71da]  os::sleep(Thread *, long long, int)(0x812a420, 0x2710, 0, 0x1) [0xbfde85ce]  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
.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
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
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
code being executed. The
signal -i command keeps the debugger
from stopping on innocuous signals that the JVM handles.
System.Propertiescan 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
os.arch=IA32 os.name=UnixWare os.version=7.1.4 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
The SCO UNIX
JDBC implementation is included in the
/usr/java/jre/lib directory as
To use it, include the appropriate path to this jar file in your
Documentation on how to use the SCO UNIX JDBC implementation is
installed as part of the
j2sdk142 package and may be read at
/usr/java/scojdbc/doc/index.htm. Similarly, examples of how to use
this implementation may be found at
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
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
are defined in the
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,
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,
and illegal argument exceptions, as well as not
displaying its fonts properly. For these reasons installation of
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.outthat does a
libuser.sothat in turn invokes the Java virtual machine, will not work. An
a.outthat is linked with
-ljvm -lhpithat calls a
libuser.sothat in turn invokes the Java virtual machine, will also not work. Such an
a.outmust always be linked against
-ljvm -lhpiitself. (See
/usr/java/demo/jni_invoc_demofor the full set of system libraries to link against.)
file(1)command does not correctly recognize Java
.classfiles. This is not problem with J2SE 1.4.2 per se, but with the underlying operating system.
MulticastSocket.leaveGroupmethod 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_FRto be set; the
fr_FR.ISO8859-1value 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
LANGvalue 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
java.nio.channels.FileChannel.transferTomethod 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
available as part of UnixWare 7 Release 7.1.3 Update Packs 3 and 4 and
UnixWare 7 Release 7.1.4.
When that package is installed, the Apache Xerces-J Release 1.4.4 parser
http://xml.apache.org/xerces-j/) will be installed.
Apache Xerces-J is installed into the extensions classpath
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
service, it effectively takes precedence over the J2SE 1.4.2 for SCO UNIX
parser in the bootstrap classpath. Thus, once package
installed, Apache Xerces-J will become the XML parser that is used.
Note that once the Apache Xerces-J Release 1.4.4 parser is installed there are several JCK tests that are known to fail. These tests pass if the newer Apache Xerces2 Java Parser Release 2.6.2 is installed instead. However the Xerces2 parser has not yet been integrated into the Java web services packages or the SCOx Components.
javasoappackage has a known problem with a missing class, and because that CD's
javajssepackage is obsolete and harmful. Instead, the SCOx Components should be used that are provided with UnixWare 7 Release 7.1.3 Update Pack 4 and UnixWare 7 Release 7.1.4.
The J2SE 1.4.2 for SCO UNIX implementation described in these Release Notes may be still accessed as well, in the normal manner.
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.
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.