Many thanks for the answer. I did not realize that there was a difference
between the com.sun.* classes and the sun.* classes. Is this in a faq that
I missed?
This is good news :)
Thanks,
Michael P. McCutcheon
----- Original Message -----
From: "Doug Gehringer" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, September 10, 2001 10:34 AM
Subject: Re: [JAVA3D] should we use the com.sun.j3d.* classes?
> > From: "Michael P. McCutcheon" <[EMAIL PROTECTED]>
> > ... I'm confused about using the com.sun.j3d.*
> > classes. It seems that these are not supported given that the
documentation
> > says the following:
> >
> > "In general, writing java programs that rely on sun.* is risky: they are
not
> > portable, and are not supported."
> >
> > However, I just bought two books, Java3D API Jump Start, and Essential
> > Java3D Fast, and they both reference the com.sun.j3d classes from cover
to
> > cover. I have heard that other books are this way as well.
>
> There is a difference between the com.sun.* utilities and the sun.*
internal
> classes. The com.sun packages are external and supported, the sun.*
packages
> are internal and unsupported.
>
> Sun has made the com.sun packages as a supported set of utilities for Java
3D.
> While they are not a part of the Java 3D specification (which defines the
> essential functionality for Java 3D implementations), the utilities
provide
> useful functionality and a stable API. If the utilities are changed or
extended
> in a future release, the changes will be backwards compatible so that
programs
> that used the old versions will still work. For example, Java 3D 1.1
included
> utility packages for picking. Java 3D 1.2 had much improved picking
> functionality in a new interface, but the old 1.1 packages are still
included
> for backwards compatiblity. Bugs can be filed against the utilities, and
the
> utilities are part of the standard installation. For that reason, I
considered
> the utilities as part of the API for the "Java 3D API Jump-Start".
>
> The sun.* packages are internal implementation classes. They are included
in
> the JDK for use by the JDK APIs, but they are not guaranteed to be
supported in
> future releases. Typically, the sun.* classes are functionality that is
not yet
> supported in an offical API. For example, a common use of the sun.*
packages is
> for image encoding. Some of the Java 3D community code for screen capture
uses
> the sun.* packages to encode screen images into JPG files. The problem
with
> unsupported interfaces is exactly as you note:
>
> > "In general, writing java programs that rely on sun.* is risky: they are
not
> > portable, and are not supported."
>
> A future release of the JDK may change or eliminate these packages. In
the case
> of image operators, the better choice is to use the Java Advanced Imaging
(JAI),
> API which is the supported interface for the image functionality in the
sun.*
> packages.
>
> Please use the com.sun.* packages. They are a powerful addition to the
API. If
> you find bugs, report them. Try to avoid using the sun.* packages, instead
look
> for supported APIs like JAI instead.
>
> Doug Gehringer
> Sun Microsystems
>
>
===========================================================================
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the
body
> of the message "signoff JAVA3D-INTEREST". For general help, send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff JAVA3D-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
