Forum Stats

  • 3,873,239 Users
  • 2,266,523 Discussions
  • 7,911,480 Comments

Discussions

bytecode

2»

Comments

  • 843793
    843793 Member Posts: 41,732 Green Ribbon
    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.
    The hidden code just describes what bytecode will be generated. At compile-time, you can still have the information about a class' type, e.g.: it will be possible to check at compile-time that List<String> only accepts Strings.

    However, it is possible to produce Java .class files without using the Java compiler. Although this isn't common, it is possible, so the checks must also be done at runtime. My code was simply a suggestion of how to turn the List<String> into standard Java code (i.e., without the generics) by the compiler, so it could be compiled into standard Java bytecode, with no extensions, while keeping runtime checks.

    Re the setType 'method', it is not a good idea generally to use keywords in the same way as method calls, this is confusing. The syntax a.b(c) should always mean a method call, special cases just complicate matters. The C++ way works fine for templates, just using List<String>.
  • 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.
    I don't like the idea of addiing generics to java which is essentially adding a pre-processor which java has successfully avoided up until now :( However, I fail to see why this would cause a problem for the compiler? List <Integer> would be replaced at compile time by the actual class that implements the template.

    What did I miss?

  • 843793
    843793 Member Posts: 41,732 Green Ribbon
    You missed that the Java generics proposal is very different to templates in C++. The runtime class which implements List<Integer> is List (as is the runtime class for List<anythingElse>).
  • 843793
    843793 Member Posts: 41,732 Green Ribbon
    You missed that the Java generics proposal is very
    different to templates in C++. The runtime class which
    implements List<Integer> is List (as is the runtime
    class for List<anythingElse>).
    If this be the case, then how is this saving anything? Their will invariably be just as much typecasting as before. Now the typecasting will be compiled in and be inbetween your List<Integer> class and the actual implementing List class.

    What does this save?
  • 843793
    843793 Member Posts: 41,732 Green Ribbon
    In Java, new classes can generally be loaded in at runtime.

    In C++, everything is compiled in, it is less dynamic.

    Having compile-time templates in Java would make runtime use of the objects difficult.

    What I suggested was to make templates a run-time thing, so that new templates can be created all the time.

    Also, don't fool yourself about the casting:

    String x="Hello" involves a type check.

    Object x="Hello" involves a type check. Type casting is no more expensive (DISCLAIMER: as far as I know) than assignment in Java.

  • 843793
    843793 Member Posts: 41,732 Green Ribbon
    Well I understand the Generics now, and I realize its basically saving time. So its not magical but I would use it and it will be a welcome addition.

    However, I still fail to see how this proposes any runtime challenges. and I dont see the difficulty in the instanceof example since it can simply replace the Genericed class with its true class.

    I dont believe for one minute that

    String x = "hello";

    will involve ANY type checking. That would be an incredible waste of time since the compiler knows. Ok, maybe the compiler is doing type checking, but im not interested in compile time/duration. Their should be no type checking of that statement at runtime. the JVM should trust the compiled code shouldn't it?

    Type checking is not the issue for me anyway, its type casting.
  • 843793
    843793 Member Posts: 41,732 Green Ribbon
    All code is type checked at verification time. The JVM doesn't trust any code. This is the beauty of Java -- the JVM can download code from an untrusted source and guarantee that it doesn't overwrite memory, read from memory that it doesn't own, or attack a foreign system in many other ways. This checking is done only when a class is loaded, so it doesn't significantly impact the speed of the program.

    You can read Programming for the Java Virtual Machine for more details on bytecode verification.
  • 843793
    843793 Member Posts: 41,732 Green Ribbon
    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?
    The short answer is yes, it is being investigated.
    I will be surprised if the additional expresiveness
    proves worth the loss of runtime performance.
  • 843793
    843793 Member Posts: 41,732 Green Ribbon
    If the generic type constraints are available at runtime, then while checking them might initially reduce performance, it might also allow the JIT to optimise or even eliminate many casting operations. By generating seperate methods for different generic instantiations (hot spots only) the JIT might find more opportunities for inlining and other performance enhancements.
    So the real cost of runtime generic type information could be very small or even negative.
This discussion has been closed.