7 ms·

The following bytecodes have been introduced: vaload vastore vbox vdefault vload vreturn vstore vunbox vwithnewfield These will have direct impact on the JVM.

The following bytecodes have been introduced: vaload vastore vbox vdefault vload vreturn vstore vunbox vwithnewfield These will have direct impact on the JVM. Is there a test version of the JVM with these bytecodes already implemented? Not sure if Java follows similar rules as the IETF, show us working code with the specifications.

jimktrains2 9y ago
If they're doing breaking changes to the VM, I wonder if we can get rid of type erasure. Generics seem really nice until you actually use them to do anything mildly complicated, then type erasure rears it's ugly head and you now have a type parameter and a Thing.class normal parameter and reflection.
- bitmapbrother 9y ago
  Isn't type erasure one of the reasons there are so many dynamic languages on the JVM? Also, why do you consider the introduction of these new bytecodes as breaking changes for the JVM? Backward compatibility has always been one of the highest priorities for the Java architects.
  - paulddraper 9y ago
    > Isn't type erasure one of the reasons there are so many dynamic languages on the JVM? No and yes. No, it doesn't really matter for dynamically typed languages (just use Object for generic types). Yes, it matters for statically typed languages. One of the factors for Scala .NET abondonment was the difficulty in creating a interoperable advanced type system in a fully reified environment. IMO, full type erasure (like C/C++) is the right way to go. Java erasure is weird only because it didn't do it completely, not because they did it at all.
    - bad_user 9y ago
      > No, it doesn't really matter for dynamically typed languages (just use Object for generic types). This line is disproven by all the dynamic languages that happened and failed on the CLR.
      - kelnos 9y ago
        Did they fail because they weren't possible to build on top of the CLR, or because people didn't want to use them?
    - Matthias247 9y ago
      What do you mean with "full type erasure (like C/C++)"? Afaik if you have RTTI enabled you have full type information available at runtime, even for templates - which is the thing that people usually want when talking about reified generics. Is it about C++ without RTTI? Or about the fact that vector<int> is compiled completely separate from a vector<string> (monomorphization)? I think the latter one is an orthogonal issue to whether type information is available at runtime.
      - paulddraper 9y ago
        You're right, since C++98, it's has RTTI. Subpar example on my part :/
    - josefx 9y ago
      > No, it doesn't really matter for dynamically typed languages (just use Object for generic types). At which point any call to the underlying environment fails with a type error. Sorry your List<Object> is not and will never be a List<int>, trying to pass it as one wont do. Either you provide a way to construct a generic type with the right type parameters in the dynamic language or you accept that you can only inter-op with a limited subset of the underlying environment. Of course that also gets ugly. You now have to deal with the fact that you not only have a List but several incompatible List<T> floating around, adding the contents of two lists suddenly includes the question what sort of list to return, List<Int>,List<Double>,List<Number> or an error? In a type erased context the answer is always the same, you return a List<Object>.
  - jimktrains2 9y ago
    I meant breaking in that the Java 10 compiler would be targeting a newer version of the JVM and could dispense with having to be backwards compatible, which was one of the reasons I remember reading for generics.
    - kelnos 9y ago
      Where are you reading that? The Java N compiler always targets version N of the JVM (well, by default, anyway), and you can't run bytecode on older versions of the JVM. I would sincerely doubt they're considering breaking back-compat in Java 10 (that is, making it so older bytecode targeting something <10 cannot run on 10+).
- devdoomari 9y ago
  scala handles the generic-edge cases using lower-bounds and upper-bound types - and scala runs on JVM. But there could be any other edge cases that cannot be solved easily thru scala's lower-/upper-bound types... (don't know enough)
- nradov 9y ago
  Those are not breaking changes. Existing byte code will continue to work. My understanding of generic type erasure is that it is more of a language issue than a VM issue. Nothing in the VM prevents reified generics, but when generics were introduced in Java 5 they decided to use type erasure in order to avoid having to produce a whole new collections standard library or break compatibility with existing code.
  - deleted 9y ago
    [deleted]
  - jimktrains2 9y ago
    I meant breaking in that the Java 10 compiler would be targeting a newer version of the JVM and could dispense with having to be backwards compatible, which was one of the reasons I remember reading for generics. They could have simply left the old library, deprecated it, and added in their genericed one as a a new package. It had to be modified anyway.
    - evincarofautumn 9y ago
      Right, it breaks forward compatibility: bytecode for a newer VM won’t work on an older VM. IMO backward compatibility is much more important for a programming language, though.
    - moomin 9y ago
      Yup, and Microsoft did exactly that, meaning C# has been able to express List<int> for ten years now.
    - jdmichal 9y ago
      Or they could have done erasure in the runtime when they detected non-generic usage of a generic class. Instead of forcing it on everyone.
  - valarauca1 9y ago
    Nah this is a VM issue. Type assertions have no ability to recurse. RN you assert both classes are a UTF8 value in the constant pool. Or really 1 class is a UTF8 value, which the compiler know the first one is. But with Generics, you may not know what it holds at runtime so this doesn't work. You'd have to constantly rebuild the constant pool (Slow) each time a new _kind_ of generic is used. So either a new type+byte code would have to be introduced, or the type assertion instruction would have to become recursive. The later is a breaking change. Also interfaces break this b/c those are class specific. So a Lorg/my/company/myClass$5; and Lorg/your/company/yourClass$0 might both implement the same interface. But that interface information isn't in the collection class, but those to class's class files. So really it just needs new byte code.
- deleted 9y ago
  [deleted]
- bad_user 9y ago
  It's in fact not type erasure that "rears its ugly head", but actually that Java's type system is not expressive enough, which is why developers end up relying on reflective capabilities. There's something seriously wrong with the type system when you want "instanceOf T" checks or "new T".
  - kelnos 9y ago
    If you don't have/want "new T", how do you ever create an instance of anything?
    - chii 9y ago
      The in this context is a variable, not a concrete type.
      - barrkel 9y ago
        Did you mean: "The T in this context..."? Instantiating a generic type is like a function call at compile time, where the type arguments are substituted for type parameters in the body of the generic type. It's a variable at compile time, but it's a concrete type at runtime for any version of the code that can execute.
  - barrkel 9y ago
    There's nothing wrong with doing 'new T' in a generic method or class body. It requires a constraint on the type variable is all: that some constructor with a specific parameter list is available.
- alkonaut 9y ago
  I only thought the erasure was bad because of how Java lacked value types (so my list of T will use heap boxes when T is int). I haven't given it a ton of thought but I thought that apart from reflection it would actually be nicer if the runtime erased types. I.e. at runtime a type should just be either a stack/copy/move type or a reference type. So erase all reference type to objects. It feels like it's the job of the compiler to handle these. Obviously at runtime you can get some extra safety guarantees from reified types, but at the cost of languages on the runtime being more difficult to adapt to other paradigms etc. I imagine a runtime that doesn't have strong opinions about types to be easier to make type level language changes for (i.e. the language(s) can evolve without the need for runtime changes), and it should also be easier to support entirely different type systems.
  - tigershark 9y ago
    Erased generics are awful compared to proper generics like C#. If you ever used both of them it should be clear as the sun. In C# you don't have to pass around the type in a method parameter and use reflection. I’m missing how you can claim that the languages on the runtime with proper generics are more difficult to adapt to other paradigms given the extremely fast evolution of C# and F# compared to Java that for example received closures something like 10 years after C#.
    - alkonaut 9y ago
      > In C# you don't have to pass around the type in a method parameter and use reflection. I know - but I'm not familiar with the situation where I'd have to to that in java. Do you mean e.g. Foo(object x) { if (X is List<int>) ... else ... }
      - Sharlin 9y ago
        Basically every time you need to instantiate a type passed as a type parameter. You either need to pass the appropriate class literal or a factory function. And if you need ro create an instance of a generic type parameterized by a type parameter (eg. Collection<T>) you need a factory or else resort to raw types and/or ugly casting.
- PDoyle 9y ago
  These aren't breaking changes. This isn't even the first time they've added bytecodes. (Java 7 added invokedynamic.)
- deleted 9y ago
  [deleted]
_old_dude_ 9y ago
It has the same kind of rules, i believe, here is the code of the VM that works/may work with value types http://hg.openjdk.java.net/valhalla/valhalla/hotspot/ http://hg.openjdk.java.net/valhalla/valhalla/hotspot/

jimktrains2 9y ago

If they're doing breaking changes to the VM, I wonder if we can get rid of type erasure. Generics seem really nice until you actually use them to do anything mildly complicated, then type erasure rears it's ugly head and you now have a type parameter and a Thing.class normal parameter and reflection.

bitmapbrother 9y ago
Isn't type erasure one of the reasons there are so many dynamic languages on the JVM? Also, why do you consider the introduction of these new bytecodes as breaking changes for the JVM? Backward compatibility has always been one of the highest priorities for the Java architects.
- paulddraper 9y ago
  > Isn't type erasure one of the reasons there are so many dynamic languages on the JVM? No and yes. No, it doesn't really matter for dynamically typed languages (just use Object for generic types). Yes, it matters for statically typed languages. One of the factors for Scala .NET abondonment was the difficulty in creating a interoperable advanced type system in a fully reified environment. IMO, full type erasure (like C/C++) is the right way to go. Java erasure is weird only because it didn't do it completely, not because they did it at all.
  - bad_user 9y ago
    > No, it doesn't really matter for dynamically typed languages (just use Object for generic types). This line is disproven by all the dynamic languages that happened and failed on the CLR.
    - kelnos 9y ago
      Did they fail because they weren't possible to build on top of the CLR, or because people didn't want to use them?
  - Matthias247 9y ago
    What do you mean with "full type erasure (like C/C++)"? Afaik if you have RTTI enabled you have full type information available at runtime, even for templates - which is the thing that people usually want when talking about reified generics. Is it about C++ without RTTI? Or about the fact that vector<int> is compiled completely separate from a vector<string> (monomorphization)? I think the latter one is an orthogonal issue to whether type information is available at runtime.
    - paulddraper 9y ago
      You're right, since C++98, it's has RTTI. Subpar example on my part :/
  - josefx 9y ago
    > No, it doesn't really matter for dynamically typed languages (just use Object for generic types). At which point any call to the underlying environment fails with a type error. Sorry your List<Object> is not and will never be a List<int>, trying to pass it as one wont do. Either you provide a way to construct a generic type with the right type parameters in the dynamic language or you accept that you can only inter-op with a limited subset of the underlying environment. Of course that also gets ugly. You now have to deal with the fact that you not only have a List but several incompatible List<T> floating around, adding the contents of two lists suddenly includes the question what sort of list to return, List<Int>,List<Double>,List<Number> or an error? In a type erased context the answer is always the same, you return a List<Object>.
- jimktrains2 9y ago
  I meant breaking in that the Java 10 compiler would be targeting a newer version of the JVM and could dispense with having to be backwards compatible, which was one of the reasons I remember reading for generics.
  - kelnos 9y ago
    Where are you reading that? The Java N compiler always targets version N of the JVM (well, by default, anyway), and you can't run bytecode on older versions of the JVM. I would sincerely doubt they're considering breaking back-compat in Java 10 (that is, making it so older bytecode targeting something <10 cannot run on 10+).
devdoomari 9y ago
scala handles the generic-edge cases using lower-bounds and upper-bound types - and scala runs on JVM. But there could be any other edge cases that cannot be solved easily thru scala's lower-/upper-bound types... (don't know enough)
nradov 9y ago
Those are not breaking changes. Existing byte code will continue to work. My understanding of generic type erasure is that it is more of a language issue than a VM issue. Nothing in the VM prevents reified generics, but when generics were introduced in Java 5 they decided to use type erasure in order to avoid having to produce a whole new collections standard library or break compatibility with existing code.
- deleted 9y ago
  [deleted]
- jimktrains2 9y ago
  I meant breaking in that the Java 10 compiler would be targeting a newer version of the JVM and could dispense with having to be backwards compatible, which was one of the reasons I remember reading for generics. They could have simply left the old library, deprecated it, and added in their genericed one as a a new package. It had to be modified anyway.
  - evincarofautumn 9y ago
    Right, it breaks forward compatibility: bytecode for a newer VM won’t work on an older VM. IMO backward compatibility is much more important for a programming language, though.
  - moomin 9y ago
    Yup, and Microsoft did exactly that, meaning C# has been able to express List<int> for ten years now.
  - jdmichal 9y ago
    Or they could have done erasure in the runtime when they detected non-generic usage of a generic class. Instead of forcing it on everyone.
- valarauca1 9y ago
  Nah this is a VM issue. Type assertions have no ability to recurse. RN you assert both classes are a UTF8 value in the constant pool. Or really 1 class is a UTF8 value, which the compiler know the first one is. But with Generics, you may not know what it holds at runtime so this doesn't work. You'd have to constantly rebuild the constant pool (Slow) each time a new _kind_ of generic is used. So either a new type+byte code would have to be introduced, or the type assertion instruction would have to become recursive. The later is a breaking change. Also interfaces break this b/c those are class specific. So a Lorg/my/company/myClass$5; and Lorg/your/company/yourClass$0 might both implement the same interface. But that interface information isn't in the collection class, but those to class's class files. So really it just needs new byte code.
deleted 9y ago
[deleted]
bad_user 9y ago
It's in fact not type erasure that "rears its ugly head", but actually that Java's type system is not expressive enough, which is why developers end up relying on reflective capabilities. There's something seriously wrong with the type system when you want "instanceOf T" checks or "new T".
- kelnos 9y ago
  If you don't have/want "new T", how do you ever create an instance of anything?
  - chii 9y ago
    The in this context is a variable, not a concrete type.
    - barrkel 9y ago
      Did you mean: "The T in this context..."? Instantiating a generic type is like a function call at compile time, where the type arguments are substituted for type parameters in the body of the generic type. It's a variable at compile time, but it's a concrete type at runtime for any version of the code that can execute.
- barrkel 9y ago
  There's nothing wrong with doing 'new T' in a generic method or class body. It requires a constraint on the type variable is all: that some constructor with a specific parameter list is available.
alkonaut 9y ago
I only thought the erasure was bad because of how Java lacked value types (so my list of T will use heap boxes when T is int). I haven't given it a ton of thought but I thought that apart from reflection it would actually be nicer if the runtime erased types. I.e. at runtime a type should just be either a stack/copy/move type or a reference type. So erase all reference type to objects. It feels like it's the job of the compiler to handle these. Obviously at runtime you can get some extra safety guarantees from reified types, but at the cost of languages on the runtime being more difficult to adapt to other paradigms etc. I imagine a runtime that doesn't have strong opinions about types to be easier to make type level language changes for (i.e. the language(s) can evolve without the need for runtime changes), and it should also be easier to support entirely different type systems.
- tigershark 9y ago
  Erased generics are awful compared to proper generics like C#. If you ever used both of them it should be clear as the sun. In C# you don't have to pass around the type in a method parameter and use reflection. I’m missing how you can claim that the languages on the runtime with proper generics are more difficult to adapt to other paradigms given the extremely fast evolution of C# and F# compared to Java that for example received closures something like 10 years after C#.
  - alkonaut 9y ago
    > In C# you don't have to pass around the type in a method parameter and use reflection. I know - but I'm not familiar with the situation where I'd have to to that in java. Do you mean e.g. Foo(object x) { if (X is List<int>) ... else ... }
    - Sharlin 9y ago
      Basically every time you need to instantiate a type passed as a type parameter. You either need to pass the appropriate class literal or a factory function. And if you need ro create an instance of a generic type parameterized by a type parameter (eg. Collection<T>) you need a factory or else resort to raw types and/or ugly casting.
PDoyle 9y ago
These aren't breaking changes. This isn't even the first time they've added bytecodes. (Java 7 added invokedynamic.)
deleted 9y ago
[deleted]

_old_dude_ 9y ago

It has the same kind of rules, i believe, here is the code of the VM that works/may work with value types http://hg.openjdk.java.net/valhalla/valhalla/hotspot/ http://hg.openjdk.java.net/valhalla/valhalla/hotspot/