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

121–130 of 168 posts

Re: The Java type system is broken

#121

Post by icedchai »

monocasa wrote: post #93
MaxBarraclough wrote: post #70

Earlier quoted context omitted.

> If Java had generics in the beginning, it would look a lot different and the type system would be more powerful and safe. And conceivably a good deal faster, too. My understanding is that the JVM is required to constantly perform runtime type checks.

Yeah, it either has to cast from Object all the time, or spend JIT compiler time and memory figuring out if it can elide those checks (probably with exception code for when it guesses wrong).

Without generics, the developer would have to cast from Object anyway.

Re: The Java type system is broken

#122

Post by majewsky »

aserafini wrote: post #110
bunnymancer wrote: post #56

Earlier quoted context omitted.

Had a client just last month that were doing SOAP wrong somehow... Required a SOAP message, that contained no XML after the message tag, but instead the entire message body was to be a JSON, and responded with a JSON if something was wrong, and a fully formed SOAP message if things were Ok. That and the guys that handle your money use the Http status code as their personal error messages. Except when the error is on…

I'm guessing you're talking about Adyen. At least I've had exactly the same experience integrating with their API. It's an awful mismash. I even get responses with bool = 'true' in their json, but only sometimes. That's the string 'true' sometimes and othertimes json true.

Oh god, there's a ton of those in the Openstack API. Representative example from my own code that has to deal with it: the veryFlexibleUint64. https://github.com/sapcc/limes/blob/dac0e2019ed2a6006585c2a3...

Re: The Java type system is broken

#123

Post by majewsky »

pjmlp wrote: post #101
monocasa wrote: post #78

Earlier quoted context omitted.

Sure, totally. In fact, I'm a big fan of how Microsoft does versioning, supporting previous versions, but releasing major versions with backwards incompatible changes. You see this in DirectX, and IMO, that's why we're talking about DirectX and Vulkan, rather than AZDO OpenGL these days. It really gives you an opportunity to clean up the cruft.

Yeah, although I think they missed an opportunity to move beyond "only C goes" mindset at Khronos.

Is there any language besides C that's not a complete pita to generate FFI bindings for?

Re: The Java type system is broken

#124

Post by [deleted] »

pron wrote: post #90
monocasa wrote: post #50

Earlier quoted context omitted.

Unlike Java, Go doesn't have to worry about bytecode backwards compatibility. That was the main issue that had them reaching for type erasure. Take a look at C# which added it without many issues (because they were willing to break back compat of their bytecode). Go fits this model a whole lot better.

> 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).

[deleted]

Re: The Java type system is broken

#125

Post by tdsamardzhiev »

tabtab wrote: post #77
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.

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…

True, but I think that for bigger applications static typing is better even if you don't get it quite right.

Re: The Java type system is broken

#126

Post by lmm »

icedchai wrote: post #121
monocasa wrote: post #93

Earlier quoted context omitted.

Yeah, it either has to cast from Object all the time, or spend JIT compiler time and memory figuring out if it can elide those checks (probably with exception code for when it guesses wrong).

Without generics, the developer would have to cast from Object anyway.

The point is that if Java had had generics in the beginning, they could (perhaps) have been integrated into the language in a way that obviated those casts entirely.

Re: The Java type system is broken

#127

Post by lmm »

stickfigure wrote: post #25
rimunroe wrote: post #7

Earlier quoted context omitted.

Is a type system really worth that much if it can't help you in a situation where your code is ugly and hard to follow?

Unequivocally, yes. Several new languages (eg Typescript, Dart) have optional type systems that still bring significant value to the table. Sure - all other things being equal, I'd much rather have a type system that is completely sound. Ceylon's type system is beautiful and I'm happy to see its union + intersection types being adopted by Typescript. But honestly, I'm not going to lose much sleep over these particula…

> Several new languages (eg Typescript, Dart) have optional type systems that still bring significant value to the table.

I think it's too early to say that this approach has proven to be successful - indeed another reply says that Dart has switched to a stronger type system with required types, which I'd take as significant evidence that optional typing is not a good tradeoff. Certainly my experience of the checkers framework in Java was that optional types are the worst of both worlds.

> But honestly, I'm not going to lose much sleep over these particular issues in Java. Bad code gets refactored.

I'm worried (or rather, I would be worried if I hadn't seen the bug reports, which seem to be being taken seriously and fixed in the compiler). If they can happen in bad code, who's to say they can't happen in good code.

> A bigger complaint should be made that generic type erasure makes libraries hard (eg, the number of places you have to pass around Class or TypeReference objects to let the runtime know what to do). But that was a clearly a compromise decision and everyone knows about it.

I'd argue that the only cases where you need that are when you're doing something you shouldn't (reflection). But I guess in a language without typeclasses there are problems that have no good solution.

Re: The Java type system is broken

#128

Post by mcculley »

kjeetgill wrote: post #48
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.

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.

Re: The Java type system is broken

#129

Post by lmm »

viach wrote: post #4

From the examples: "String s = gridWrapper.get(0).get(0).get(0);" - Java type system is broken! Java is not perfect, but this looks to me like a broken code indeed ".get(0).get(0).get(0)". Could we rephrase the message of the article as "If you write really broken code in Java, you might be not guarded by the type system". And this is, well, uhm, well... acceptable?

The type system should give guarantees. I believe these cases violate the specification, and I think the specification is right to require the typechecker to check all code rather than just most code: a type system that works 100% of the time is much more useful than a type system that works 99.99% of the time, because it means you can blindly rely on it rather than having to double-check it every time you do anything critical and then maintain all those double-checks.

If we take the view that these are bugs in the Java compiler, then of course a bug that's rarely triggered is less bad than a bug that's triggered all the time. But both are bugs all the same.

Re: The Java type system is broken

#130

Post by kjeetgill »

hota_mazi wrote: post #107
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

Actually, most people who actually understand in depth the subject and the trade offs of erasure versus reification squarely side on the erasure side. Erasure is the safest way to implement generics for a long list of reasons. Reification comes with a lot of downsides, which is why most languages that support parametric polymorphism use erasure.

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.

Post reply on HN