Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Java type system is broken

wouter.coekaerts.be

Post reply on HN
Print view View original

151–160 of 168 posts

Re: The Java type system is broken

#151

Post by phillipcarter »

hota_mazi wrote: post #133
kjeetgill wrote: post #130

Earlier quoted context omitted.

Interesting, do you have any resources? What people? Aside from the video I posted from Brian Goetz most of what I've read is just comments about how much people like reification in C# and how annoying those edge cases in Java are (i.e. stories from practitioners not language designers.) I'd love to read more.

There's plenty of material out there but I'll summarize: 1. Erasure keeps you honest and prevents you from second guessing the compiler by limiting the introspection you can perform on your code. 2. Reification puts up a very high barrier to interop. Erasure systems are much more welcoming to implementing multiple languages and multiple type systems on top of them. For example, the scala.net project was abandoned bec…

I suppose if implemented flawlessly, this would be true:

> Erasure keeps you honest and prevents you from second guessing the compiler by limiting the introspection you can perform on your code

But the title of the article under discussion is called "The Java type system is broken", after all :)

Re: The Java type system is broken

#152

Post by tabtab »

_skel wrote: post #108
tabtab wrote: post #77

Earlier quoted context omitted.

Just use dynamic or better yet type-tag-free languages. Types are hard to get right and hard to reason about. Sure, there are some Sheldons out there who master it even under pasta applications, but most of us are not Sheldons. C# also bleeped up types by adding nullable types, making reflection into a scavenger hunt. For dynamic or tag-free languages, type indicators could be used to parse-check scalar (base) values…

I prefer my type errors at compile time. You have to reason about types in any language because passing the wrong type to a function can result in errors. You have to do all of that mental work by yourself in a dynamic language because there isn't a system to do it for you.

There are tools roughly similar to C's "lint" that can warn you about suspicious-looking code. While compile-time checking can be nice, compiler-oriented languages often result in more verbose code. Verbosity introduces errors also. But the benefit weighing also depends on the kind of applications. I didn't mean to trigger a "holy war" of static versus dynamic languages.

Re: The Java type system is broken

#153

Post by chrisseaton »

kelnos wrote: post #149
mcculley wrote: post #44

The mess that is the current Java type system makes me skeptical when proponents of languages like Go say not to worry, that generics can be added later. If Java had generics in the beginning, it would look a lot different and the type system would be more powerful and safe.

I was reading something a while ago (can't find it now, unfortunately) that suggested that the use of type erasure for generics actually opens up the JVM to be able to do some useful things that (for example) the CLR can't do. One thing I recall was that the Scala developers gave up on their CLR/.NET backend. I also read, more generally, that adding reified generics to the JVM might make it hard or impossible to impl…

Yes I've heard this from multiple people targeting new languages to the JVM.

Maybe it's why the JVM has a larger ecosystem of new languages?

Re: The Java type system is broken

#155

Post by MaxBarraclough »

icedchai wrote: post #132
mcculley wrote: post #131

Earlier quoted context omitted.

Those casts are still there. The compiler puts them in and the JVM has to execute them.

Yes. And my point is they'd be there anyway, with or without generics. It's not "generics" making the JVM any slower.

> they'd be there anyway

No. That's the point.

Re: The Java type system is broken

#156

Post by PDoyle »

coldtea wrote: post #67
cmiles74 wrote: post #62

Earlier quoted context omitted.

For certain and specific definitions of "broken code".

Yeah, for the type of broken code that has the wrong types.

Right. I think this is the promise of Java generics: we promise we'll warn you if you're relying on dynamic type checking because we can't prove all dynamic type checks will pass.

This article gives a series of examples that break that promise.

Re: The Java type system is broken

#157

Post by hyperpape »

kelnos wrote: post #149
mcculley wrote: post #44

The mess that is the current Java type system makes me skeptical when proponents of languages like Go say not to worry, that generics can be added later. If Java had generics in the beginning, it would look a lot different and the type system would be more powerful and safe.

I was reading something a while ago (can't find it now, unfortunately) that suggested that the use of type erasure for generics actually opens up the JVM to be able to do some useful things that (for example) the CLR can't do. One thing I recall was that the Scala developers gave up on their CLR/.NET backend. I also read, more generally, that adding reified generics to the JVM might make it hard or impossible to impl…

One source: https://olabini.com/blog/2010/07/questioning-the-reality-of-...

Re: The Java type system is broken

#158

Post by pron »

monocasa wrote: post #92
pron wrote: post #90

Earlier quoted context omitted.

> added it without many issues Except for the fact that all CLR languages must adopt the same variance model, enforced by the runtime (or choose not to interoperate well).

Sure, but in context Go doesn't have that issue. Go's compiler only supports Go in a more or less statically linked binary.

Go doesn't have this issue because there aren't other languages running on that runtime. If there were (and you wanted an interop of those languages with Go so that you could use Go libraries), then you'd have this issue regardless of the fact that the runtime is linked with the image.

Re: The Java type system is broken

#159

Post by hota_mazi »

mcculley wrote: post #128
kjeetgill wrote: post #48

Earlier quoted context omitted.

Interesting. How do you think it would be different? I ask because the go-to is usually genetics erasure. Do you think more could or would have been different? For what it's worth, Brian Goetz doesn't see type-erasure as a such a failure and defends the design choice[0]. [0]: https://m.youtube.com/watch?v=TkpcuL1t1lY

I have not watched the video. All of the defenses of type erasure I have read boiled down to backwards compatibility. If generics had been there from the start, the JVM and the compiler could do more with them, eliminating casts and allowing things like List , getting rid of arrays entirely as a special case and allowing the compiler and JVM to optimize accordingly.

That's incorrect.

It would have been possible to implement reified generics while preserving backward compatibility, Neal Gafter had actually a proposal to do just that.

In the end, erasure won simply because it's the superior solution.

Re: The Java type system is broken

#160

Post by mcculley »

hota_mazi wrote: post #159
mcculley wrote: post #128

Earlier quoted context omitted.

I have not watched the video. All of the defenses of type erasure I have read boiled down to backwards compatibility. If generics had been there from the start, the JVM and the compiler could do more with them, eliminating casts and allowing things like List , getting rid of arrays entirely as a special case and allowing the compiler and JVM to optimize accordingly.

That's incorrect. It would have been possible to implement reified generics while preserving backward compatibility, Neal Gafter had actually a proposal to do just that. In the end, erasure won simply because it's the superior solution.

Erasure is superior to a system that would be typesafe? Please elaborate.
Post reply on HN