4 ms·

Well, you're right that JS JITs can only infer type information via heroic efforts, but AFAIK the Java compiler throws away any type information from the source

Well, you're right that JS JITs can only infer type information via heroic efforts, but AFAIK the Java compiler throws away any type information from the source code, which means that the JVM JIT needs to inver type information again from the byte code. Still, the JVM JIT is faster than JS due to reasons explained in the sibling comment of the parent one.

BorisTheBrave 7y ago
This is not true, bytecode stores fields and classes as fully qualified strings: https://stackoverflow.com/a/17406592 https://stackoverflow.com/a/17406592
pdpi 7y ago
> but AFAIK the Java compiler throws away any type information from the source code You're thinking about generics. .class files preserve a whole bunch of type information (I'm building a .class decompiler in my free time, and I'm looking at that very same data in my debugger ATM).
- The_Colonel 7y ago
  You probably know this, but it's not obvious to the random reader. Even generic types are available in the Java .class file and are accessible from the reflection API. Spring for example uses this quite heavily.
  - cogman10 7y ago
    It depends on where you are at. Type information is present in fields and class inheritance For example, a class like this `class Foo implements Bar<String>` Retains the fact that the generic type is a String. That information is completely lost at method invocation. So a method that takes a `Bar<String>` ultimately compiles to a method that takes a `Bar` and knows nothing of the String. To get that generic information down you have to engage in some fun tricks using either the class or field method I mentioned earlier. (Usually you do this with a second type parameter where it matters).
imtringued 7y ago
Java is only throwing generic type information away in the declaration of classes and methods. The code that is accessing generic types is compiled with casts to the expected type. List<String>.get(1) will generate a cast to String therefore nothing is actually missing in the generated code. It is only missing when you use reflection to e.g. deserialize a List via Jackson by passing List<String>.class. That unfortunately won't work because the generic type parameter is not part of the declaration, only the generated code.
pizlonator 7y ago
Java JITs don’t throw away type information. The bytecode carries strong types, though you have to do some work to get them out (some abstract interpretation). But that’s something you can do statically; no need for profiling or speculation. In JS you can only get the types by profiling.
- titzer 7y ago
  Generics are erased in Java. Not so in the CLR.
  - pizlonator 7y ago
    Yeah but the thread is about types, not generic types specifically. Also it’s not really true that genetics are erased. There’s that horrible thing javac does so that the VM can support reflection for generics. I get your point though.
    - titzer 7y ago
      Do you mean the passing of classes as additional arguments? I haven't seen the horrible thing. Overall I think C# got this one right. Generics are right there in the binaries. bUt ActuALLy, I think the rightest right thing is to do specialization up to representation at link time (or compile time), when the whole program is available, ala MLton. Virgil does this. Of course this is not possible in a dynamic code loading environment but I only have so many fucks to give in this life.
      - pizlonator 7y ago
        No, I meant that the Class format has metadata about what the genetics were so some java.lang.reflect thing can query about what the genetic type was. I don’t think it comes with soundness guarantees. I agree C# got this right. I agree that doing specialization up to link time is ideal from a certain standpoint.
  - username90 7y ago

BorisTheBrave 7y ago

This is not true, bytecode stores fields and classes as fully qualified strings: https://stackoverflow.com/a/17406592 https://stackoverflow.com/a/17406592

pdpi 7y ago

> but AFAIK the Java compiler throws away any type information from the source code You're thinking about generics. .class files preserve a whole bunch of type information (I'm building a .class decompiler in my free time, and I'm looking at that very same data in my debugger ATM).

The_Colonel 7y ago
You probably know this, but it's not obvious to the random reader. Even generic types are available in the Java .class file and are accessible from the reflection API. Spring for example uses this quite heavily.
- cogman10 7y ago
  It depends on where you are at. Type information is present in fields and class inheritance For example, a class like this `class Foo implements Bar<String>` Retains the fact that the generic type is a String. That information is completely lost at method invocation. So a method that takes a `Bar<String>` ultimately compiles to a method that takes a `Bar` and knows nothing of the String. To get that generic information down you have to engage in some fun tricks using either the class or field method I mentioned earlier. (Usually you do this with a second type parameter where it matters).

imtringued 7y ago

Java is only throwing generic type information away in the declaration of classes and methods. The code that is accessing generic types is compiled with casts to the expected type. List<String>.get(1) will generate a cast to String therefore nothing is actually missing in the generated code. It is only missing when you use reflection to e.g. deserialize a List via Jackson by passing List<String>.class. That unfortunately won't work because the generic type parameter is not part of the declaration, only the generated code.

pizlonator 7y ago

Java JITs don’t throw away type information. The bytecode carries strong types, though you have to do some work to get them out (some abstract interpretation). But that’s something you can do statically; no need for profiling or speculation. In JS you can only get the types by profiling.

titzer 7y ago
Generics are erased in Java. Not so in the CLR.
- pizlonator 7y ago
  Yeah but the thread is about types, not generic types specifically. Also it’s not really true that genetics are erased. There’s that horrible thing javac does so that the VM can support reflection for generics. I get your point though.
  - titzer 7y ago
    Do you mean the passing of classes as additional arguments? I haven't seen the horrible thing. Overall I think C# got this one right. Generics are right there in the binaries. bUt ActuALLy, I think the rightest right thing is to do specialization up to representation at link time (or compile time), when the whole program is available, ala MLton. Virgil does this. Of course this is not possible in a dynamic code loading environment but I only have so many fucks to give in this life.
    - pizlonator 7y ago
      No, I meant that the Class format has metadata about what the genetics were so some java.lang.reflect thing can query about what the genetic type was. I don’t think it comes with soundness guarantees. I agree C# got this right. I agree that doing specialization up to link time is ideal from a certain standpoint.
- username90 7y ago