[java] Question about generics

Started by
16 comments, last by princec 18 years, 3 months ago
Quote:Original post by princec
Generics can't remove run-time overhead as they are implemented using a technique called type erasure. The bytecode generated has no knowledge of generics at all. The compiler inserts casts in the code having already trapped most of the potential ClassCastExceptions at compile time.

However you should know that a runtime cast is an incredibly fast operation and nothing you should be concerned about.

Cas :)


Thanks, I'm not overly concerned about the operation. (Its probably on par with bounds checking an array, but doing a lot of that can make a program slow. Which it probably is checking some constant from the byte-code generation.)

Can you explain "type erasure" or point to some documentation please.

Thanks,
L-

[Edit:] Actually nevermind. Google found it for me, thanks.
"Education is when you read the fine print; experience is what you get when you don't." -Pete Seegerwww.lucid-edge.net
Advertisement
Quote:Original post by BitMaster
My C# knowledge is rather limited, but I believe their generics compile into a different class for each instatiation, which would elimate a few casts but might limit your ability to work with legacy code.
no, this would be how C++ works, making copies of the class specific to each data type used. C# utilizes one class that maintains type information on the data. It required a large change to the underlying CLR to make it work. However, MS is operating on a different philosophy for the .NET runtimes than Sun is for the Java runtimes. MS has decided to forgoe backwards compatibility and has enabled .NET runtime environments to coexist seemlessly with each other. So, theoretically .NET should not end up with the same API bloat of deprecated classes and methods as Java.

[Formerly "capn_midnight". See some of my projects. Find me on twitter tumblr G+ Github.]

That's why we're sticking with Java :) Need to know stuff is going to work everywhere, for a while longer! The Java runtimes co-exist peacefully with each other too.

Cas :)
Quote:Original post by princec
That's why we're sticking with Java :) Need to know stuff is going to work everywhere, for a while longer! The Java runtimes co-exist peacefully with each other too.

Cas :)

no, each subesquent runtime supercedes the previously installed runtime. While it may leave it installed, your programs will always try to run off of the latest runtime. With .NET, your programs will always try to run off of the runtime they were built with. I feel this is a better policy because I have seen first hand that the JREs are not fully backwards compatible, especially concerning graphical stuff.

[Formerly "capn_midnight". See some of my projects. Find me on twitter tumblr G+ Github.]

No, that's not true. The default behaviour is to run with the latest version of the JVM, but you can a) embed the runtime in your software bypassing the problem completely (like I do) or b) specify in the Webstart JNLP file which VMs you want to use and the order of preference that they should be used in, to some degree.

Cas :)
Quote:Original post by capn_midnight
Quote:Original post by BitMaster
My C# knowledge is rather limited, but I believe their generics compile into a different class for each instatiation, which would elimate a few casts but might limit your ability to work with legacy code.
no, this would be how C++ works, making copies of the class specific to each data type used. C# utilizes one class that maintains type information on the data. It required a large change to the underlying CLR to make it work. However, MS is operating on a different philosophy for the .NET runtimes than Sun is for the Java runtimes. MS has decided to forgoe backwards compatibility and has enabled .NET runtime environments to coexist seemlessly with each other. So, theoretically .NET should not end up with the same API bloat of deprecated classes and methods as Java.


Doesn't C# (or the CLR, of whatever) specialize generics for struct-types (so, no boxing necessary, and better performance), but reuses one single class for class-types (but which contrary to java has still access to type parameter information)?


Found it: On MSDN

Quote:
When a generic type is first constructed with a value type as a parameter, the runtime creates a specialized generic type with the supplied parameter or parameters substituted in the appropriate places in the MSIL. Specialized generic types are created once for each unique value type used as a parameter.
Quote:Original post by princec
No, that's not true. The default behaviour is to run with the latest version of the JVM, but you can a) embed the runtime in your software bypassing the problem completely (like I do) or b) specify in the Webstart JNLP file which VMs you want to use and the order of preference that they should be used in, to some degree.

Cas :)

two problems with your two solutions. Letter A kills binary cross platform compatability. Letter B presupposes that one is using Webstart, which is quite buggy in its own right.

[Formerly "capn_midnight". See some of my projects. Find me on twitter tumblr G+ Github.]

Binary cross-platform compatibility is some sort of techno-utopia which is a bit of a joke in the real world of application deployment. If you want to use Java and deploy reliably anywhere, you must embed the VM for Windows and Linux deployments, period.

Yes, Webstart is a bit shit, but at least it's being improved ;)

Cas :)

This topic is closed to new replies.

Advertisement