Re: Question on nested types

2001-09-18 Thread Bryce McKinlay 

Eric Blake wrote:

So, which do we follow, Sun's behavior or specification?  Behavior-wise,
Classpath is correct because it behaves identically to the JDK;
specification-wise, both libraries are in error by not accepting the
above program as legal, and the fix for Classpath would be simply
renaming Hashtable.Entry to something like Hashtable.HashEntry.

In the past we have made these decisions based on observed behaviour of 
the JDK, even when that behaviour directly contridicts one spec or 
another (the JCL and the online docs contradict each other sometimes too).

In this case I do prefer the existing code simply because using Entry 
makes the code look cleaner and more consise. But, if you think that 
this is a real bug and there is a danger of Sun changing their 
implementation to correct it (highly unlikely would be my guess) ...

regards

Bryce.



___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath

Re: Question on nested types

2001-09-17 Thread Eric Blake 

No, javac and jikes are correct.  Similarly, it is possible for a
private field to hide a visible field:

class A {
  public int i;
}
class B extends A {
  private int i;
}
class C extends B {
  void foo() {
// illegal, i is hidden in B, and A's i is not available
// i++;
  }
}

Also, see
http://www.ergnosis.com/java-spec-report/java-language/jls-8.5-b.html
for an unofficial take on the hole in the JLS.

You're thinking of methods, where it is NOT legal for a method with less
visibility to hide one with more.

Erwin Bolwidt wrote:
 
  import java.util.*;
  class Foo
  {
public static void main(String[] args)
{
  System.out.println(Hashtable.Entry.class == Map.Entry.class);
}
  }
 
 
 I think it is a bug in javac and jikes. Since Hashtable.Entry is private,
 it is not visible to other classes, so it does not hide Map.Entry. So your
 example should work, but the compilers are probably wrong.
 
 It is not so strange though that Hashtable has its own Entry member class,
 because Map.Entry is an interface that still needs to be implemented.

Yes, but the implementation need not be named Entry, so that it does not
hide the inherited Map.Entry.

 
 - Erwin

-- 
This signature intentionally left boring.

Eric Blake [EMAIL PROTECTED]
  BYU student, free software programmer

___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath

Re: Question on nested types

2001-09-17 Thread Erwin Bolwidt 



On Sun, 16 Sep 2001, Eric Blake wrote:

 I just noticed the JDK 1.4 documentation for java.util.Hashtable claims
 that Hashtable inherits the nested type Entry from Map:
 http://java.sun.com/j2se/1.4/docs/api/java/util/Hashtable.html

 This would mean that the following program should be legal, and output
 true:

 import java.util.*;
 class Foo
 {
   public static void main(String[] args)
   {
 System.out.println(Hashtable.Entry.class == Map.Entry.class);
   }
 }

 However, it does not compile against Classpath, since the implementation
 of Hashtable defines a private nested class named Entry which hides
 Map.Entry, and Hashtable.Entry is not accessible (instead of being an
 alias for Map.Entry as the documentation claims).  See JLS 8.5 for the
 specification of nested class hiding.

I think it is a bug in javac and jikes. Since Hashtable.Entry is private,
it is not visible to other classes, so it does not hide Map.Entry. So your
example should work, but the compilers are probably wrong.

It is not so strange though that Hashtable has its own Entry member class,
because Map.Entry is an interface that still needs to be implemented.

- Erwin



___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath

Question on nested types

2001-09-16 Thread Eric Blake 

I just noticed the JDK 1.4 documentation for java.util.Hashtable claims
that Hashtable inherits the nested type Entry from Map:
http://java.sun.com/j2se/1.4/docs/api/java/util/Hashtable.html

This would mean that the following program should be legal, and output
true:

import java.util.*;
class Foo
{
  public static void main(String[] args)
  {
System.out.println(Hashtable.Entry.class == Map.Entry.class);
  }
}

However, it does not compile against Classpath, since the implementation
of Hashtable defines a private nested class named Entry which hides
Map.Entry, and Hashtable.Entry is not accessible (instead of being an
alias for Map.Entry as the documentation claims).  See JLS 8.5 for the
specification of nested class hiding.

But perhaps the bug is in Sun's javadoc.  Notice that the JDK 1.4
classpath will not allow compilation of the example class either.  In
other words, Sun's implementation (without decompiling it to verify)
also seems to have a private nested class Hashtable.Entry which hides
and prevents the inheritance of the public Map.Entry.

So, which do we follow, Sun's behavior or specification?  Behavior-wise,
Classpath is correct because it behaves identically to the JDK;
specification-wise, both libraries are in error by not accepting the
above program as legal, and the fix for Classpath would be simply
renaming Hashtable.Entry to something like Hashtable.HashEntry.

I just submitted a bug report to Sun's website on the matter, but it may
be a while before I get a response.

-- 
This signature intentionally left boring.

Eric Blake [EMAIL PROTECTED]
  BYU student, free software programmer

___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath