Discussions

News: Sun to add Generics and Assertion as part of Java 1.4

  1. Generics and Assertion are good features but it is
    bound to increase size of Java language..(ie more things
    to learn as part of Core Java language)..

    The good part is that will reduce size of Collection Objects and may increase performance... eg No more
    casting for say ArrayList of Strings...

    Read Story Here

    Threaded Messages (42)

  2. I'm pretty sure (unless there have been some last-minute changes I am not aware of) that generics will not be a part of JDK1.4. There are plans to incorporate generics in JDK1.5 though.
    The generics JSR is not yet finalized, and the JDK1.4 beta reflection API doesn't have the suggested changes for generics, so I really don't think it will be available in 1.4.
  3. Yes, generics are *NOT* part of the 1.4 spec:

    keynote details

    About a third the way down the article under the heading "For Developers: New Additions to the Language", is the following:
    "Gosling claims that Generics, also known as Templates and Type Polymorphism, is the most requested new feature and currently missing from the platform. It will be added to release 1.5 after it goes through the approval process in the JCP program."

  4. Have it today, just use a preprocessor in your makefile...
  5. Even though Gosling said that he really liked the compromise that the participants in the JCP reached, I still think they are completely missing the target. In a nutshell, the syntax is C++-like and provides type safety where downcasting from Object was usually needed. So far so good. The catch is that the proposal is totally compatible with the current JVM's: no bytecode ops have been added. And that's a big mistake.

    Some of the reasons why I think this is totally misguided:

    - It is my experience that type safety is not that big a deal in the day-to-day life of a Java programmer. There are several occurrences where you can get bitten by this, but I found that only one was admittedly a pain to debug: putting an object in a HashMap and inverting key and value. Other than that, I don't get that many ClassCastExceptions with my containers, I usually know what I put in them and the codes that write it and read are typically colocated in the same VM (see below for exceptions to this)

    - A dynamic cast is costly, even more so when the involved objects implement interfaces. I think this is the main drawback of lack of templates, and it is not being addressed by the proposal, which is merely syntactic sugar without any runtime impact

    - Introspection and heavy distribution of Java code will probably make generics not that relevant anyway. When an EJB returns a collection of objects to a client, generics don't add a lot of robustness to the application

    - There are no plans to add anything that would alleviate typing and redundancy of code (such as typedefs). For example, we're going to type numerous lines such as

    List<Integer> l = new List<Integer>();
    ...

    Regardless of the fact that it's a lot of extra typing (which can be avoided by a smart editor), it is very error prone and will lead to code that is both hard to grep and to read. The speaker (and tech lead for the JCP) said that the readability problem plagued C++ and that they had solved it with Java generics... yeah right.

    It would be unfortunate for Java if generics made it into the language. I really loved templates in C++ (the C++ committee guys really know their stuff) but they are not welcome in Java.
  6. Cedric,

    With all due respect, if Java properly supported generics, our systems would perform much better. All of those casts are extremely expensive. Unfortunately, these casts aren't eliminated in the bytecode. I'm dissappointed about that.

    Because we get no performance benefit from not having to cast... I'd almost be willing to agree that they aren't worth bringing into the language.

    But the covariance is something that I really want. And I'll take it in any form I can get it. Developing any kind of good abstract framework _screams_ to have covariance available for efficient modeling and design.

    Really though... paramterized-types, covariance, and enums are an important part of any truly OO language. Java isn't a 'kid' on the block, anymore. It is time that Java grew up a little bit and graduated to the next level, IMHO.

    This doesn't solve all of the OO-lackings of Java. It probably gets us 30% there. But I'll take what I can get.

    Sun is so damned slow about releasing anything new in the language, I'll settle for any OO tidbits that they throw out.

    Regards,

    Rick

  7. Hey Cedric, where did you hear that typedefs will not be considered for Generics? The article in javaworld seems to hint otherwise:

    http://www.javaworld.com/javaworld/javaone01/j1-01-sintes3.html

    I think typedef is a double-edged sword. Like you said, it increases readability, especially for "generic arrays":

    Map<Key, String> = new HashMap<PrimaryKey, String>();

    will become:

    KeyStringMap = new KeyStringHashMap();

    But many times, increased readability occurs only for the person who wrote the code! Those who developed in C++ and have seen out of control typedef codes know what I'm talking about! :-)

     
  8. Gene,

    I got this information from the presenter at JavaOne himself (who is the tech lead), so I suppose this information is more recent than the JavaWorld article. I was about to ask him the question myself but somebody else beat me to it.

    He said that right now, typedefs weren't part of the proposal but they are aware of the issue and if there is enough pressure, they will consider adding them.

    I think that the Generics proposition should contain:

    - The current gj-like implementation
    - Modification of the bytecode in order not to incur the overhead of casts
    - A (possiblity limited) aliasing mechanism such as typedef

    If one of these three items is missing, I think that adding Generics to the language will do more harm than good.

    Although I have to say that these three items are fairly heavyweight themselves, and it will be very hard to assess how they impact the language in general.

    I guess the conclusion should be: leave the language alone :-)
  9. They finally added a regex package in the core though!
    Much needed IMO.... such a common thing to want (just look at other languages that support it). I hate having to grab third party regex libraries all the time (although those libs are really good (ORO -> Apache Regex)

    Dion
  10. Speaking about templates and generic programming they should add to 1.4 or 1.5 more powerful collections framework. Good example of such API is STL conversion to java (JGL from objecspace). I miss STL consepcts in java

    ps: sorry for my english
  11. I didnot attend JG's keynote at javaone. But from the sessions I attended I thought its pretty clear that Generics is not part of 1.4
  12. I am almost positive that I read around the web that there is undocumented support for Generics in 1.4. Try searching the jBoss.org mailing list archives. I'm sure it was discussed there.

    I'm not sure how the generics mechanism works, but surely the best thing to do would be to have the classloader create an instance of a Class object at runtime for the first instantiation of a generic collection and then use that to provide new instances from then on. In this way, there is no dynamic casting going on.
  13. Generics haven't made it into Merlin (1.4).
    This was stated at JavaOne during a talk on Generic Java.

    There is a prototype compiler that supports Generics available from Sun that produces 1.3 compatible classes.
    Head to http://developer.java.sun.com/developer/earlyAccess/adding_generics/ for details. (Need a Java Developer Connection login.)

    I've seen comments that during the talk at JavaOne the speaker said that one of the downsides to the JCP is that participants can easily block implementation of new standards - and that one of the vendors was blocking Generics as it would be difficult for them to get it into their tools. Any opinions?
  14. This is indeed true, at least as far as 1.4 is concerned, and the culprit is IBM.
  15. I have been waiting literally years for generics to be added to the Java language (not so much assertions, though).

    The usage of generics with allow developers to create better designed, more abstract, object-oriented libraries to support their applications.

    Generics in Java will give a benefits including (but not limited to) the following :

    1) Compile-time typesafe collections.

    Currently, Java does not have a mechanism for declaring typesafe collections. This usually means that developers have to perform a non-typesafe cast when retrieving an item from a collection.

    For example. Here is a current example of a collection:

    {
      List myList = new ArrayList();
      myList.add(new Integer(1)); // Not typesafe
      Integer myInt = (Integer)myList.get(0); // UGLY and not typesafe
    }

    Here is the code which can be accomplished using generics:

    {
      List<Integer> myList = new ArrayList<Integer>();
      myList.add(new Integer(1));
      Integer myInt = myList.get(0); // CLEAN. No cast required
    }

    That is not to say that 'in the background', Java will be optimizing your code without the cast. Actually, generics in Java will be implemented using a tool called Generic Java (GJ). GJ is really a compiler-patch (pre JDK1.4) which will perform the compile-time type code checking of collections. It doesn't do any code optimizations by eliminating the actual cast in the byte-code.

    2) Covariance.

    To me, this is the best benefit that I can see of generics in Java. This will allow you to do many things with respect to return types of methods and method argument types.

    Covariance in Java will permit for more elegant and abstract desigining of frameworks. I've been waiting for this one a long time.

    If you want more info on these concepts, you might want to check out the 'Eiffel' language. Looking at some good Eiffel code will teach volumes.

    ========

    As a sidebar, the only things I don't like is that we don't get 'enums'. I think enums are incredibly useful. Why they were left out of the language, I have no idea.

    ========

    Well... that's my short explanation. I can't do generics justice in a single post. Like I said, go check out a book on Eiffel and download the compiler/IDE. After a few months of playing around, it opened up my language-brain to a whole new world of OO possibilities.

    Regards,

    Rick
  16. Rick,

    I'm not sure how you see that generics will add covariance to Java, can you detail?

    Covariance is a totally different beast than generics, and I have to say I am more accustomed to contravariance by now, but I am usually easily convinced by a solid example and some code to back it up :-)

  17. Cedric,

    No problem with providing an example. I also understand _exactly_ what you mean about getting used to contra-variance. Hell, I'm so used to it now that I forgot what I was missing. Here's a derived example straight out of the GJ documentation... (and after my own heart -- I have always HATED cloning -- until GJ came along). Let's clone a person... something also near and dear to my heart!

    public class Person implements Cloneable
    {
        public Person clone()
        {
            Person p = null;

            try
            {
                p = (Person)super.clone();
            }
            catch (CloneNotSupportedException e)
            {
                e.printStackTrace();
            }
            
            return p;
        }
    }


    public class RickTest
    {
        public static void main(String[] args)
        {
            Person person1 = new Person();
            Person personClone = person1.clone();
        }
    }

    No casts. And the overriding of the parent method with a covariant return type.

    Personally, I could put this to use so effectively in several things I am working on.

    But we have to get out of that contra-variant way of thinking first.

    Regards,

    Rick
  18. wrong way[ Go to top ]

    I recently have read the JSR-014 Generics in Java spec.

    My disappointment was as deep as when I first read Collections framework spec.

    I think that Sun had to get PolyJ as a base, not Pizza and GJ. Probably, it's because Sun developers were involved in GJ, and lobbied inside.
  19. wrong way[ Go to top ]

    Argyn Kuketayev wrote:

    My disappointment was as deep as when I first read Collections framework spec.

    ---------

    No joke. Disappointment is an understatement. I recently had a discussion with the JSR-lead, Gilad Bracha, about the whole thing. I was _so_ looking forward to getting rid of most of my reflection-based code, for safer (even perhaps faster) generics-based code.

    Gilad and I seemed to agree that a 'structural, concept-based' approach would be a valid way of adding this sort of power to the Java generics implementation (as opposed to the current C++ approach), but he believed that it would be too great of a change to the language. I don't know if they will ever consider adding it [sigh]. Makes me wonder if it is time to create a new language targetting the JVM. Hmmm... Ayone want to help me implement Java.Next?

    If you agree that Java generics should be much more powerful, then why don't you e-mail Gilad (gila dot bracha at eng dot sun dot com) and tell him how you feel? He's quite responsive and pleasant to speak with. (He's also working on a proposal for adding lambda classes to the language. [WooHoo!])

    God bless,
    -Toby Reyelts

  20. wrong way[ Go to top ]

    Argyn,

    I'm not a Microsoft advocate (or detractor). Neither am I for Sun.

    I think C# is that next language you are talking about. If we are lucky enough to see C# runtimes appearing on different operating systems (which is required by the ECMA) then we will have the language we need.

    C# is extremely well-designed and has all of the features that we as Java developers would want.

    Unless Java goes open source, I don't see if including true generics and PTs in the future at all.

    Regards,

    Rick
  21. ==========================
    Toby,

    When I first read JSR-014, I wanted to write a paper on comparative analysis of PolyJ and GJ approach to parameterized classes in Java. Now I realize that I'm so overloaded with my current e-com project, that I'm not sure I'll have time to do it this Summer. Unfortunately, it seems that Sun has already decided to go with GJ as a base for generics in Java. It's a pity.

    I don't have a space and time to express my thoughts about it, but my feelings are:
    1. proposal introduces generics in such a way that it took me two evening to understand how it all works. It's too complex, and it introduces a lot of non-obvious side effects with casts etc.
    2. primitive types are not supported
    3. "unchecked" exceptions kill me
    4. it seems that now we are trapped by Java's initial roots in Oak and its embedded origin. Java was going to be a simple language. it closely approached its boundaries of growth. any new feature to implement is a pain for Sun and all vendors
    5. Sun wants keep Java simple. result: ugly terrible Java Collections Framework. it's mutant, hybrid, weird library. everything there is an Object, no type-safe containers on one side, and on the other it's not dynamic like Smalltalk. JCF is an example of what happens when you try to jump over the hole in two steps - you fall down. the "simplicity" of JCF, leads to complexity in our code, and a final result - our programs - don't get neither smaller and nor more stable
    ====================================
    Rick,

    for some reason I dislike C#. It's mostly irrational: because it comes from MS, and these guys always trap their developers in a cage. You take their tools, hoping for better future, and you find your self bound to their bandwagon :)

    I remember in VB, first we got DAO (data access objects), it was supposed to be the primary DB access method replacing ODBC. then we got RDO, and DAO was declared ineffective and not-recommended, we ported all our code, then we got ADO with OLEDB.... etc. I don't know where's the trap this time with C#, but I'm sure there is. It's MS.
  22. Argyn,

    Here's some feeback I have on your comments:

    First, Sun may have decided to use GJ as a base, now, but the first generics implementation isn't due out until 1.5. That's at least over a year. That would give them plenty of time to think about it more. Sun has been known to change there mind when there's been lots of developer outcry over a topic.

    About your feelings on generics:

    1) I'm not so concerned with complexity as I am with expressibility (power). Readability is important, too, but I don't think the current syntax is too bad.

    2) Java will always suffer from primitive types causing problems all over the place until they come up with something like automatic boxing. I'm not sure why a feature like this hasn't already been added to the language. AFAIK, people who don't want to pay a space/speed penalty, don't have to. They just don't let their primitives get boxed.

    3) Can you elaborate on what you mean here? If you're talking about the fact that I can write code like Vector v = Vector<String>(), I agree that this is nasty, and I hate the concept of 'type erasure'. It's something I don't want to have to think about when programming.

    4) I don't think it's language changes that Sun is so worried about... it's the JVM that concerns them. If they change the JVM spec, it can easily mean an incompatible change. I'll give Sun kudos about caring so much about backwards binary compatibility. However, there are times where I just wish they'd bite the bullet and make the change.

    5) I don't think the Collections framework is too bad, myself. But I believe it could probably learn a few things from the C++ standard library. Of course, this is a perfect example where lambda classes would really be highly beneficial to the language.

    ---------

    As far as C# goes, it's hardly a revolutionary language. It's an obvious Java clone with a different API, and some minor tweaks. In fact, you could probably write a compiler that would support 99.5% of C# and target the JVM.

    The C# language only exists, because MS couldn't swallow it's pride and continue with Java. On top of all of this, with MS's track record, I don't trust them further then I can throw them.

    God bless,
    -Toby Reyelts
  23. Toby,

    Also, see my message to Argyn about C#.

    I don't know how you think that the Java VM can embody 99.5% of what the C# language can do. It certainly can't. Mainly because it has covariance, templates, true parametric types, enums and a number of other language features that Java couldn't handle without a complete rewrite of the VM.

    C# takes a lot from Java. I agree. So what? Java takes a lot from C++. What's your point? And C++ takes a lot from C.

    And as far as trusting Microsoft, I don't. But I don't trust Sun, either.

    Sun refuses to put their language into the open-source community or at least give it to an independent standards committee for management. Their licensing structure is atrocious and barbaric (finacially speaking). They get around to fixing bugs very infrequently. They have LOTS of problems.

    As a serious advocate of the open-source initiative, Java (to me) represents the same thing that Microsoft does. From an open-source perspective, that is.

    Microsoft haters, Sun haters. Personally, I think both companies are propaganda-spinning-techno-rapists who are trying rule the industry and innovation with a stoic, and unmovable iron fist.

    Well... screw them.

    Regards,

    Rick


  24. Rick,

    You said:

    I don't know how you think that the Java VM can embody 99.5% of what the C# language can do. It certainly can't.
    ---------

    I beg to differ.

    1) covariance - What kind of covariance does C# have that can't be supported by the JVM?

    2) templates - Humm.. C# doesn't have templates. Java already has a proposal and working implementation of generics.

    3) true parametric types - As I said, C# doesn't have templates. For Java, if you want more powerful features than the proposed generics, they _can_ be implemented using the existing JVM. It's the generics JSR team that is currently deciding to limit generics to the current proposal.

    4) enums - You can emulate enums as a language feature. It doesn't require any new support from the JVM.

    Can you really name anything I can't do with the JVM that C# can do with the CLR? You might be able to find something, but that's where the 0.5% comes into play. Again, neither C#, nor the CLR, are anything innovative.

    Btw, there was once a thread on Microsoft's C# newsgroup about just this. You might be interested in reading it.

    God bless,
    -Toby Reyelts
  25. Toby,

    Alright. I guess I'll list a few major differences and let you decide if their weight is only 5%. Some are off the top of my head, and some are straight out of Anders Heljsberg's book on C#. I'm including those that I feel are big differences...

    1) Operator overloading.
    2) Templates are not directly allowable in C#, but can be used in C++ libs which can be directly included in C# code.
    3) No distinction between primitives and objects. *HUGE*
    4) Native support for class properties.
    5) Decimal data types with enough precision to handle financial/scientific applications. Java's 'double' isn't enough.
    6) Dynamic (variant) typing.
    7) Unsigned primitives.
    8) Class properties (very convenient)
    9) Delegates (dynamic and virtual methods) (I love these)
    10) Enums. You discount them easily. Either you are light on 'C' or you forget what they do. Enums are much more typesafe than the having to create statics in Java. Enums also are permissible in a 'switch' statement. VERY NICE. Even James Gosling said one of his biggest regrets was not putting enums into Java.
    11) Structs. Self-explanatory. Don't even compare with public final static variables. Structs can be allocated on the heap or off.
    12) in, out, and ref parameters (even for primitives)
    13) Pointer arithmetic (don't bawk. They have their place.)

    Including these things in Java would be hugely difficult and an overhaul of the VM.

    BTW, don't talk about simulating C# features in Java -- that is apples and oranges. 'Simulation' is not the question. The question is about the *features* themselves.

    Look... I like Java. But I like C# more. Like I said... of COURSE C# comes from Java... as Java comes from C++. And it improved it, but took away some good features. But to say that the added features that C# has over Java is only 5%... I think you're being stubborn and discounting.

    Believe me, if I had my choice, we'd all be using Eiffel. Which has them all beat for language features and OO elegance, IMHO.

    You need to read all of the requests for some of the C++/C# style semantics on Javasoft.

    Java has weaknesses, Toby. You may as well acknowledge it.

    Regards,

    Rick

  26. 1) Operator overloading - This is syntactic sugar. No VM change.

    2) Templates - Please, let's not bring up templates anymore. C# obviously loses the battle here.

    3) No distinction between primitives and objects. - I believe primitive boxing can be done with the VM as is now (with compiler help). I have to test it out to make sure, though.

    4) Native support for class properties. - C# has no native support for properties (and neither does the CLR). Again, this is just compiler magic, even in Microsoft's C# compiler.

    5) Decimal data types with enough precision to handle financial/scientific applications. Java's 'double' isn't enough. - This is hard to argue against, because I don't know the details of C#'s double type. Could you elaborate?

    6) Dynamic (variant) typing. - You'll have to explain what you mean here. If you're talking about unions, then this can be simulated using polymorphism.

    7) Unsigned primitives. - Compiler magic.

    8) Class properties (very convenient) - It seems that you're repeating yourself here.

    9) Delegates (dynamic and virtual methods) (I love these) - Again, functors are better for multiple reasons.

    10) Enums.

    How old are you and how long have you been writing C? I've been working in both C and C++ for about the last 8 years (though I avoid C whenever possible, because at worst, C++ is a better C).

    I specifically said that enums can be implemented with compiler magic (which they can). I did not say that the user would write public final static ints. And, frankly, enums _aren't_ that typesafe, and if you think otherwise, _you_ are light on C.

    11) Structs.

    Umm... I would never equate structs with public final static variables. They are orthogonal features. As far as structs being allocatable on the stack, generational garbage collectors don't even have to collect objects with short life-times, regardless of whether they are a full blown class, or a simple struct (all public data members).

    12) in, out, and ref parameters (even for primitives) - All should be possible with compiler magic.

    13) Pointer arithmetic - Can be done with compiler magic, though it might be slow. This is one feature, though, that I can say I am happy leaving out support for.

    As you can see - these features don't rely on changes to the JVM. Lots of compiler magic - yes, but that's what compilers are for.

    ------
    Rick wrote:

    BTW, don't talk about simulating C# features in Java -- that is apples and oranges. 'Simulation' is not the question. The question is about the *features* themselves.
    ------

    Lol. Like class properties, right? Compilers are for implementing magic. If they were limited to the primitives of the machine we were targetting, we'd all be using branch statements instead of for and while loops.

    ------
    Rick wrote:

    Java has weaknesses, Toby. You may as well acknowledge it.
    ------

    Oh, I never said that it didn't. I said that C# is nothing revolutionary, is a Java-clone, and almost anything C# can do, I can do on top of the JVM which existed many years before C# or the CLR came along.

    God bless,
    -Toby Reyelts
  27. Toby,

    I'll relent here. Because the point that you are proving and the point that I am trying to prove are different.

    If you are saying that the VM, with the appropriate bytecodes, can do anything that C# can do... I'd say you are correct. Because ultimately, there really isn't much difference... a VM is a VM is a VM. Everything translates native ultimately. System.out.print == printf == PRINT == echo == Console.WriteLine == DISPLAY UPON CONSOLE... etc... etc... etc. You get no argument from me there. Your point is well received.

    My point, in my opinion, is that C# is more feature-rich than Java. In design, it has everything that Java has, and more. You dismiss it as syntactic sugar, but I don't understand your dismissal. It evades me.

    You seem to simply concentrate on the output. While I also concentrate on the results, I am also concerned about the process. I am concerned with how you get there. With the time and efficiency involved. Thats one reason why I enjoy Eiffel and its DBC methodology. Though you dismiss it as syntactic sugar, I actually think it serves a good purpose.

    I never said that C# is anything new. I said the opposite. Neither was Java anything new. Java was C++ minus. C# is somewhere in between both.

    But I agree with your point. Java can do anything that C# can without a VM change. Yes. So can COBOL, or C, or Eiffel, or any other robust, widely-used language.

    I can pound a nail into a board with many different kinds of hammers. But that doesn't mean that they are all created equal.

    Best regards,

    Rick



  28. Re: C# like Java[ Go to top ]

    Rick wrote:

    C# takes a lot from Java. I agree. So what? Java takes a lot from C++. What's your point? And C++ takes a lot from C.

    -----

    There are vast differences between C, C++, and Java. I find them so numerous, that I won't bother going into detail here, (but if you really want me to, I will). Suffice it to say that the major thing Java inherits from C++ is its cumbersome syntax, which makes it all the more hilarious that Microsoft would continue the tradition with C# [sigh].

    On the other hand, people can sum up the differences between C# and Java in a two paragraph article. The problem is _not_ that C# borrows from Java. The problem is that C# is a _clone_ of Java.

    God bless,
    -Toby Reyelts
  29. Re: C# like Java[ Go to top ]

    On the other hand, people can sum up

    > the differences between C# and Java in
    > a two paragraph article. The problem is _not_
    > that C# borrows from Java. The problem is
    > that C# is a _clone_ of Java.

    That's a very simplified view of the world. C# has a lot of interesting features that Java doesn't have, which is not exactly surprising considering that it is five years younger (which has both good sides and bad sides).

    Some of the features that would make it very hard to port C# on a JVM would be, off the top of my head:

    - infix operators (and overloading thereof)
    - delegates (very useful feature)
    - boxed types

    C# is a very interesting language which might be a little bit overloaded with functionalities (mirroring Java which is slightly lacking in some areas).

    My main biffs:

    - uppercase naming of API methods (not a problem for Win32 developers but a pain when you've been writing Java for six years)
    - only runs on Windows

    That being said, the coolest thing of all is definitely the CLR, which dwarfs C# in brilliance.

    --
    Cedric

  30. Re: C# like Java[ Go to top ]

    - infix operators (and overloading thereof)

    I'm not sure what you mean by 'infix' operators. If you're talking about operator overloading, that should be a simple feature to add to the language, no VM change required.

    - delegates (very useful feature)

    IIRC, delegates are essentially function pointers, and are thus inferior (both in speed and functionality) compared to functors.

    - boxed types

    I'm investigating this right now. Off of the top of my head, it seems that a little compiler magic should get you there, but I can't say for sure, yet.

    I hardly think my view is simplified. You'll have to give me something substantial to change my mind.

    God bless,
    -Toby Reyelts
  31. Toby

    1) I think that readibilty/complexity problems with JSR-014 come because of too many contraints applied to JSR. Sun doesn't want JVM changes, Java is "old", legacy code compatibilty etc. That's why entire JSR-014 doesn't look elegant, it's a sort of heavyly traded-off.

    2) I like PolyJ's approach where primitive tipes have "quazi-methods". Primitive types will never be the same as objects in the current JVM. However, it's sort of natural, if int has "add" method. So,
    Interface Set<T>{boolean equals(T)}
    whould work with int too, because it has "equal" method. I feel that there must be some change in JVM. making primitive types closer to classes would help to make our code simpler.

    3)I mean the code like
    Class Foo{
    <T> T[] array {return new T[]}
    }

    there'll be unchecked exception, because as you said run-time type info is "erased". erasure is not the right thing at all. casts and instanceof will return trash, as well as getClass() :(

    4) sure, Sun doesn't want to change JVM. is it bad? I don't know. Intel went to protected mode from 286 to 386. It was a big change. and it was right decision. Maybe it's time to change JVM?

    5) I believe Collection framework is more like step back, rather than step forward. JGL was better. Collections framework had to be similar to STL, based on generic programming. It's so obviosly factorized to containers and algorithms.

    Thanks, Argyn

    5)
  32. Argyn,

    Well, I'm both a Microsoft and Sun basher.

    Don't talk about vendors trapping developers in a cage, though, Argyn. Sun has been doing the same thing to us since Java came out.

    They don't fix bugs for YEARS. They don't add features that we want. They constantly create 'new' platforms (like EJB) without solidifying the language core and foundation. They aren't open source. They don't have any standards committee to report to. BELIEVE ME. They suffer the same problems.

    I have felt like a trapped snake using Java for a long time now. It isn't just Microsoft.

    I'm not a Microsoft-advocate, nor a Sun one. But I can at least look objectively at the C# language and see how well done it is. I also see a few weak points. But far less than Java.

    The biggest problem is cross-platform capability. Until they get that -- and I believe the next target platform will be Linux -- then I won't fully support it either.

    But as a language, it is very nice, IMHO.

    Regards,

    Rick

  33. Rick,

    I just looked at C# spec, I didn't find anything like parameterized types in C#

    could you please point me to the section in MS specification, where parameterized classes are described

    Thanks,
    Argyn
  34. Argyn,

    Generics are being added to the next rev.

    Regards,

    Rick
  35. Argyn,

    Also, see the following thread (and others) where the addition of generics and templates are on the map to be added to C#.

    http://groups.google.com/groups?hl=en&lr=&safe=off&ic=1&th=8713bfa91afd92cf,10&seekm=urn3pwNvAHA.1196%40tkmsftngp02#p

    Regards,

    Rick
  36. Rick,

    when templates will be in C#, then we'll discuss it :)

    I was surprised to get 300+ pp document with C# specification. I recall times when Mr Wirth wrote that language must be specified in 40 pages.

    So far I didn't find any significant advantages of C#/.NET over Java/J2EE.

    Argyn
  37. Argyn,

    I agree with you on this point.

    Excepting that the .NET framework is specified to be language-independent (at least as far as the CLI)... whereas J2EE is not. But they haven't implemented any other non-Microsoft languages as yet.

    Right now, .NET really only makes sense on Win32 platforms. We'll see in the future if it makes sense on other platforms as well. But right now, I can't see it.

    Best Regards,

    Rick
  38. Rick,

    CLR and JVM don't differ in multi-language capabilities. Nothing prevents you from writing a compiler from any language to MS IL or to Java byte-codes.

    My understanding is that MS promises better integration with the legacy code (read COM apps). In reality, it doesn't seem as seemless. In CLR non MSIL code (COM code) is not going to be an "equal citizen" as its "native" code. Basically, I believe that it'll be the same situation as now with JNI/Java, maybe a little smoother.

    Argyn
  39. Argyn,

    Concerning the bytecodes, you are correct. I'm not trying to say that anyone can write a compiler to target anyone else's VM for any language. We all know that can be done. That is a given.

    What I am saying is that the .NET framework has a CLI (Common Language Interface) already defined for it on paper. Any .NET language would have to implement the CLI fully in order to be considered compliant with the .NET specification. It is well-defined and has been given to a standards body.

    Java has no CLI. Unless we consider the entire JSR itself as a CLI specification. Which really isn't its intention. Not do I think it reasonable. Really only the core Java libraries should be considered CLI-capable. Maybe a few of the javax libraries.

    Java is not _intended_ as a multi-language platform, whereas .NET is intended for that very purpose.

    That was all I was trying to say.

    Best regards,

    Rick

  40. Rick,

    I looked at C# spec once more on weekends. Can you explain me this:

    1. I didn't find anything about covariance. example

    System.Collections has ArrayList with
    IEnumerator GetEnumerator()
    can I make a sublcalls MyArrayList with
    MyEnumerator GetEnumerator()?

    the idea is to have type-dafe collections.

    2. In IEnumerator there's a field Current. Why it's not a method but field? what about covariance here? I want Current to be MyType in MyEnumerator, for the sake of type-safety

    General comment, I found that the specification is too thick. So many key words. I think for poor VB crowd who couldn't handle even simpler Java, C# will be nightmare with its "sealed", "virtual", "override", etc. :)
    In Java all methods are virtual, in C# it's like in C++.

    thanks,
    argyn
  41. Argyn,

    C# will be simple for people who know Java. C# will be simple for people who know C++. C# will be as difficult to learn as Java is. I don't think it is intended to be picked up by the VB crowd. Obviously, I think its target audience is Java programmers and C++ programmers. I wouldn't expect a VB programmer to go and learn C#... not without a large learning curve. C# will be easy to pick up for Java and C++ programmers. I think C programmers will have more difficult time.

    I don't think that's a disadvantage, though.

    Covariant return types (like generics) are on slate to be included in revision 2. I know, I shouldn't mention them until they're reality. But I know for a fact that they are being worked on as we speak. The two biggest requests from the C# community have been generics and covariant return types... and they have publicly stated they are most likely going to be included in the spec in the next release.

    The thing that I want in the spec that hasn't been stated as going in in native security model. Java's security model is wonderful. C# really has no security model to speak of.

    But one can hope... :-)

    -- Rick



      

  42. Rick,

    That's not exactly the example I had in mind. You were connecting covariance and Generics, I was wondering how you could illustrate that.

    As for the clone covariance example, I am still not convinced this is the right approach: it's exactly what the current Generic proposal is doing: add syntactic sugar and overlook the bytecode and performance problem of casts.

    Having typesafe casts is interesting but not incurring the cast overhead at the bytecode level is primordial, IMO.
  43. Ced,

    I completely misunderstood... sorry.

    I in no way meant to completely tie up generics with covariance. Rather to say that in Sun's implementation of generics (which is Generic Java), we also get covariant return types.

    Although, I agree that this is limited covariance (the people at bell labs agree on this). But to introduce TRUE covariance into Java would probably require a rewrite of the VM. Same can be said for TRUE generics.

    To me, covariant return types will save a lot of code and ugly casting.

    I don't see these things as a waste... or syntactic sugar.

    I understand that we get no performance gains, or optimizations. But the point is... until Sun releases Java into the open-source community... we're not going to see a rewrite.

    So until C# is available on other platforms... I'll take whatever I can get with Java.

    Regards,

    Rick