The Java type system is broken(wouter.coekaerts.be)
wouter.coekaerts.be
The Java type system is broken
http://wouter.coekaerts.be/2018/java-type-system-broken
167 comments
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 their end, in which case they return 200 and a JSON with an error message.
There are plenty of ways to do REST wrong, so let's not lump that into the people that make blog posts complaining about X because X is broken, and working just fine...
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 their end, in which case they return 200 and a JSON with an error message.
There are plenty of ways to do REST wrong, so let's not lump that into the people that make blog posts complaining about X because X is broken, and working just fine...
The only thing stopping Tim Berners-Lee spinning in his grave, is that he's still alive.
Had a client just last month that were doing SOAP wrong somehow...
To be fair, I'm not sure there's any other way.
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...
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.
Well I hope the money was good at least. Yikes.
[deleted]
I liked the two sentences before those even more:
> Java’s type system has taken a beating by the desire for backward compatibility and the interaction of its growing list of features. It needs some love to get it back in shape.
> Java’s type system has taken a beating by the desire for backward compatibility and the interaction of its growing list of features. It needs some love to get it back in shape.
This is just what it is to work with computers. Computers get fixed over time. Everything is broken, everything is fine. Mantras.
[deleted]
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.
If Java had generics in the beginning, it would look a lot different and the type system would be more powerful and safe.
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.
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.
The missing part every time this story gets told, is that Microsoft already had a generics implementation ongoing being lead by Don Syme of F# fame.
They just decided to release 1.0 without generics, instead of waiting for it to be 100% ready.
As Don clearly describes on his blog.
They just decided to release 1.0 without generics, instead of waiting for it to be 100% ready.
As Don clearly describes on his blog.
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.
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?
There are many ways to define APIs, we don't need to struggle ourselves only to C.
Metal uses Objective-C/Swift, with shaders in C++14. The Objective-C runtime can be used as FFI.
DirectX, uses COM with HLSL (a C++ subset). Likewise any COM or .NET (via RCW) aware language can talk to it.
One of the reasons OpenCL lost to CUDA was being stuck with C, while CUDA offered C, C++, Fortran and any additional language that could target PTX.
Which was what eventually made them come up with SPIR and later SPIR-V.
NVN and LibCGNM are also based on C++ and C++ inspired shader languages.
All modern OO, with nice SDKs that handle font, texture, materials, maths, GPGPU debugging.
Metal uses Objective-C/Swift, with shaders in C++14. The Objective-C runtime can be used as FFI.
DirectX, uses COM with HLSL (a C++ subset). Likewise any COM or .NET (via RCW) aware language can talk to it.
One of the reasons OpenCL lost to CUDA was being stuck with C, while CUDA offered C, C++, Fortran and any additional language that could target PTX.
Which was what eventually made them come up with SPIR and later SPIR-V.
NVN and LibCGNM are also based on C++ and C++ inspired shader languages.
All modern OO, with nice SDKs that handle font, texture, materials, maths, GPGPU debugging.
fortran?
> Take a look at C# which added it without many issues
I wouldn't say "without many issues." It took a major surgery in the CLR codebase to add generics. The difference between CLR 1.1 without generics and CLR 2.0 with generics was huge. No area of code was untouched.
I wouldn't say "without many issues." It took a major surgery in the CLR codebase to add generics. The difference between CLR 1.1 without generics and CLR 2.0 with generics was huge. No area of code was untouched.
Go doesn’t have an ABI? Does every library ship only as source code? I didn’t know that.
I was thinking of more fundamental changes to Java idiom and the standard library had generics been part of the design (e.g., how arrays work).
I was thinking of more fundamental changes to Java idiom and the standard library had generics been part of the design (e.g., how arrays work).
Did C# really break backwards compatibility of their bytecode? What I understand is that C# generic and non generic APIs are completely different, and are not inter operable.
To the first - yes, the version of .NET that introduced generics broke bytecode backward compatibility. Stuff compiled for .NET 1.0 will not run on the CLR for 2.0 and later. In practice, this wasn't a big deal; maintainers just shipped two different versions of their packages, and you'd download the one you wanted.
To the 2nd - The concrete types are separate, but they fit into a common interface hierarchy, so, at a source code level, they're plenty interoperable. For example, the (non-generic) IEnumerable interface has a Cast<T>() extension method that will convert it to a (generic) IEnumerable<T>. IEnumerable<T>, for its part, simply inherits IEnumerable.
In general, I actually like using those conversion methods for downcasting, because it gives a clearer indication of when I'm in a danger zone - for example, converting a non-generic list to a generic list might fail if the non-generic list contains a mix of different types of object. Java's situation feels less predictable to me, as this article illustrates fairly well. A few keystrokes for the sake of safer code is a dandy tradeoff in my book.
To the 2nd - The concrete types are separate, but they fit into a common interface hierarchy, so, at a source code level, they're plenty interoperable. For example, the (non-generic) IEnumerable interface has a Cast<T>() extension method that will convert it to a (generic) IEnumerable<T>. IEnumerable<T>, for its part, simply inherits IEnumerable.
In general, I actually like using those conversion methods for downcasting, because it gives a clearer indication of when I'm in a danger zone - for example, converting a non-generic list to a generic list might fail if the non-generic list contains a mix of different types of object. Java's situation feels less predictable to me, as this article illustrates fairly well. A few keystrokes for the sake of safer code is a dandy tradeoff in my book.
> Stuff compiled for .NET 1.0 will not run on the CLR for 2.0 and later
That's not true. (Mass shared hoster kinda guy here) when we pushed a bunch of customers code compiled for .NET 1.0/1.1 over to hosting environments with only CLR 2 available, their code ran just fine. These were .NET 1.0/1.1 assemblies.
There are some edge cases where stuff could break, say when doing reflection or emitting your own IL, but that for most LOB web hosted apps was pretty rare.
I did in fact marvel how backwards compatible CLR 2 was when it first shipped.
That's not true. (Mass shared hoster kinda guy here) when we pushed a bunch of customers code compiled for .NET 1.0/1.1 over to hosting environments with only CLR 2 available, their code ran just fine. These were .NET 1.0/1.1 assemblies.
There are some edge cases where stuff could break, say when doing reflection or emitting your own IL, but that for most LOB web hosted apps was pretty rare.
I did in fact marvel how backwards compatible CLR 2 was when it first shipped.
Not sure on the first part but the second part is true.
When there is a C# class that both has and doesn't have type information, they are actually completely different classes that just happen to share a base name.
This really made it painful when they first added generics. If you used generic containers but wanted to call into a library that predated it you hand to transform your data in/out of all the calls to the library. In Java land you didn't have to do anything other then a blind cast on the out side which doesn't even have a runtime penalty.
Long term the C# way was probably better but then they didn't have nearly as robust of a library ecosystem when they added generics.
When there is a C# class that both has and doesn't have type information, they are actually completely different classes that just happen to share a base name.
This really made it painful when they first added generics. If you used generic containers but wanted to call into a library that predated it you hand to transform your data in/out of all the calls to the library. In Java land you didn't have to do anything other then a blind cast on the out side which doesn't even have a runtime penalty.
Long term the C# way was probably better but then they didn't have nearly as robust of a library ecosystem when they added generics.
Yea from the wording I think they mean you can either break backwards compatibility or "fork the world".
In Java's case, old bytecode using Map would correctly work with change to Map <K, V>. C# introduced a new set of collections I believe.
In Java's case, old bytecode using Map would correctly work with change to Map <K, V>. C# introduced a new set of collections I believe.
Yeah, IIRC they added the "constrainted." instruction prefix. It's a prefix to the callvirt instruction that constrains the the underlying call to the specified type, allowing runtime generic type decisions/exceptions rather than only compile time decisions like Java.
> 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).
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.
[deleted]
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.
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.
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?
Maybe it's why the JVM has a larger ecosystem of new languages?
Since there is no subclassing [0] in Go, many of those cases are not expressible in Go.
[0] Interfaces can contain other interfaces, but I think that is still different because you can't do
[0] Interfaces can contain other interfaces, but I think that is still different because you can't do
var a []subinterface = []superinterface{...}I agree that generics should probably be a strong consideration right from the beginning. I disagree that this would mean that it would necessarily be done correctly or that it's impossible to add it later. That was the case with .Net and C#, it wasn't until the 2.0 release that generics were added. [0]
[0]: http://mattwarren.org/2018/03/02/How-generics-were-added-to-...
[0]: http://mattwarren.org/2018/03/02/How-generics-were-added-to-...
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
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.
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.
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 because it was impossible to represent Scala's type system on .net's reified platform.
3. Reification imposes overhead because of the multitude of extra runtime checks that need to be performed.
4. Most the benefits you get from reification can be emulated on erased systems (some are admittedly more hackish on an erased runtime, but they should be rare).
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 because it was impossible to represent Scala's type system on .net's reified platform.
3. Reification imposes overhead because of the multitude of extra runtime checks that need to be performed.
4. Most the benefits you get from reification can be emulated on erased systems (some are admittedly more hackish on an erased runtime, but they should be rare).
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 :)
> 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 :)
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<int>, 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.
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.
Erasure is just as type safe as reification.
Erasure gives you a little less flexibility to express certain constructs than reification allows, but from a type safety standpoint, the two approaches are equivalent.
If you want widen the meaning of "type safe" a bit, I would argue that reification is "less" type safe in the sense that it allows you to perform additional runtime type checks / type casts, which basically means you are second guessing the compiler and invalidating all the type soundness that it has provided you by accepting to compile your code.
Erasure gives you a little less flexibility to express certain constructs than reification allows, but from a type safety standpoint, the two approaches are equivalent.
If you want widen the meaning of "type safe" a bit, I would argue that reification is "less" type safe in the sense that it allows you to perform additional runtime type checks / type casts, which basically means you are second guessing the compiler and invalidating all the type soundness that it has provided you by accepting to compile your code.
It would not have allowed one to seal the loopholes demonstrated in the article?
> 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.
And conceivably a good deal faster, too. My understanding is that the JVM is required to constantly perform runtime type checks.
Good deal faster? I seriously doubt it. My understanding are generics are purely a compile time feature and does not effect run time.
I remember Java before generics: tons of casting from Object. The compiler is doing the same thing.
I remember Java before generics: tons of casting from Object. The compiler is doing the same thing.
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.
If the types were reified, the compiler and the JVM would know what type was there. No cast would be needed.
> they'd be there anyway
No. That's the point.
No. That's the point.
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).
and pointer chasing too right? unless the runtime can optimize, every generic sits behind a pointer.
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).
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.
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 to see if they are interpretable as the intended type:
For dynamic or tag-free languages, type indicators could be used to parse-check scalar (base) values to see if they are interpretable as the intended type:
function foo(int a, date b) {...}
function foo(a, b) {
if (! parsableAsInt(a)) throwTypeError(...);
if (! parsableAsDate(b)) throwTypeError(...);
}
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.
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.
> Verbosity introduces errors also.
The purpose of types is to introduce errors in the first place - at compile time, if you messed up.
Wrong code causes errors regardless. Annotating with types just moves this event from runtime to compile time.
The purpose of types is to introduce errors in the first place - at compile time, if you messed up.
Wrong code causes errors regardless. Annotating with types just moves this event from runtime to compile time.
I understand that, but I'm not sure the benefits exceed the drawbacks. In other words, verbosity introduces errors by making the code harder/longer to read. The type-related verbosity may reduce errors, but perhaps not enough to counter those caused by verbosity. In my experience, it's roughly a wash, but depends on a lot of other things, like frameworks used, skill of developers, QA techniques, etc.
The thing I most resent is that dynamic languages are so widespread. It is so pleasurable to write haskell or ocaml!
> C# also bleeped up types by adding nullable types, making reflection into a scavenger hunt.
Having used reflection in C# with both nullable types and non-, I'm curious what you mean by "scavenger hunt".
Having used reflection in C# with both nullable types and non-, I'm curious what you mean by "scavenger hunt".
[deleted]
PHP only got this halfway right because it borrowed "." from Perl. It should have also borrowed "eq" instead of making "==" unusable.
True, but I think that for bigger applications static typing is better even if you don't get it quite right.
That would solve the problem with adding generics, yes. It would also destroy the thing people appreciate about static typing - that you get told at compile time when you've done something wrong.
String concatenation got a lot nicer in C# lately but the old method is still there
It’s pretty tragic how people respond to such criticism emotionally, instead of acknowledging the issues and working towards fixing them or educating others in the traps and compromises involved.
HN is less prone to toxicity, but this is reminiscent of Reddit and it drives away the people that want to help.
As a piece of advice, some type theory never harmed anyone ;-)
HN is less prone to toxicity, but this is reminiscent of Reddit and it drives away the people that want to help.
As a piece of advice, some type theory never harmed anyone ;-)
Application of type theory, or any theory, or any formal method, requires humility and patience.
To apply a formal method to your work requires to acknowledge that your intuition might me wrong, your past decisions incorrect, and your knowledge of the subject area deficient. Often you have to step back, rethink, and rework.
This is a normal mindset for a scientist, and a pretty common mindset for an experienced engineer.
But this view is not automatically acquired with an engineering diploma, with obvious coding skills, or even with a couple successful open-source projects. It has to be nurtured consciously—or rammed down your throat by unforgiving reality; the latter is pretty traumatic.
To apply a formal method to your work requires to acknowledge that your intuition might me wrong, your past decisions incorrect, and your knowledge of the subject area deficient. Often you have to step back, rethink, and rework.
This is a normal mindset for a scientist, and a pretty common mindset for an experienced engineer.
But this view is not automatically acquired with an engineering diploma, with obvious coding skills, or even with a couple successful open-source projects. It has to be nurtured consciously—or rammed down your throat by unforgiving reality; the latter is pretty traumatic.
It is also tribalism.
When one is a polyglot developer, we are like mercenaries, a bag full of tools, each with its caveats, and we care about the solution less how we got there juggling those tools.
Developer X tend to keep searching for external confirmation that they did the right choice. Any attack on tool X triggers defensive attacks, as if they would be a personal attack.
Of course I am exaggerating here, just extrapolating from those that I know on my circle.
When one is a polyglot developer, we are like mercenaries, a bag full of tools, each with its caveats, and we care about the solution less how we got there juggling those tools.
Developer X tend to keep searching for external confirmation that they did the right choice. Any attack on tool X triggers defensive attacks, as if they would be a personal attack.
Of course I am exaggerating here, just extrapolating from those that I know on my circle.
It is also really easy to look over flaws when you work around them everyday. I used to be on the java hate train but now after using it daily I can barely remember why I used t take issue with it
I think it's just a knee jerk reaction to some academic/PL theory types that chime in with a "Huzza! Long live (Haskell/Scala/Ocaml/etc.)!" As if a lack of soundness is dawning on anyone and was anyone's issue to begin with.
It's pretty dramatic so it gets met with preemptive defensiveness.
From the end of article: Everything is broken. Everything is fine.
It's pretty dramatic so it gets met with preemptive defensiveness.
From the end of article: Everything is broken. Everything is fine.
In theory, as soon as a type system is unsound, it is unsound.
In practice, there are ranges of brokenness. If you have to go hunting for the problem, and it takes a combination of 5 obscure features which nobody would ever use together, it's not that big a deal. If it's the sort of thing that you encounter in any non-trivial program, well....
... your language dies.
Part of the reason so many people in this thread can be cavalier about type soundness issues is precisely that all the languages they use, being the languages that did not die because they have a crappy type system, are pretty sound, within the model the language is operating under, so, yeah, of course it doesn't look like a problem to a normal programmer, because it was solved a long time ago. Doesn't mean it's a bad idea, or that people should just sneer contemptuously at the issues and snidely dismiss them as academic frippery, because then these people go on to write new languages that have these sorts of issues.
(Like the recent wave of "event based" programming environments that just threw away the benefits of structured programming, because they were so thoroughly immersed in a structured programming world they didn't even realize how thoroughly they'd internalized it, had no idea what the preconditions were for it, and not only had no idea they were throwing it away but snidely berated people who pointed it out. And then spent 5+ years rediscovering it all over again....)
In practice, there are ranges of brokenness. If you have to go hunting for the problem, and it takes a combination of 5 obscure features which nobody would ever use together, it's not that big a deal. If it's the sort of thing that you encounter in any non-trivial program, well....
... your language dies.
Part of the reason so many people in this thread can be cavalier about type soundness issues is precisely that all the languages they use, being the languages that did not die because they have a crappy type system, are pretty sound, within the model the language is operating under, so, yeah, of course it doesn't look like a problem to a normal programmer, because it was solved a long time ago. Doesn't mean it's a bad idea, or that people should just sneer contemptuously at the issues and snidely dismiss them as academic frippery, because then these people go on to write new languages that have these sorts of issues.
(Like the recent wave of "event based" programming environments that just threw away the benefits of structured programming, because they were so thoroughly immersed in a structured programming world they didn't even realize how thoroughly they'd internalized it, had no idea what the preconditions were for it, and not only had no idea they were throwing it away but snidely berated people who pointed it out. And then spent 5+ years rediscovering it all over again....)
Seems like the project acknowledged issues and is working towards fixing them. There is no flame in it and discussion in bugs that were opened is factual.
[deleted]
My favourite feature of Java's type system is that, because any object type also accepts null, the type system is unsound and you can convert anything to anything else:
https://raw.githubusercontent.com/namin/unsound/master/doc/u...
https://raw.githubusercontent.com/namin/unsound/master/doc/u...
It should be noted that soundness is not a common feature for type systems in the wild. It sounds kind of scary, "X programming language's type system is unsound", but that's pretty much been the status quo for most of programming.
Our intuition about inheritance is pretty much all wrong.
I make analogies to taxonomy because before I learned software a biology teacher told me that taxonomy is also broken, so when I learned type theory it felt like a similar kind of broken.
We think putting wings to a mammal is adding behavior, when in fact it is subtracting it. Adding wings on a mammal means you have a bat, or a flying squirrel.
You have narrowed the potential of this type, not enhanced it. Anything else a mammal might do that bats can't? You've taken all of that away. Mammals with fly() aren't the fastest land animals. They don't have the record for holding their breath, or hibernation time. They can't dive(), speak() or useTool(). Really they're kinda useless except for vermin control.
I make analogies to taxonomy because before I learned software a biology teacher told me that taxonomy is also broken, so when I learned type theory it felt like a similar kind of broken.
We think putting wings to a mammal is adding behavior, when in fact it is subtracting it. Adding wings on a mammal means you have a bat, or a flying squirrel.
You have narrowed the potential of this type, not enhanced it. Anything else a mammal might do that bats can't? You've taken all of that away. Mammals with fly() aren't the fastest land animals. They don't have the record for holding their breath, or hibernation time. They can't dive(), speak() or useTool(). Really they're kinda useless except for vermin control.
This is probably why it's important to not anthropomorphize your code. Code abstractions do pretty much one thing: they prevent the duplication of code. They each do this in their own ways that make certain deduplications easier than others. If you focus on that, the broken analogy of taxonomy doesn't matter, and you can easily hop between the religious war camps of "OOP vs FP" and "Inheritance vs Composition". Figure out what you want your ergonomics to be and just go with that.
This is a correct observation, and also something to always remember. There are dark corners where unsound type systems fail, they inevitably exist in most practical languages, so you can wander into one in daily practice.
I was about to say this. Most type systems in practical use are not mathematically sound.
Is there a way to understand this tradeoff in a principled way?
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.
If I can serialize to String, and then deserialize a String to any type of class, I can effectively "cast" anything to anything.
The point is not that you can do explicit casts, it's that because you can form a (fake) instance for impossible types you can do invalid type conversions without doing anything that looks unsafe.
In Haskell you can certainly achieve the same thing with various common extensions ( http://okmij.org/ftp/Haskell/impredicativity-bites.html ). Possibly not in vanilla Haskell '98, at the price of being not a very nice language to work in. (A total language like Idris should permit GADT-like functionality without allowing this kind of issue).
In Haskell you can certainly achieve the same thing with various common extensions ( http://okmij.org/ftp/Haskell/impredicativity-bites.html ). Possibly not in vanilla Haskell '98, at the price of being not a very nice language to work in. (A total language like Idris should permit GADT-like functionality without allowing this kind of issue).
The actual correspondence in haskell are GADTs:
data EqualityProof a b where
Refl :: (a ~ b) => EqualityProof a b
-- compiler error because we don't check that the equality proof is actually Refl
coerce :: EqualityProof a b -> a -> b
coerce _ a = a
-- this works
coerce Refl a = a
-- here the Refl pattern match catches the undefined
-- this is like forcing the programmer to do a null check before the equality is in scope
-- and throwing a runtime exception when it's null
coerce undefinded 3 :: StringBy “convert” here I mean convince the compiler that any thing of type A is any type B, when it definitely isn't, without using an explicit cast.
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 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.
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.
Read about Bottom (⊥).
null can be considered bottom (if it were not for primitives)
null can be considered bottom (if it were not for primitives)
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?
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?
>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"
The very idea of the type system is that it makes "broken code" of a certain type a compile error.
The very idea of the type system is that it makes "broken code" of a certain type a compile error.
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.
This article gives a series of examples that break that promise.
In some situations. The examples in this article, I think, make it clear that for a lot of "broken code" these errors are caught. It's too bad that there are edge cases, but that is Java all over, in my opinion.
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?
"Is X really worth it if it isn't perfect and doesn't cover every edge case?"
I kinda feel like humanity has repeatedly decided the answer to this question is "yes".
"Being valuable" isn't binary. There are relative amounts of value, I think.
I kinda feel like humanity has repeatedly decided the answer to this question is "yes".
"Being valuable" isn't binary. There are relative amounts of value, I think.
Being valuable isn't binary, but you shouldn't stop in the middle if it's possible to do better easily.
I think that's always the conflict in these discussions. We can usually agree on how things work but your "broken and unsounds" is simply a "limitation" to others.
Saying things like "do better easily" makes sense in the context of fixing something that's broken.
But for anyone who just sees it just as a limitation this comes off as presumptuous. What do you want to change? How do you want to overcome the limitation? At what cost?
Saying things like "do better easily" makes sense in the context of fixing something that's broken.
But for anyone who just sees it just as a limitation this comes off as presumptuous. What do you want to change? How do you want to overcome the limitation? At what cost?
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 particular issues in Java. Bad code gets refactored.
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.
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 particular issues in Java. Bad code gets refactored.
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.
> … Dart… have optional type systems…
fyi "Dart’s type system is now sound" and "…types are mandatory".
https://www.dartlang.org/guides/language/sound-dart
fyi "Dart’s type system is now sound" and "…types are mandatory".
https://www.dartlang.org/guides/language/sound-dart
Wow great news! That makes Flutter even more exciting.
> 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.
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.
Type system helps those who help themselves.
If you don't like this example, you can always find cases where the limitations of the type system (or more specifically Generics) become apparent. This isn't quite so obvious during 'normal' application development, but if you start creating libraries or frameworks and you want generic type support, you will run into a wall very quickly.
Is it? The whole point of a type system is that it gives you guarantees over your code. Certain bugs should be inexpressible within the language.
Well, think of it this way. A seat belt cannot help you at all if an object flies through your windshield. Nevertheless, driving while wearing a seat belt is, overall, safer than driving without one.
This is HN, we don't need seat belt analogies. Very strict type systems forbid this class of errors during compilation, others do a best effort and fail at runtime.
Whoever you are, analogies can help clarify your thinking. A type system that prevents some errors is not without value just because it cannot catch others. If the uncaught types of errors are rare and the type system that would solve them somehow burdensome it may even be a reasonable compromise to accept these faults.
Of course. At this point I'm not sure what this has to do with the code snippet mentioned upthread or the response to it. Your analogy didn't really convey why you'd think java allowing "String s = gridWrapper.get(0).get(0).get(0);" is a good vs bad thing, it just tells me that types don't protect you from everything, I think. I didn't find that the analogy added anything valuable and instead kind of simplified a problem that didn't need simplifying. The topic isn't whether type systems are valuable, but whether the positive value of java's outweighs the harmful logic it allows the developer to write.
A language like rust can prevent writing code like that, and thus prevent that sort of error, while a language like javascript is even more lax. Both have their tradeoffs wrt productivity and performance.
A language like rust can prevent writing code like that, and thus prevent that sort of error, while a language like javascript is even more lax. Both have their tradeoffs wrt productivity and performance.
I was replying to someone implying that the type system was useless because it was not ironclad.
being that this is hn, the expression "class of errors" verges on being a thought terminating cliche.
Sure, and there's a point to all kinds of semi-strong typing. I'm glad Python does time checking at runtime, even it can't protect me from everything. When the type system becomes part of the grammar, it should be stronger than that though.
I don’t think that is true anymore. There are languages like typescript that don’t provide anything near that guarantee but are still seen as very useful.
The author is trying to write a concise example. You could achieve the same effect by writing three for loops, but that would take additional code and declarations that make his point less clear.
It's stupid code, but a type system has to be code agnostic. Otherwise you're back to dynamic languages with local type annotations.
In Java
f.get(0).get(0).get(0)
f[0][0][0]
f[x][y][z]
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.
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.
If he were to show real world example, few would bother to follow it through because it would be tens of lines of code spanning through multiple classes and namespaces.
What's the point of strong typing if it only saves you most of the time?
So a type-system that does the right thing in 99.999999% of the cases is completely useless according to you?
Don't throw out a number like that. We're talking about a Turing complete language, which means we're talking about protections that have to range over all possible programs and abstractions. It may be that your problem domain is extremely biased toward some small region of that space, in which case a type system that doesn't work there is actually useless.
Either way, it is hard to reason about factors like that numerically when we've not qualified which kinds of programs we're expecting the type system to actually work for.
Either way, it is hard to reason about factors like that numerically when we've not qualified which kinds of programs we're expecting the type system to actually work for.
I think the question is rhetorical.
Not really, a language in which some type errors are impossible (rather than merely very unlikely) makes it drastically easier to prove something useful about programs (e.g. to optimize away runtime checks that would otherwise be needed as a safety net and impossible cases).
> And this is, well, uhm, well... acceptable?
It is not. The only purpose of a type system is to prevent broken code from compiling. When it fails to do so, it is broken.
It is not. The only purpose of a type system is to prevent broken code from compiling. When it fails to do so, it is broken.
Typescript with its explicitly unsound type system show that a "broken" type system is immensely valuable, especially when you get something in return for that [1]
[1]: https://www.typescriptlang.org/docs/handbook/type-compatibil...
[1]: https://www.typescriptlang.org/docs/handbook/type-compatibil...
Well, sure, it's better than having an even worse type system! No one's saying java's type system is worse than not having anything.
Welcome to the world of enterprise-ready complex applications. I agree that these cases should be covered by the compiler but man, there are mainstream languages that don't implement generics just because they're complex and pretend that they're not helpful.
It would be nice of you to compare Java generics with equivalents instead of just criticizing it. It doesn't help anyone writing "this is broken" not offering any alternatives or suggesting ways to fix the problem.
It would be nice of you to compare Java generics with equivalents instead of just criticizing it. It doesn't help anyone writing "this is broken" not offering any alternatives or suggesting ways to fix the problem.
Clearly you didn't reach the conclusion. First, because the conclusion is not "Java sucks", but rather "Most of these things, while not kosher, are unlikely to happen in practice." Second, because the author didn't just leave it at criticising the language — he opened a bunch of bugs in the OpenJDK tracker.
People criticizing constructive criticism are often not constructive.
> It doesn't help anyone writing "this is broken" not offering any alternatives or suggesting ways to fix the problem.
Clearly stating and detailing problems is absolutely helpful. We can't solve problems if we don't understand them.
Clearly stating and detailing problems is absolutely helpful. We can't solve problems if we don't understand them.
>It doesn't help anyone writing "this is broken" not offering any alternatives or suggesting ways to fix the problem.
Actually identifying a problem is of very much help, even without a solution.
For one, it lets people know of the problem, so they can get to an eventual solution.
Second, it lets people know of the problem, and avoid those areas, even if there's no solution available.
Actually identifying a problem is of very much help, even without a solution.
For one, it lets people know of the problem, so they can get to an eventual solution.
Second, it lets people know of the problem, and avoid those areas, even if there's no solution available.
C# is a similar language in it's goals and architecture. LINQ to Objects type system will throw an error if you try to return conditionally different types from a lambda expression, so it is doable.
I think it would've been better to write "unsound" rather than broken, but it's pretty common to present little proofs/results like this without saying how the system should fix it. Doing so is helpful, because many times you'll know there's a problem without there being an obvious fix.
> It would be nice of you to compare Java generics with equivalents instead of just criticizing it. It doesn't help anyone writing "this is broken" not offering any alternatives or suggesting ways to fix the problem.
Hmm. If I knew your coolant was leaking, but had no idea how to fix it, would you prefer I didn't tell you? Just want to keep driving that car around with that coolant leaking?
At the very least, this is educational and helps better understand Java for those of us who work with it.
Hmm. If I knew your coolant was leaking, but had no idea how to fix it, would you prefer I didn't tell you? Just want to keep driving that car around with that coolant leaking?
At the very least, this is educational and helps better understand Java for those of us who work with it.
[deleted]
Here's another fun trick, though it's probably not a flaw in the type system: https://twitter.com/joshbloch/status/1018987317489426432.
Another flaw we can abuse is Java's covariant array types:
Object[] objects = new Integer[] {1, 2, 3};
objects[0] = "hello";
Yeah, compound types like that are a bit of a hack. During type erasure, the type variable gets reduced to its leftmost type (in this case, `String`), so the `main` signature ends up being a valid entry point. Best the compiler can do to enforce the right-hand type constraints is to insert cast instructions where values are used as insances of those types.
As the tweet shows, you still get (some) type safety from the runtime checks.
As the tweet shows, you still get (some) type safety from the runtime checks.
Disagree with bullshit term: heap pollution.
Pollution is the proliferation of superfluous objects creating some sort of undesirable mixture. For instance "namespace pollution".
An inconsistency between the run-time type of an object in the heap, and the type of the expression in the program which refers to that object, isn't a good fit for the word "pollution".
Quit trying to pollute the computing lexicon with nonsense.
Pollution is the proliferation of superfluous objects creating some sort of undesirable mixture. For instance "namespace pollution".
An inconsistency between the run-time type of an object in the heap, and the type of the expression in the program which refers to that object, isn't a good fit for the word "pollution".
Quit trying to pollute the computing lexicon with nonsense.
Looks like this is a thing in Java culture; good grief.
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.
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.
[deleted]
Website is struggling, here's a cache: http://archive.is/k2YbA
I was trying to justify the type safety of list in java to one of my senior, i am glad that i was right, it is indeed broken
Java generics are broken? What else is new?
* The Java is broken
Java is broken ¯\_(ツ)_/¯
This fact may be hacker but it is not news.
Oh good, another opinion about how this one thing in this one language is the worst thing ever, and also works just fine.
Find something that bothers you, complain publicly, do absolutely nothing after that, repeat.
Find something that bothers you, complain publicly, do absolutely nothing after that, repeat.
This is the correct conclusion. The people getting outraged over this are the same that will hold long and boring monologues about how everybody does REST wrong.