Java Technology Home Page
A-Z Index

Java Developer Connection(SM)
Technical Tips

Downloads, APIs, Documentation
Java Developer Connection
Tutorials, Tech Articles, Training
Online Support
Community Discussion
News & Events from Everywhere
Products from Everywhere
How Java Technology is Used Worldwide
Print Button
 
Tech Tips archive

Tech Tips
January 10, 2000

This issue presents tips, techniques, and sample code for the following topics:

This issue of the JDC Tech Tips is written by Glen McCluskey.

These tips were developed using JavaTM 2 SDK, Standard Edition, v 1.2.2.


NARROWING AND WIDENING CONVERSIONS

Suppose you're doing some C or C++ programming, and you have a sequence of statements like this:

    long a;
    short b;

    a = 123456;
    b = a;
What happens? This is probably a programmer error. Here a value (123456) is assigned to a variable (b) that's probably too small to represent it. (This assumes that a value of data type short is 16 bits). C and C++ do not prohibit this operation; the result is implementation-defined. An experiment with a couple of C++ compilers shows a value of -7616 for b.

This usage is illegal in the JavaTM programming language, and it serves to illustrate the way in which the language treats conversions. Specifically, when you convert a larger primitive type (like long) to a smaller primitive type (like short), it requires a cast to be valid. For example:

    b = (short)a;
Converting a large primitive type to a smaller primitive type is called "narrowing primitive conversion". This type of conversion has the potential for some loss of information. That's because all but the lowest bits of data are discarded in the conversion. In this example, the lowest 16 bits are saved, because a short is guaranteed to have exactly 16 bits. By dropping the higher bits of data, you might lose information about the magnitude and precision of the original value. The magnitude is the range of values that a primitive type can represent. For example, if you convert a long to a byte, you'll probably lose magnitude information, because a long can represent a much wider range of values using 64 bits than a byte can using 8 bits.

The idea of precision can be illustrated using float and double. You can represent a value like "pi" with more significant digits if you use a double instead of a float.

In addition to a loss of magnitude and precision, the sign of the converted value can be different than the sign of the original value.

Widening conversions are analogous to narrowing conversions. A widening conversion never loses information about magnitude, but can lose precision. For example, if you convert a long to a float, you might sacrifice precision. A float has 32 bits instead of 64, and uses some of those bits for an exponent. So a float cannot represent all 64 bits of the long value. A float can represent the magnitude of a long, but not necessarily the precision. No cast is required for a widening conversion such as:

    long a;
    float f;

    a = 1234567890;
    f = a;
Narrowing and widening primitive conversions never result in a run-time exception, even in cases where information is lost.

There's a special case known as an "assignment conversion" that handles some conversion cases that would otherwise seem to be illegal, such as:

    byte x;

    x = 59;
In this example, a variable of type byte is being assigned a value of type int. This implies a narrowing conversion. And it's legal if (a) the expression to be assigned (59) is of constant int type, (b) it's being assigned to a variable (x) of type byte, short, or char, and (c) it will fit into the variable without losing any information. In other words, you can assign small integer constants to byte, char, and short variables without worrying about using a cast.

Narrowing and widening conversions also apply to reference types. For example, if you have:

    class A {}
    class B extends A {}

    ...

    A aref = new A();
    B bref = new B();
then usage like:
    aref = bref;
is a widening conversion, and usage such as:
    bref = (B)aref;
is a narrowing conversion. Widening reference conversions never throw a run-time exception, but narrowing reference conversions can throw a ClassCastException for usage like this:
    class A {}
    class B extends A {}
    class C extends A {}

    ...

    B bref = new B();
    A aref = bref;
    C cref = (C)aref;
The variable "aref" references a B, not a C, and an attempt to force the B into a C results in an exception.


USING IMPORT DECLARATIONS

If you've done any amount of Java programming, you've likely used import declarations, of the form:

    import java.util.*;
or:
    import java.util.ArrayList;
These are quite simple in a way, but there are a couple of interesting issues to mention concerning the use of these declarations. The first point is that an import declaration makes a type or set of types available, but doesn't do any textual inclusion of files. By contrast, the C #include directive actually substitutes text into the including file. So that:
    #include <stdio.h>
actually results in a header file stdio.h being inserted into the compilation unit. In Java programming, a corresponding declaration:
    import java.util.ArrayList;
simply says that the class type ArrayList can be used in the program without full qualification (that is, ArrayList instead of java.util.ArrayList).

There's an implicit import declaration:

    import java.lang.*;
assumed at the beginning of a Java compilation unit, just after any package statement in the unit. A wildcard like "*" says "make available all public types from the package", in this case, all types in the package java.lang. Wildcards are never used to import subpackages, so an import like:
    import java.lang.*;
doesn't give you access to the classes in java.lang.reflect, a subpackage of java.lang. You need to say:
    import java.lang.reflect.*;
to access those classes.

What about ambiguities? What if you import two types with the same name from different packages?

    import P1.A;
    import P2.A;
This is invalid usage. However, what if you say instead:
    import P1.*;
    import P2.*;
and both packages P1 and P2 contain an A type? Well, if you don't actually use the A in your program, then it's okay. But if you say:
    A a = new A();
you'll get an ambiguity error. In other words, you get an error if (a) you use a type-import-on-demand declaration (that is, an import declaration using a wildcard), (b) two different packages have types with the same name, (c) you use that type. There is no rule that says "the first one wins".

There are a couple of different styles you can use with imports. Suppose you need to use ArrayList and Vector from java.util. You can say:

    import java.util.*;
or:
    import java.util.ArrayList;
    import java.util.Vector;
These are both "right". The first is terse; you don't have to enumerate all the types you're using. The second makes clear what types you're using in your program, at the expense of some verboseness. The second approach also has a subtle advantage in that it forces a type to be found in a particular package. Here's an example. Suppose you want to use a type A, and you say:
    import P1.*;
    import P2.*;
And you believe that A is found in P1, when it's actually not in P1 but in P2. Explicitly enumerating the types you're using gets around this problem. If you think A is in P1, and you say:
    import P1.A;
and it's not actually there, you'll get a compile error.

Is there any efficiency issue between these two styles? Possibly, but since import declarations don't actually import anything into your program, any difference is very small. Remember that there's an implicit import java.lang.* at the top of your compilation units, and java.lang in JDKTM 1.2.2 contains 75 classes and interfaces. An experiment using a contrived example, one with thousands of class name uses that must be looked up, showed a negligible change in compilation speed. So compilation performance should probably not be considered a factor when choosing one format over another.

There's one final angle of interest on import declarations. Suppose you use an inner class:

    package P;

    public class A {
        public static class B {}
    }
If you want to access A from another compilation unit, you say:
    import P.*;
or:
    import P.A;
But if you'd like to access B without qualification, you need to say:
    import P.A.*;
or:
    import P.A.B;
The first of these makes available types within the class A found in package P. The second makes available just the type B found in class A in package P.

— Note —

The names on the JDCSM mailing list are used for internal Sun MicrosystemsTM purposes only. To remove your name from the list, see Subscribe/Unsubscribe below.

— Feedback —

Comments? Send your feedback on the JDC Tech Tips to: jdc-webmaster

— Subscribe/Unsubscribe —

The JDC Tech Tips are sent to you because you elected to subscribe when you registered as a JDC member. To unsubscribe from JDC email, go to the following address and enter the email address you wish to remove from the mailing list:

http://developer.java.sun.com/unsubscribe.html

To become a JDC member and subscribe to this newsletter go to:

http://java.sun.com/jdc/


Print Button
[ This page was updated: 21-Sep-2000 ]
Products & APIs | Developer Connection | Docs & Training | Online Support
Community Discussion | Industry News | Solutions Marketplace | Case Studies
Glossary | Feedback | A-Z Index
For more information on Java technology
and other software from Sun Microsystems, call:
(800) 786-7638
Outside the U.S. and Canada, dial your country's AT&T Direct Access Number first.
Sun Microsystems, Inc.
Copyright © 1995-2000 Sun Microsystems, Inc.
All Rights Reserved. Terms of Use. Privacy Policy.