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

131–140 of 168 posts

Re: The Java type system is broken

#131

Post by mcculley »

icedchai wrote: post #120
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.

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.

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

Re: The Java type system is broken

#132

Post by icedchai »

mcculley wrote: post #131
icedchai wrote: post #120

Earlier quoted context omitted.

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.

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.

Re: The Java type system is broken

#133

Post by hota_mazi »

kjeetgill wrote: post #130
hota_mazi wrote: post #107

Earlier quoted context omitted.

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.

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

Re: The Java type system is broken

#134

Post by mcculley »

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.

If the types were reified, the compiler and the JVM would know what type was there. No cast would be needed.

Re: The Java type system is broken

#135

Post by teh_klev »

bunderbunder wrote: post #95
enitihas wrote: post #55

Earlier quoted context omitted.

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…

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

Re: The Java type system is broken

#136

Post by bunderbunder »

majewsky wrote: post #123
pjmlp wrote: post #101

Earlier quoted context omitted.

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?

fortran?

Re: The Java type system is broken

#137

Post by pjmlp »

majewsky wrote: post #123
pjmlp wrote: post #101

Earlier quoted context omitted.

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.

Re: The Java type system is broken

#138

Post by ionforce »

kochthesecond wrote: post #29
moron4hire wrote: post #23

Earlier quoted context omitted.

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.

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?

Re: The Java type system is broken

#139

Post by kazinator »

kazinator wrote: post #105

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 nons…

Looks like this is a thing in Java culture; good grief.

Re: The Java type system is broken

#140

Post by Tarean »

stingraycharles wrote: post #9
TazeTSchnitzel wrote: post #5

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

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.

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 :: String
Post reply on HN