JDK-4881275 : (reflect) Class.cast() - typesafe cast desired
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.lang:reflect
  • Affected Version: 5.0
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: solaris_8,solaris_9
  • CPU: generic,sparc
  • Submitted: 2003-06-19
  • Updated: 2017-05-16
  • Resolved: 2003-12-19
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availabitlity Release.

To download the current JDK release, click here.
Other
5.0 b32Fixed
Related Reports
Duplicate :  
Relates :  
Relates :  
Relates :  
Description
Date: Fri, 13 Jun 2003 23:37:54 +0400
From: Roman Elizarov <###@###.###>
Subject: JSR14 prototype comments - Class<T> goodies and shortcomings
To: ###@###.###
Reply-to: Roman Elizarov <###@###.###>

Hello!

In short - I'm glad to see variance on board, but there are some
concerns.

It's nice to be able to cleanly express the following method
signatures that happen this or other way all over various libraries in
J2SE and J2EE, like:

javax.rmi.PortableRemoteObject:
  public static <T> narrow(Object o, Class<T> c);

javax.security.auth.Subject:
  public Set<T> getPublicCredentials(Class<T> c);

etc ...

Being declared this way they are much easier to use. Benefits are
immense especially in J2EE (happens all the time). Instead of writing:

MyHome h = (MyHome)narrow(..., MyHome.class);

one is now able to simply write:

MyHome h = narrow(..., MyHome.class);

And it works! But, here's the problem - the following naive
implementation:

static <T> narrow(Object o, Class<T> c) { return (T)o; }

Compiles with "unchecked cast to type T" warning. Moreover, I don't
see how one can implement methods with those signatures without
triggering this warning. It looks like a significant shortcoming in
the type system.

Class<T> construct should actually hint the compiler that T is a
non-generic class type (there's no such thing like Class<Set<String>>,
but only Class<Set>), and thus cast conversion to T shall be allowed
in this context without "unsafe" warning. Of course, it may still
produce ClassCastException, but it is perfectly safe.

If you decide to follow this path, consider also the fact that in the
above context it is also possible to compile expression like "o
instanceof T", which is not valid in the absence of Class<T> c.

Sincerely,
Roman Elizarov


Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: tiger-beta FIXED IN: tiger-beta INTEGRATED IN: tiger-b32 tiger-beta
2004-06-14

PUBLIC COMMENTS ...
2004-06-10

EVALUATION One way of dealing with this would be to move the supposedly unsafe operation into class Class, by adding the following method to Class<T> T cast(Object o); the semantics would be defined as throwing a class cast exception if the object is not an instance of the class, or returning the object as an instance of the class. ###@###.### 2003-06-19 It turns out that this is not typesafe when the class represents a generic type. Therefore, this method is being withdrawn for Tiger. ###@###.### 2004-02-10
2003-06-19