4 ms·

I believe that OP is confused about when the resolution happens. Overloading is resolved by the compiler, inheritance at runtime

marginalia_nu 3y ago
Kind of a blurry distinction with a JIT-compiled languague tbh.
- alserio 3y ago
  why? the JIT works on bytecode and JVM bytecode has no concept of overloading. Maybe I should have specified that by "compiler" i meant the first compilation step, Java source to bytecode.
  - hinkley 3y ago
    The JVM bytecode is not the JVM. There’s some late binding allowed in the JVM to deal with API changes. So the caller can call a method signature that doesn’t exist in the target (but either does in a later version or did in a previous one), and the JVM has to resolve it at first invocation, rewriting the bytecode in the process. The compile time resolution ends up being a hint that usually works, but doesn’t always. And if memory serves a number of languages that run on top of the JVM have leveraged this fact, including the original third party implementation of generics.
    - alserio 3y ago
      still the lookup is based on the symbol, no? so the JVM does not resolve overload even in that case, i believe
      - hinkley 3y ago
        Read what I said again. Step 1 is a lookup by symbol. You're ignoring the vast majority of the logic. There are hints about what I'm talking about in this conversation about invokespecial: https://stackoverflow.com/questions/13764238/why-invokespecial-is-needed-when-invokevirtual-exists https://stackoverflow.com/questions/13764238/why-invokespeci... This trickiness is not called out in the bytecode specification, but in the JVM spec. They get a little closer to the mark here: https://docs.oracle.com/javase/specs/jvms/se9/html/jvms-6.html#jvms-6.5.invokespecial https://docs.oracle.com/javase/specs/jvms/se9/html/jvms-6.ht... "Is Java Statically Typed or Dynamically Typed?" is basically an interview gotcha question. Most people should answer the former, but if you are hiring people to create a JVM or a language that translates to the JVM, you're looking for a much longer answer that circles around gradations of the latter, because the compiler is strongly typed but the JVM has weaker type guarantees that are sorted out at first invocation, and which look like variance (predating most literature on contra and covariance, I might add). Prior to invokedynamic people used this and other facts to trick the JVM into doing things that are illegal in Java. The Hotspot people learned a whole lot about how the JVM actually functions from interactions with these sorts of people.
        alserio 3y ago
        i now get what you mean, thanks
        hinkley 3y ago
        If I wasn't already clear, this isn't something that normal devs should have or want to think about. But it's hard to avoid if you end up dealing with separate compilation units that are run on a different build schedule. Sooner or later your refactoring will either blow up with an obscure error, or work even though if you really think about it, the compiler would say it shouldn't. And of course if you actually dig you'll find it out as well. If you want sophisticated dispatch you want to use invokedynamic, but that was an RFE when I was learning about this stuff.
        deleted 3y ago
        [deleted]
    - LegionMammal978 3y ago
      I'm having trouble finding the behavior you describe in the JVM specification. Except for the special case of signature polymorphic methods, a resolved method must always match both the name and descriptor, as far as I can tell. You linked the invokespecial opcode, but that just talks about how to search through superclasses and superinterfaces to find the target method.

marginalia_nu 3y ago

Kind of a blurry distinction with a JIT-compiled languague tbh.

alserio 3y ago
why? the JIT works on bytecode and JVM bytecode has no concept of overloading. Maybe I should have specified that by "compiler" i meant the first compilation step, Java source to bytecode.
- hinkley 3y ago
  The JVM bytecode is not the JVM. There’s some late binding allowed in the JVM to deal with API changes. So the caller can call a method signature that doesn’t exist in the target (but either does in a later version or did in a previous one), and the JVM has to resolve it at first invocation, rewriting the bytecode in the process. The compile time resolution ends up being a hint that usually works, but doesn’t always. And if memory serves a number of languages that run on top of the JVM have leveraged this fact, including the original third party implementation of generics.
  - alserio 3y ago
    still the lookup is based on the symbol, no? so the JVM does not resolve overload even in that case, i believe
    - hinkley 3y ago
      Read what I said again. Step 1 is a lookup by symbol. You're ignoring the vast majority of the logic. There are hints about what I'm talking about in this conversation about invokespecial: https://stackoverflow.com/questions/13764238/why-invokespecial-is-needed-when-invokevirtual-exists https://stackoverflow.com/questions/13764238/why-invokespeci... This trickiness is not called out in the bytecode specification, but in the JVM spec. They get a little closer to the mark here: https://docs.oracle.com/javase/specs/jvms/se9/html/jvms-6.html#jvms-6.5.invokespecial https://docs.oracle.com/javase/specs/jvms/se9/html/jvms-6.ht... "Is Java Statically Typed or Dynamically Typed?" is basically an interview gotcha question. Most people should answer the former, but if you are hiring people to create a JVM or a language that translates to the JVM, you're looking for a much longer answer that circles around gradations of the latter, because the compiler is strongly typed but the JVM has weaker type guarantees that are sorted out at first invocation, and which look like variance (predating most literature on contra and covariance, I might add). Prior to invokedynamic people used this and other facts to trick the JVM into doing things that are illegal in Java. The Hotspot people learned a whole lot about how the JVM actually functions from interactions with these sorts of people.
      - alserio 3y ago
        i now get what you mean, thanks
        hinkley 3y ago
        If I wasn't already clear, this isn't something that normal devs should have or want to think about. But it's hard to avoid if you end up dealing with separate compilation units that are run on a different build schedule. Sooner or later your refactoring will either blow up with an obscure error, or work even though if you really think about it, the compiler would say it shouldn't. And of course if you actually dig you'll find it out as well. If you want sophisticated dispatch you want to use invokedynamic, but that was an RFE when I was learning about this stuff.
      - deleted 3y ago
        [deleted]
  - LegionMammal978 3y ago
    I'm having trouble finding the behavior you describe in the JVM specification. Except for the special case of signature polymorphic methods, a resolved method must always match both the name and descriptor, as far as I can tell. You linked the invokespecial opcode, but that just talks about how to search through superclasses and superinterfaces to find the target method.