Forum Stats

  • 3,872,118 Users
  • 2,266,382 Discussions
  • 7,911,052 Comments

Discussions

Categories

bytecode

843793
843793 Member Posts: 41,732 Green Ribbon
edited Jul 11, 2002 5:08AM in Generics
Is anybody seriously considering any changes to the bytecode to support generic run-time type checking, or are you all committed to making it bytecode-compatible by preprocessing out to the existing Java syntax?

Or are you all too drunk to care?
· Share on TwitterShare on Facebook
«1

Comments

  • 843793
    843793 Member Posts: 41,732 Green Ribbon
    What changes to the bytecode would you consider?

    I don't think bytecode changes would help, because generics does not mean run-time type checking. It means compile-time type checking. Java has always had run-time type checking.

    Since generics is really a compile-time feature, I don't see how changing the bytecode would help.
    · Share on TwitterShare on Facebook
  • 843793
    843793 Member Posts: 41,732 Green Ribbon 
    if ( numbers instanceof List <Integer> ) ...
    That line of code makes perfect sense to me, but not to a compile-time generic system - it can only be checked by keeping some generic information (the specific parameterized class) with the object at run-time.

    That could be done without changes to the bytecode, of course - but it would be more complicated, and less compatible with non-generic code.
    · Share on TwitterShare on Facebook
  • 843793
    843793 Member Posts: 41,732 Green Ribbon
    NextGen is an extension of Generic Java that I believe does what you want. The article I've repeatedly linked to in other threads compares GJ, NextGen, and PolyJ (which does need bytecode support).

    If you're concerned about compatability, I would think that you would not want the bytecode to change, because new bytecode would not run on old JVMs.

    If you read the comparison of the different generic type systems, and you really think you have a better way of implementing them in Java, please do share them, with enough details that an expert programmer could implement a compiler and JVM. I'm sure lots of people would be very interested in these details.
    · Share on TwitterShare on Facebook
  • 843793
    843793 Member Posts: 41,732 Green Ribbon
    I don't know what a better system might be, but i'm sure one must exist.

    Tell me... compiler aside, do any of you know how flexible the underlying runtime is? Specifically, could it be tricked into creating classes on the fly with a strange custom ClassLoader?
    · Share on TwitterShare on Facebook
  • 843793
    843793 Member Posts: 41,732 Green Ribbon
    You don't know what it is, but you're sure it must exist? Let me guess... you've never taken a logic class or been involved in debate?

    Maybe you could some up with an argument that's just a little bit more convincing than that!? I don't know what it is, but I'm sure it must exist! ;-)

    Seriously, yes, you can dynamically create classes with a custom classloader. It needn't even be strange, for some definition of "strange".
    · Share on TwitterShare on Facebook
  • 843793
    843793 Member Posts: 41,732 Green Ribbon
    (must... control... hand... of... death...)

    I have a computer science degree, of which the logic bits were my highest grade.

    While at Uni i argued in lots of debates, the official kind as well as the random stranger kind, and won quite a few of them. My favourite memory is of the debate "This house believes people in the public eye should have better morals." I opposed this, and won - quite resoundingly.

    However, my programming approach has always been at least partly one of 'feel'. I try to develop and follow intuitions and instinctive understandings of subjects, rather than relying only on what could be proved. It generally leads to better answers quicker. Object orientation is one such area - from the approach of a turing machine, it helps nothing. But it does help human programmers. Generics are the same.

    And in this case, my instincts are telling me that there is a more elegant and effective solution than either erasing generics when you compile, or create a million and one extra static classes to fill in the gaps.
    · Share on TwitterShare on Facebook
  • 843793
    843793 Member Posts: 41,732 Green Ribbon
    How about some hidden code.

    E.g.,

    class X<class T>
    {
    ���T a;
    ���T b;

    ���X(T a,T b)
    ���{
    ������this.a=a;
    ������this.b=b;
    ���}

    ���T greater()
    ���{
    ������if (a.hashCode()==b.hashCode())
    ���������return a;
    ������return b;
    ���}
    }

    becomes:

    class X
    {
    ���Object a;
    ���Object b;
    ���Class __type;

    ���X(Object a,Object b)
    ���{
    ������checkType(a);
    ������checkType(b);
    ������this.a=a;
    ������this.b=b;
    ���}

    ���Object greater()
    ���{
    ������if (a.hashCode()==b.hashCode())
    ���������return a;
    ������return b;
    ���}
    }

    This is in the same vein as the operator overloading for Strings, i.e:

    a+b gets converted to new StringBuffer(a).add(b).toString();

    I don't think this would have any negative effects anywhere (apart from reflection). I may be wrong. Please don't flame me if I'm wrong ;)
    · Share on TwitterShare on Facebook
  • 843793
    843793 Member Posts: 41,732 Green Ribbon
    How about some hidden code.
    But the hidden code causes type errors to be discovered at run time, not compile time. Because generics are all about discovering the errors at compile time, this hidden code is not an effective replacement for generics.
    · Share on TwitterShare on Facebook
  • 843793
    843793 Member Posts: 41,732 Green Ribbon
    As I understand it, the compiler already simulates certain runtime actions. For example:

    if( false) {
    System.out.println( "Trace!");
    }

    looks like a run-time statement, but it is actually resolved at compile time -- no code for the System.out.println is generated.

    Could generic code be handled in the same way, using the existing Java syntax, with reserved words that would cause the compiler to anticipate the run-time processing? For example, the Collections classes might contain a method called setType( class). The compiler would treat "setType" not as an actual method, but as a generic specification.

    · Share on TwitterShare on Facebook
  • 843793
    843793 Member Posts: 41,732 Green Ribbon
    As I understand it, the compiler already simulates certain runtime actions. For example:



    if( false) {

    System.out.println( "Trace!");

    }



    looks like a run-time statement, but it is actually resolved at compile time -- no code for the System.out.println is generated.



    Could generic code be handled in the same way, using the existing Java syntax, with reserved words that would cause the compiler to anticipate the run-time processing? For example, the Collections classes might contain a method called setType( class). The compiler would treat "setType" not as an actual method, but as a generic specification.



    · Share on TwitterShare on Facebook
This discussion has been closed.