3 ms·

It's also possibly an unnecessary trade-off. Scala, for example, has something akin to reified generics, without any support from the JVM itself. It also allow

It's also possibly an unnecessary trade-off. Scala, for example, has something akin to reified generics, without any support from the JVM itself. It also allows for a decent level of interop with other JVM languages, though of course all you can really "export" to other languages is the least common denominator semantics required by the JVM. Java could theoretically do something similar: Maintain type information that is visible to Java at compile- and run-time, while still compiling to code that is consumable from other languages without too much hassle. Really, personally, I only care about it being available at compile time. Haskell, for example, erases types much more aggressively than Java does, while also maintaining a high level of type safety. I guess I don't know that it's backwards compatibility on the JVM that bothers me so much as Java's tendency to think of itself as being little more than a JVM macro assembler with C-like syntax.

pron 8y ago
That's not so simple. The class file, I believe, does have the generic instance at the use site, but then if you could have two overloads, foo(List<String>) and foo(List<Integer>), which would you call if you use a raw type (either in Java or from other languages). It's not that Java is a JVM macro assembler so much that there is not much to be gained from this feature given the rest of Java, and Java has a very different design philosophy from Scala, as it aims at a different audience. If and Java evolves in that direction, perhaps this feature would change. In the meantime, those who like Scala can use Scala.
- bunderbunder 8y ago
  This feels to me more like a failure of imagination than a technical impossibility. C#, for example, handles some things like this by exporting a function with a special name in the compiled modules. Java could do the same - handle the overload by having them be two different methods named something like foo__String() and foo__Integer() on the back end. The naming may not be beautiful, but I think that, if you do it right (for starters, try to use more readable naming conventions than Scala does), it can make for a pretty sane user experience for consumers who are using different languages. Naturally, the best practice would also be to design so that the API remains clean for packages that are meant to be consumed by multiple JVM languages. I also want to point out that having a type system with a stronger handle on generics is about more than just ergonomics when overloading methods. As another example, Java's story for auto-mapping libraries (serialization/deserialization, lighweight ORM, stuff like that) is materially hindered by the inability to express things like "List<MyDataType>.class". And those sorts of things do have a material impact on developer productivity - when I'm working in Java, I find that I spend an inordinate amount of time writing, maintaining and code reviewing all the extra glue code that needs to be written to handle tasks that other languages make almost effortless.
  - pron 8y ago
    > This feels to me more like a failure of imagination than a technical impossibility. It's not the lack of possible solutions, but more of a design philosophy. > is materially hindered by the inability to express things like "List<MyDataType>.class See Guava's TypeToken https://google.github.io/guava/releases/25.0-jre/api/docs/com/google/common/reflect/TypeToken.html https://google.github.io/guava/releases/25.0-jre/api/docs/co... > I find that I spend an inordinate amount of time writing, maintaining and code reviewing all the extra glue code that needs to be written to handle tasks that other languages make almost effortless. Which is why the Java ecosystem offers a nice selection of languages to match almost everyone's taste. Many people like Java and feel productive using it, and those who don't can enjoy the great polyglot interop afforded by, among other things, generic type erasure.

pron 8y ago

That's not so simple. The class file, I believe, does have the generic instance at the use site, but then if you could have two overloads, foo(List<String>) and foo(List<Integer>), which would you call if you use a raw type (either in Java or from other languages). It's not that Java is a JVM macro assembler so much that there is not much to be gained from this feature given the rest of Java, and Java has a very different design philosophy from Scala, as it aims at a different audience. If and Java evolves in that direction, perhaps this feature would change. In the meantime, those who like Scala can use Scala.

bunderbunder 8y ago
This feels to me more like a failure of imagination than a technical impossibility. C#, for example, handles some things like this by exporting a function with a special name in the compiled modules. Java could do the same - handle the overload by having them be two different methods named something like foo__String() and foo__Integer() on the back end. The naming may not be beautiful, but I think that, if you do it right (for starters, try to use more readable naming conventions than Scala does), it can make for a pretty sane user experience for consumers who are using different languages. Naturally, the best practice would also be to design so that the API remains clean for packages that are meant to be consumed by multiple JVM languages. I also want to point out that having a type system with a stronger handle on generics is about more than just ergonomics when overloading methods. As another example, Java's story for auto-mapping libraries (serialization/deserialization, lighweight ORM, stuff like that) is materially hindered by the inability to express things like "List<MyDataType>.class". And those sorts of things do have a material impact on developer productivity - when I'm working in Java, I find that I spend an inordinate amount of time writing, maintaining and code reviewing all the extra glue code that needs to be written to handle tasks that other languages make almost effortless.
- pron 8y ago
  > This feels to me more like a failure of imagination than a technical impossibility. It's not the lack of possible solutions, but more of a design philosophy. > is materially hindered by the inability to express things like "List<MyDataType>.class See Guava's TypeToken https://google.github.io/guava/releases/25.0-jre/api/docs/com/google/common/reflect/TypeToken.html https://google.github.io/guava/releases/25.0-jre/api/docs/co... > I find that I spend an inordinate amount of time writing, maintaining and code reviewing all the extra glue code that needs to be written to handle tasks that other languages make almost effortless. Which is why the Java ecosystem offers a nice selection of languages to match almost everyone's taste. Many people like Java and feel productive using it, and those who don't can enjoy the great polyglot interop afforded by, among other things, generic type erasure.