Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsWhite Papers
Discussion GroupsFirst AidDatabasesJavaBeansGUIJava 3DVirtual MachineCORBASecurityToolsGeneral
Java DirectoryOpen Source ProjectsSample Book ChaptersUser GroupsWeb Resources
Related Topics
Databases.NETMore Topics ...

Java Forum / General / November 2005

Tip: Looking for answers? Try searching our database.

And yet another generics question

Thread view: 
Chris Uppal - 02 Nov 2005 16:30 GMT
Can anyone explain to me why:

   class Test<X>
   {
        static X x() { return null; }    // line 3
   }

provokes the compiler to issue an error message:

   Test.java:3: non-static class X cannot be referenced from a static context

Pointers to the JLS, to the bug parade, or a justification for what looks like
craziness to me, would be equally welcome...

   -- chris
Ingo R. Homann - 02 Nov 2005 16:32 GMT
Hi,

> Can anyone explain to me why:
>
[quoted text clipped - 11 lines]
>
>     -- chris

A static function does not belong to an instance. But the type-parameter
<X> is bound to an instance.

Perhaps you are looking for this:

  class Test
  {
       static <X> X x() { return null; }
  }

Hth,
Ingo
Ian Pilcher - 02 Nov 2005 17:18 GMT
> A static function does not belong to an instance. But the type-parameter
> <X> is bound to an instance.

For example:

   public static void main(String[] args)
   {
       Test<String> stringTest = new Test<String>();
       Test<Integer> intTest = new Test<Integer>();

       Test.x();    //  What type is this supposed to return?
   }

> Perhaps you are looking for this:
>
>   class Test
>   {
>        static <X> X x() { return null; }
>   }

That won't work, because the compiler has no way to know what X is.
You need:

   class Test
   {
       static <X> X x(Class<X> cls)
       {
           return null;
       }
   }

Signature

========================================================================
Ian Pilcher                                        i.pilcher@comcast.net
========================================================================

Ingo R. Homann - 02 Nov 2005 17:30 GMT
Hi,

>>Perhaps you are looking for this:
>>
[quoted text clipped - 4 lines]
>
> That won't work, because the compiler has no way to know what X is.

Of course it works (Eclipse 3.1 compiles it). You can call it like this:
 'Test.<String>x();' or this: 'String s=Test.x();' which infers String
as the proper type.

If you just call 'Test.x();' it just returns null and the result is
referenced nowhere. So there is no type to be inferred.  It's like as if
you just wrote 'null' and ask which type it has. :-)

Ciao,
Ingo
Ian Pilcher - 02 Nov 2005 18:56 GMT
> Of course it works (Eclipse 3.1 compiles it). You can call it like this:
>  'Test.<String>x();' or this: 'String s=Test.x();' which infers String
[quoted text clipped - 3 lines]
> referenced nowhere. So there is no type to be inferred.  It's like as if
> you just wrote 'null' and ask which type it has. :-)

Serves me right for posting without trying it.

Signature

========================================================================
Ian Pilcher                                        i.pilcher@comcast.net
========================================================================

Chris Uppal - 03 Nov 2005 10:15 GMT
> A static function does not belong to an instance. But the type-parameter
> <X> is bound to an instance.

But that's only repeating my question in different words.  I'm looking for any
sort of justification for what appears (to me) to be an absurd restriction.

/Why/ is the type parameter only "available" to instance-side code ?  What
possible advantage does that give, either to the semantics of the language, or
to the implementations ?  /I/ cannot think of any at all, but maybe I'm missing
something.

   -- chris
Ingo R. Homann - 03 Nov 2005 11:01 GMT
Hi,

>>A static function does not belong to an instance. But the type-parameter
>><X> is bound to an instance.
[quoted text clipped - 6 lines]
> to the implementations ?  /I/ cannot think of any at all, but maybe I'm missing
> something.

There is no advantage, but there is simply no alternative!

OK, consider, you would have a class like this:

class Test<X> {
  static X x;
}

Now, you can instantiate some classes:

Test<String> s=new Test<String>();
Test<Integer> i=new Test<Integer>();

Now, if you wrote "Test.x" somewhere else in your code (not necessarily
in class Test), what type would you expect it to be - String or Integer?

Or do you want Java to have multiple instances of the static variable x
(one of String, one of Integer, ...), so that you can write the following:

class Test<X> {
  static X x;
  void foo(X x2) {
    x=x2;
  }
}

Then, there is a problem with javas implementation of generics which
uses type erasure. I agree that type erasure is a non optimal
implementation, but if you want to have backward-compatibility to old
java-code, there is no better solution, I think.

Ciao,
Ingo
Chris Uppal - 03 Nov 2005 12:39 GMT
> class Test<X> {
>    static X x;
> }

Ah yes.  I'm with you now, thanks.  I was thinking solely in terms of static
methods, forgetting entirely about static fields.  Silly me...

<ponders>
Would it have been better to forbid only static fields, I wonder ?  That would
certainly be more irregular that forbidding static members altogether, but
generics are so irregular anyway, that the incremental downside might have
been smaller than the gain.
</ponders>

Cheers.

   -- chris
Ingo R. Homann - 03 Nov 2005 13:21 GMT
Hi,

>>class Test<X> {
>>   static X x;
>>}
>
> Ah yes.  I'm with you now, thanks.  I was thinking solely in terms of static
> methods, forgetting entirely about static fields.  Silly me...

IMHO, the problem with static fundtions is the same as with static
methods! (But there is a solution for that, as I mentioned.)

Ciao,
Ingo
John C. Bollinger - 04 Nov 2005 03:21 GMT
>> A static function does not belong to an instance. But the type-parameter
>> <X> is bound to an instance.
[quoted text clipped - 6 lines]
>to the implementations ?  /I/ cannot think of any at all, but maybe I'm missing
>something.

And in a more recent post Chris wrote:
> <ponders>
> Would it have been better to forbid only static fields, I wonder ?  That would
> certainly be more irregular that forbidding static members altogether, but
> generics are so irregular anyway, that the incremental downside might have
> been smaller than the gain.
> </ponders>

I am a rank amateur when it comes to type theory, but in my limited
understanding of the subject I am going to suggest that you are
commingling the distinct concepts of a type /parameter/ and its
corresponding type /argument/, and perhaps overlooking the (now
stronger) differences between class and type.  Type parameters are
properties of a generic class, just as static members are, but the
corresponding type arguments bound to those parameters are properties of
particular type instances (by which I am referring to types, not
objects).  It is not the type parameters that are inaccessible to static
methods, but rather the type arguments.

Granted, that's a somewhat hand-waving argument.  You could imagine
binding a type argument at the point of invocation, something like this:

    Test<X>.x();

But if you need to do that, then it is no less work than Ingo's
suggestion to use a generic method instead, whose invocation would look
like this (without type inference):

    Test.<X>x();

Furthermore, the first alternative (type parameter usable by static
methods) runs into all the normal confusion with invocation of static
methods on references, but compounded by the fact that the relevant type
argument is not that of the reference's type (to the extent that that
exists in the presence of type erasure), but rather that of the
expression's type.

Signature

John Bollinger
jobollin@indiana.edu

Chris Uppal - 04 Nov 2005 12:09 GMT
> I am a rank amateur when it comes to type theory, but in my limited
> understanding of the subject I am going to suggest that you are
[quoted text clipped - 6 lines]
> objects).  It is not the type parameters that are inaccessible to static
> methods, but rather the type arguments.

That's nicely put.  I'm not yet convinced, but I suspect I might become so as I
ponder the matter further...

Incidentally, this came up as a result of my trying to feed the compiler with
something roughly like:

   class Thing<X>
   {
       static class Helper
       implements Set<X>
       {
           ...
       }

       private final Set<X> m_data = new Helper<X>();
   }

and having the compiler spit it back at me.

   -- chris
Andrea Desole - 03 Nov 2005 10:51 GMT
> Pointers to the JLS, to the bug parade, or a justification for what looks like
> craziness to me, would be equally welcome...

From

http://java.sun.com/docs/books/jls/third_edition/html/classes.html#8.1.2

<quote>
It is a compile-time error to refer to a type parameter of a class C
anywhere in the declaration of a static member of C or the declaration
of a static member of any type declaration nested within C. It is a
compile-time error to refer to a type parameter of a class C within a
static initializer of C or any class nested within C.
</quote>

For the justification, I'm not sure but maybe it can be because of
static members.
If I have

class MyClass<C>
{
    private static Vector<C> myVector;
}

the vector can be once a vector of integers, once a vector of strings.
And we are talking always about the same vector


Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2009 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.