[JSR308] Raw Types and AnnotatedTypeFactory

[Michael Ernst]

Niko-

My apologies, your message seems to have fallen through the cracks.

> Currently, when the JSR308 framework encounters raw types, it attempts  
> to create a corresponding generic type so as to hide the "raw-ness"  
> from the rest of the system.  It does by introducing the type bounds  
> as arguments.  For example, a reference to "Class" would become  
> "Class<Object>".  Clearly, though, such a type does not behave the  
> same as "Class" in every case-- indeed, I believe that there is no  
> generic type that could do so.  To that end, I think it would make  
> sense to leave raw types as raw (i.e., with no type arguments), and  
> adjust code in the various checkers to handle raw types.
> 
> First, do others agree that this makes sense?
> 
> Second, would this require far-reaching changes in the framework?  As  
> I am trying to use my checker on some raw-typed code, I intend to give  
> it a try and see what breaks, but I'd appreciate any obvious  
> warnings.  If I do get it to a stable state, I can send along the  
> patch if it is of interest.  Of course, I might find it easier to  
> generify the code in question...

This does makes sense, but I am not sure what will break.  Some parts of
the framework might assume that types are generic rather than raw.  (For
example, will resolution of generic methods still work?  Maybe or maybe
not.)

Addressing this has not been a priority for us.  We think that proper use
of generics is important to type safety, so we wish to encourage it.  We
expect that people who are willing to run a pluggable type-checker will be
willing to first ensure type-safety with respect to Java's built-in type
system (including generics).  And, our implementation (of both the Checker
Framework and of the checkers themselves) is made simpler by assuming that
there are no raw types.

So, our preference would be to retain the assumption.  If there are
compelling reasons to handle raw types more completely, then we will do so.
What are your thoughts?


> Finally, even if the current behavior were preserved, I don't believe  
> the code as written would work correctly in the face of fully "F- 
> polymorphic" bounds (i.e., a class definition like "class C<X, Y  
> extends X>").  If I understand correctly, such a type would become  
> something like "C<Object, X>", where X is not necessarily in-scope at  
> the point being type-checked.

This is a bug.  Thanks for pointing it out!  We'll fix it.

                    -Mike