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

141–150 of 168 posts

Re: The Java type system is broken

#141

Post by sqrt17 »

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.

Go's type system with limited polymorphism looks to me like someone took the (horrible) collections from Java 1.2 and applied a fix that solves 85% of the problem. Compared to the 95% solution we get with Java, it's not as refined but also plenty good enough in most cases where concrete code deals with concrete problems (i.e. not framework-level code where you'd curse Java for lacking Scala's types-and-implicit-driven compile time contorsions).

Re: The Java type system is broken

#142

Post by jeremyjh »

mnd999 wrote: post #119
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.

Except they didn’t - they introduced annotations at the same time and bumped the class file version for that.

Changing the class file doesn't necessarily break backwards compatibility. Are you saying a 1.4 JVM couldn't run 1.3 bytecode?

Re: The Java type system is broken

#143

Post by rs86 »

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…

The thing I most resent is that dynamic languages are so widespread. It is so pleasurable to write haskell or ocaml!

Re: The Java type system is broken

#144

Post by microtherion »

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.

My impression (having not tried this part of the language much) is that Swift underwent similar growing pains with their generics (but with the benefit of being willing to break backward compatibility). After 40 years or so of generics, it seems language designers STILL think "all these languages before me are overcomplicating the matter, I bet I can do this in a much simpler way".

Re: The Java type system is broken

#145

Post by flamtap »

majewsky wrote: post #122
aserafini wrote: post #110

Earlier quoted context omitted.

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

I'm... I'm so sorry.

Re: The Java type system is broken

#146

Post by slavapestov »

microtherion wrote: post #144
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.

My impression (having not tried this part of the language much) is that Swift underwent similar growing pains with their generics (but with the benefit of being willing to break backward compatibility). After 40 years or so of generics, it seems language designers STILL think "all these languages before me are overcomplicating the matter, I bet I can do this in a much simpler way".

The implementation of generics has undergone major changes and new features were added, but the conceptual model is pretty much what it was in Swift 1. This was one part of the language that they almost got right from the start.

Re: The Java type system is broken

#147

Post by mey »

cs02rm0 wrote: post #109
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…

Had a client just last month that were doing SOAP wrong somehow... To be fair, I'm not sure there's any other way.

There are degrees, sort of like levels of hell. I think the universe implodes if you combine XML Encryption and SOAP SMTP binding. Actually that may explain things pretty well...

Re: The Java type system is broken

#148

Post by chowells »

tathougies wrote: post #81
stingraycharles wrote: post #9

Earlier quoted context omitted.

Wouldn't that be a problem in most languages? Even Haskell allows for it through Data.Dynamic If I can serialize to String, and then deserialize a String to any type of class, I can effectively "cast" anything to anything.

Data.Dynamic is type safe. It performs a run-time type check. Haskell can be made to be unsound using 'unsafeCoerce', but as you'll note, there is a giant unsafe in front of it.

Haskell is unsound because of 'undefined :: a'. There you go - a proof of every proposition by the Curry-Howard isomorphism.

It's still safe, though, as it diverges at run time. Much like the ClassCastException coming from the JVM prevents the unsoundness in the original article from being a safety error.

'unsafeCoerce' (and things that can implement it, like creating a polymorphic mutable cell with 'unsafePerformIO') are worse than unsound - they are also unsafe.

Re: The Java type system is broken

#149

Post by kelnos »

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 implement some dynamic languages on top of the JVM.

So yes, erasure has its drawbacks, but it's not all bad.

Re: The Java type system is broken

#150

Post by olliej »

It missed my favorite: contravariant arrays (or is it covariant, I last did work on this more than a decade ago.

Specifically you can do (forgive syntax it’s also been a long time since I wrote java)

X = new String[10] Ovject[] o = X

o[0] = 1; // this will auto box, and then fail at runtime

Note that this isn’t a “bug” as it predates any version of generics so collection types especially are much saber if you support this. That said it does result in a logical error in which you can’t assign something that looks like it should be fine.

.Net unfortunately picked up this design decision in order to support java on their vm.

Post reply on HN