Weblogs Forum - Generics and Packages

Articles |
News |
Weblogs |
Books |
Forums

Artima Forums | Articles | Weblogs | Java Answers | News

Sponsored Link •

Weblogs Forum
Generics and Packages

14 replies on 1 page. Most recent reply: Jan 23, 2006 1:00 PM by Brian Goetz

Welcome Guest
Sign In

Back to Topic List

Reply to this Topic

Search Forum

Threaded View


Previous Topic		Next Topic

Flat View: This topic has 14 replies on 1 page

Bruce Eckel

Posts: 875
Nickname: beckel
Registered: Jun, 2003

Generics and Packages (View in Weblogs)

Posted: Nov 10, 2005 6:30 AM

Summary
There appear to be some strange side effects on packages when using generics.

Consider the following file:

package code;

interface HasColor {
  java.awt.Color getColor();
}

class Dimension {
  int x, y, z;
}

class ColoredDimension<T extends Dimension & HasColor> {
  T item;
  ColoredDimension(T item) { this.item = item; }
  T getItem() { return item; }
  java.awt.Color f() { return item.getColor(); }
  int getX() { return item.x; }
}

When you run the compiler, you get the following error message:

GenericsAndPackages.java:17: x is not public in code.Dimension; cannot be accessed from outside package
  int getX() { return item.x; }
                          ^
1 error

Since all the code is in the same package, this is probably a bug. But with generics, it's always hard to tell.

Adam Kiezun

Posts: 4
Nickname: akiezun
Registered: Nov, 2005

Re: Generics and Packages

Posted: Nov 10, 2005 6:47 AM

what's the real declaration of ColoredDimension again?
As posted, it makes no sense.

I think you mean
class ColoredDimension<T extends Dimension & HasColor>
but it's hard to tell.

In the case above, Eclipse's compiler is happy.

Bruce Eckel

Posts: 875
Nickname: beckel
Registered: Jun, 2003

Re: Generics and Packages

Posted: Nov 10, 2005 8:42 AM

Oops. It's fixed now. Pesky angles and ampersands.

Kirk Brown

Posts: 3
Nickname: kdborg
Registered: Nov, 2005

Re: Generics and Packages

Posted: Nov 10, 2005 9:56 AM

In this example, T, cannot be guaranteed to be in the same package. That is why the compilation error occurs.

Making the variable x public gives the correct scope.

Kirk Brown

Posts: 3
Nickname: kdborg
Registered: Nov, 2005

Re: Generics and Packages

Posted: Nov 10, 2005 9:58 AM

..gives the visibility to make that allows the example to compile, I mean.

Terry Cube

Posts: 1
Nickname: tcube2002
Registered: Nov, 2005

Re: Generics and Packages

Posted: Nov 10, 2005 11:14 AM

You always have really interesting topics but your examples are almost always unnecessarily confusing. They would be a lot more effective without methods like public java.awt.Color f(), or one of your previous posts with classes named "HasF" and "Manipulator4". A little more thoughtfulness on class and method naming would go a long way towards more clearly communicating the concepts you're talking about. Reading foo/bar example code is like looking at decompiled class files.

Howard Lovatt

Posts: 321
Nickname: hlovatt
Registered: Mar, 2003

Re: Generics and Packages

Posted: Nov 10, 2005 3:07 PM

The compiler is right, a class derived from Dimension does not have to be in the same package.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Generics and Packages

Posted: Nov 11, 2005 9:15 AM

> In this example, T, cannot be guaranteed to be in the same
> package. That is why the compilation error occurs.
>
> Making the variable x public gives the correct scope.

Why should that matter, though? It works if you get rid of the generic declarations:

interface HasColor {
  java.awt.Color getColor();
}
 
class Dimension {
  int x, y, z;
}
 
class ColoredDimension {
  Dimension item;
  Dimension getItem() { return item; }
  int getX() { return item.x; }
}

But item is still not guaranteed to be of a class declared in the package.

I'm not saying that you are wrong but there is something funny about this. Not matter where T is declared it must be an instance of Dimension, x is declared in Dimension and therefore should be accessible at the package level.

I suppose T could declare it's own x that ColorDimension cannot access but that shouldn't matter because ColorDimension won't know that. Even if a redefined x were avaialble on T, the erasure of T will ensure there is no way it could be accessed.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Generics and Packages

Posted: Nov 11, 2005 11:41 AM

Bruce, compiles without error. It is my feeling that this lends credence to the error being a bug:

interface HasColor {
  java.awt.Color getColor();
}
 
class Dimension {
  int x, y, z;
}
 
class ColoredDimension<T extends Dimension & HasColor> {
  T item;
  ColoredDimension(T item) { this.item = item; }
  T getItem() { return item; }
  java.awt.Color f() { return item.getColor(); }
  int getX() { return ((Dimension) item).x; }
}

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Generics and Packages

Posted: Nov 11, 2005 11:48 AM

interface HasColor {
  java.awt.Color getColor();
}
 
class Dimension {
  int x, y, z;
}
 
class ColoredDimension<T extends Dimension> {
  T item;
  ColoredDimension(T item) { this.item = item; }
  T getItem() { return item; }
  //java.awt.Color f() { return item.getColor(); }
  int getX() { return item.x; }
}

The above should also compile. If the compiler were right, why would this be OK?

Bruce Eckel

Posts: 875
Nickname: beckel
Registered: Jun, 2003

Re: Generics and Packages

Posted: Nov 11, 2005 11:58 AM

> class ColoredDimension<T extends Dimension> {
> T item;
> ColoredDimension(T item) { this.item = item; }
> T getItem() { return item; }
> //java.awt.Color f() { return item.getColor(); }
> int getX() { return item.x; }
> }

Yes, that's correct, this only happens when you have multiple bounds. That's another reason it seems like it should be an error. I should have pointed that out in the posting.

Kirk Brown

Posts: 3
Nickname: kdborg
Registered: Nov, 2005

Re: Generics and Packages

Posted: Nov 11, 2005 4:14 PM

An interesting deviation if you look at the interface HasColor. HasColor has no int variable named x. However, if you add an int x = 5; to the interface HasColor, the original problem compiles.

It would seem like a problem around visibility. Any class that extends Dim could change the visibility of x from package to private. Once that is done, ColoredDimension<> would not be able to see the variable x.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Generics and Packages

Posted: Nov 14, 2005 8:08 AM

> It would seem like a problem around visibility. Any class
> that extends Dim could change the visibility of x from
> package to private. Once that is done, ColoredDimension<>
> would not be able to see the variable x.

That's probably where this issue orignates but it doesn't seem to be a valid issue. If a class extends hasColor and shadows x such that it cannot be reached from the package, why should that keep me from reaching something in the package? If we get rid of the HasColor interface, we can still extend Dimension to shadow x but the compiler doesn't care. Why should it care when there are two super types? Why should the inability to see something that I shouldn't know about keep me from reaching something that I can reach and do know about?

Mohan Radhakrishnan

Posts: 7
Nickname: mindspace
Registered: Oct, 2005

Re: Generics and Packages

Posted: Nov 15, 2005 9:28 PM

The following compiles in eclipse and prints '0'.

package com.test;
 
public class ColoredDimension<T extends Dimension & HasColor> {
 
		T item;
		ColoredDimension(T item) { this.item = item; }
		T getItem() { return item; }
		java.awt.Color f() { return item.getColor(); }
		int getX() { return item.x; }
		
	    public static void main (String[] parameters) {
	    	ColoredDimension<NewDimension> cd = 
	    			new ColoredDimension<NewDimension>( new NewDimension() );
	    	System.out.println( "[" + cd.getX() + "]" );
	    }
}
 
interface HasColor {
	  java.awt.Color getColor();
}
 
class Dimension {
	  int x, y, z;
}
 
class NewDimension extends Dimension implements HasColor{
	
	  int x = 5;
	
	  public java.awt.Color getColor(){
		  return java.awt.Color.RED;
	  }
}

Brian Goetz

Posts: 6
Nickname: briangoetz
Registered: Sep, 2005

Re: Generics and Packages

Posted: Jan 23, 2006 1:00 PM

This does feel like a compiler bug, and I'm not sure what exactly the compiler is confused about, but in any case, there are some awfully questionable things going on in this code example, and the strange behavior goes away when you do something more sensible.

First, the name. ColoredDimension. This is not a "colored dimension", as it is neither a Dimension nor a HasColor. You could implement a ColoredDimension as such:

class ColoredDimension extends Dimension implements HasColor { ... }

with no generics at all.

What ColoredDimension really is is a "colored dimension holder." This may sound like a small nit, but it will be far far less confusing to anyone who wants to read the code (someone already commented on this.)

Second, the use of package-private variables here is extremely confusing. Dimension does not extend HasColor, so clearly you are expecting T to bind to a subclass of Dimension. But Dimension has not been designed for extension! Its fields are package-private, not protected. If you did this, or if Dimension provided getters, the problem goes away. (And clearly it should do one or the other -- the way Dimension works now is suitable only for toy examples.)

Flat View: This topic has 14 replies on 1 page

Previous Topic

Next Topic