Pregled posta

Nova Java5 u usporedbi s novim C#-om 2.0 totalno jadna i porazena: generici u Javi ne vrijede ni pisljivog boba i C#-implementacija ih generalno tuce na svim poljima!

Bas danas sam gledala malo kako rade generici u novoj Javi5 u usporedbi s C#-om. Ljudi moji, ovo je prekrasno!

Naime, ako je ovo sto su dolje rekla ova, u svijetu programiranja, vrlo ugledna gospoda, Ken Arnold (vidi ovaj link: http://weblogs.java.net/blog/arnold/archive/2005/06/generics_consid_1.html ) i Anders Hajlsberg (link: http://www.artima.com/intv/generics2.html , posebno pogledati podnaslov "Comparing C# and Java Generics", ciji sazetak donosim dolje), onda ispada da su u novoj Javi zaista katastrofalno lose, slampavo, povrsno i neefikasno napravljeni generici, koji u biti uopce ne vode racuna o tome radi li se, pri njihovom instanciranju i supstituciji parametra za tip T, o "pravim objektima" ili o onome sto se u javi zove "primitivni tipovi", poput int, long, itd... : jer, kod generica u javi uvijek se obavlja supstitucija parametra T s tipom Object, a zatim se, u generiranom bytecodeu, po potrebi stalno radi cast tog objekta nazad u potrebni tip! Katastrofalno lose, amaterski i neefikasno uradjeno! Da i ne govorimo o problemima pri upotrebi refleksije nad ovim java genericima, koje refleksija jednostavno ne prepoznaje kao takve! Uzas!

C# je sa svojim nacinom rada s genericima i sa svojim posebnim tretiranjem tzv. value types i reference types, naprosto potpuno superioran ovoj jadnoj java-implementaciji! Uostalom, ako ne vjerujete meni, uvijek mozete procitati sto kazu strucnjaci, a ako ne vjerujete ni njima, uvijek mozete uzeti bytecod i proucavati ga, kao i promatrati izvodjenje u runtimeu, mjeriti ga, itd. Beskrajno me veseli to da su Sun i njegova bezvezna Java opet spushili od prekrasnog C#-a i superiornog Microsofta! Neka samo tako nastave i uskoro ce java biti stvar proslosti, HAHAHAHAHA! :D:D:D

Uglavnom, evo najznacajnijeg izvatka iz usporedbe generika u Javi i C#-u:

Bruce Eckel: How do C# generics compare with Java generics?

Anders Hejlsberg: Java's generics implementation was based on a project originally called Pizza, which was done by Martin Odersky and others. Pizza was renamed GJ, then it turned into a JSR and ended up being adopted into the Java language. And this particular generics proposal had as a key design goal that it could run on an unmodified VM [Virtual Machine]. It is, of course, great that you don't have to modify your VM, but it also brings about a whole bunch of odd limitations. The limitations are not necessarily directly apparent, but you very quickly go, "Hmm, that's strange."

For example, with Java generics, you don't actually get any of the execution efficiency that I talked about, because when you compile a generic class in Java, the compiler takes away the type parameter and substitutes Object everywhere. So the compiled image for List is like a List where you use the type Object everywhere. Of course, if you now try to make a List, you get boxing of all the ints. So there's a bunch of overhead there. Furthermore, to keep the VM happy, the compiler actually has to insert all of the type casts you didn't write. If it's a List of Object and you're trying to treat those Objects as Customers, at some point the Objects must be cast to Customers to keep the verifier happy. And really all they're doing in their implementation is automatically inserting those type casts for you. So you get the syntactic sugar, or some of it at least, but you don't get any of the execution efficiency. So that's issue number one I have with Java's solution.

Issue number two, and I think this is probably an even bigger issue, is that because Java's generics implementation relies on erasure of the type parameter, when you get to runtime, you don't actually have a faithful representation of what you had at compile time. When you apply reflection to a generic List in Java, you can't tell what the List is a List of. It's just a List. Because you've lost the type information, any type of dynamic code-generation scenario, or reflection-based scenario, simply doesn't work. If there's one trend that's pretty clear to me, it's that there's more and more of that. And it just doesn't work, because you've lost the type information. Whereas in our implementation, all of that information is available. You can use reflection to get the System.Type for object List. You cannot actually create an instance of it yet, because you don't know what T is. But then you can use reflection to get the System.Type for int. You can then ask reflection to please put these two together and create a List, and you get another System.Type for List. So representationally, anything you can do at compile time you can also do at runtime.

I, sto reci na kraju osim: cunac i ostali "javasi", dosta je vise bilo tog Sun-ovog "javasluka"! Vrijeme je za Sunovu sasvim zasluzenu smrt, kao i za jedno ovece upokojenje svima mile vam Jave, kao i za pompozno ustolicenje besprijekornog i najboljeg jezika na svijetu (C#-a), kao i najbolje platforme na svijetu: .NET-a i njegovog svemocnog CLR-a!

Patite gledajuci kako mastodont proslosti, Java, umire! HAHAHAHAHHAHAHA!

C#-pozdrav svima od vase najdraze
math_baby


Post je objavljen 30.06.2005. u 20:29 sati.