Discussions

News: Sun releases Java Generics Tutorial

  1. Sun releases Java Generics Tutorial (51 messages)

    Sun has released a 22 page tutorial on "Generics in the Java Programming Language". The tutorial goes into detail on: defining generics, subtyping, wildcards, Generic methods, interoperating with legacy code, and advanced fine print info.

    Generics in the Java Programming Language

    Threaded Messages (51)

  2. Do we really need all that ?[ Go to top ]

    All those Generics features are not very simple and intuitive at all.

    I am not sure that benefits of Generics will outweight all complexity issues and drawbacks related with working with "legacy code" (which uses raw collections).

    While Generics will remove need of one extra cast, thus improving readibility, just imagine how complex and unreadable code now can be written by folks that are crazy about OOP.

    Also I think that JCP is going into wrong direction with Generics. I would like to see more AOP related features in language rather that improving OOP related things. We all know that OOP cant deal with crosscuting aspects therefore it's very limited.

    Are they going to deprecate all raw collections, i.e. simple List ?
    I am happy about good old collections and has never felt I need something like generics.

    I would like to ask - do you really feel you need Generics ? Are you going to use it ?
  3. Do we really need all that ?[ Go to top ]

    The CREATION of a generic type usually more verbose than the non-generic one, since you need to provide the type:

    List<String> l = new ArrayList<String>()

    versus

    List l = new ArrayList();


    It is however simpler to USE a generic type:

    String s = l.get(o);

    versus

    String s = (String) l.get(o);


    So, depending on your type creation / usage ratio, you may need to type either more or less than before. But the main advantage is that you can catch type-related errors at compile-type, instead of at run time. Plus, unless you want to write generic classes, I don't think the program complexity grows.
  4. Generic arrays are already in Java[ Go to top ]

    Generics collections communicate type in a clear way.
    Saving the cast is because you communicated to the compiler.
    Communicating to humans is more important than communicating to the compiler so saving the cast is a secondary benefit.

    How many people declare all of their arrays as:

      Object[] array = new Object[10];

    I sometime specifically use arrays because they allow me to describe type.
    With generics this is no longer necessary.

    The way to make Java simpler is to remove the array special case,
    not to remove generics.

    Brendan
  5. The way to make Java simpler is to remove the array special case,

    > not to remove generics.

    Do you have some idea how to implement streams,buffers without arrays ?
    Do you think it is pragmatic to copy file as collection of bytes using some kind of iterators ?

    >
    > Brendan
  6. Do we really need all that ?[ Go to top ]

    I would like to ask - do you really feel you need Generics ? Are you going to use it ?

    I think it is very cool feature, but more cool than usefull :)
  7. Do we really need all that ?[ Go to top ]

    This is a very interesting question. The java implementation of generics does not offer any improvement with respect to application performance. It is simply syntatic sugar. This is largley due to the route that sun took in implementing generics in java. On the other hand, c++,C# generics is quite different. It is justifiable to me because using generics in c++ and C# will really improve performance. Hence, the additional complexity is worth it.

    -M
  8. I think it should be pointed out that C++ "generics" aren't generic...
    Templates in C++ can lead to bad code bloat, and aren't in general
    sharable at runtime (they are code generated differently). While this
    does lead to highly specialized versions of the code for a template class,
    it can lead to many copies, and in a large complex system the performance
    can drop due to instruction cache overflow.

    Basically if you're in to that level of optimization, because your
    inner loops are using such classes, you have a point, but for most
    code most of the time, parameterized types are intuitive and just the
    job. Moore's law tends to undermine the economics of complex
    optimization, as witnessed by the failure of P-code in the 80's but
    the rapid success of Java in the 90's... Programmer time is the most
    expensive resource, which favours powerful elegant re-usable features,
    and dynamic, portable, late-bound languages (look at the painless
    process of using a library jar file, compared to the hairier process
    of utilizing a C++ template library)

    Java's straightforward dynamic linking strategy would have to be thrown
    away to accomodate templates, and I think Occam's razor clearly indicates
    this would be the wrong thing for Java, which after all is mainly over
    to the dynamic side of the static/dynamic language spectrum.
  9. RE: Do we really need all that ?[ Go to top ]

    I swear it'd be nice if posters had an competence rating next to their names so you could filter some out.

    > All those Generics features are not very simple and intuitive at all.
    I agree somewhat, but mostly for API designers. It is pretty simple to use a Generic collection but more complex to properly write one.

    > I am not sure that benefits of Generics will outweight all complexity issues and drawbacks related with working with "legacy code" (which uses raw collections).
    I guess we'll see. If it takes a little more coding to help the compiler verify that my code is type safe I'm game.

    > While Generics will remove need of one extra cast, thus improving readibility, just imagine how complex and unreadable code now can be written by folks that are crazy about OOP.

    Ok, you are starting to show ignorance here. The point of Generics isn't to simply remove the extra casting it is to make sure your code is type safe. Very important, eh? BTW: Are Generics really a OOP only concept?

    > Also I think that JCP is going into wrong direction with Generics. I would like to see more AOP related features in language rather that improving OOP related things. We all know that OOP cant deal with crosscuting aspects therefore it's very limited.

    Should have quit while you were ahead. :-) This is where you show your comments are foolish and should be completely be ignored. You think AOP replaces OOP? Going to write an AOP-only project soon? What are you going to apply all those aspects against?

    >
    > Are they going to deprecate all raw collections, i.e. simple List ?
    > I am happy about good old collections and has never felt I need something like generics.
    >
    > I would like to ask - do you really feel you need Generics ? Are you going to use it ?

    If you'd read the article you'd understand what is going to happen to all the "good ole collections". yee ha.

    Of course, I'll use Generics. So will you, when you understand their purpose.
  10. RE: Do we really need all that ?[ Go to top ]

    Well, I beg to differ. The Java community process used to be relatively good at addressing the needs and wants of Java developers. This is why Java was able to move much faster than C++ and became a more pragamatic, day-to-day work oriented language than the largely academic C++.

    Now, I've seen a huge number of Java projects that would benefit from AOP like interception in Java. I never really heard many Java developers (even ex-C++ guys like myself) clamour for putting generics in Java. Has Sun lost touch with the community? Generics is fine (although breaks legacy code) but AOP stuff would probably be much more populare amongst your typical Java developer, particularly if he is a Java tools/containers developer.
  11. RE: Do we really need all that ?[ Go to top ]

    AOP is available now in many forms. Though itt would
    be nice to have a standard. Generics
    really can only be had by folding it into
    the language and changing libraries to take
    advantage of the new features.
  12. I swear it'd be nice if posters had an competence rating next to their names so you could filter some out.


    Mine would be low in grammar (at least today). My excuse is that I swapped intelligence for competence at the last second to be more politic in my reply.
  13. competence rating[ Go to top ]

    You have misunderstood me. I dont think that AOP is replacement for OOP or Generics. And, yes, I know that main benefit from Generics is type safety check at compile time.

    I just have never felt that I need those things. I have never had problems because I dont have static type check.

    If your opinion is different, than it's OK for me. It doesnt mean you should write insulting posts and claim that I hate SUN. In fact, I dont.
  14. competence rating[ Go to top ]

    Maris, my late uncle never saw the need for
    a seat belt either :-)

    Type safety is more useful in complex environements
    where there are a lot of programmers, lots of change,
    lots of ways for things go wrong. In your personal development
    there probably is never a compelling issue. When someone
    is feeling pressured to fix a bug and make a change
    at 1AM is where the benifits usually kick in.

    When using perl to write even complex scripts i don't
    care about typing nor do i unit test. It works fine 99% of
    that time. In my other areas of work that 1% is not ok.
    And my 1% will be someone elses 20% and that is definitely
    not ok.
  15. RE: competence rating[ Go to top ]

    I don't know you so I can only judge your competency by what you write. I'll apoligize for being somewhat snarky but I stand by my remarks.

    If you feel you are being misunderstood then spend more time on your posts to make sure you are being clear and are sticking to the point.

    > You have misunderstood me. I dont think that AOP is replacement for OOP or Generics. And, yes, I know that main benefit from Generics is type safety check at compile time.
    Didn't get that from your post.

    > I just have never felt that I need those things. I have never had problems because I dont have static type check.
    I don't understand this remark.

    > If your opinion is different, than it's OK for me. It doesnt mean you should write insulting posts and claim that I hate SUN. In fact, I dont.

    I never claimed that you hate Sun. My claim was that you didn't seem to know what you were talking about.
  16. Yes, you do[ Go to top ]

    If it was not required, then no body will add it in C++ and use it. It has proved successful in the past, and it will be in future too.

    It provides strong type checking.

    Eg. Vector<String> data = new Vector<String>();

    Now, i am very sure that only string is added in the variable data. Compiler will check this error and i dont have to wait till run time.

    Also, may be less code in some cases. Performance increase, may be yes, in future due to not requiring casting, etc.

    Also, read the tutorial. How much you may hate SUN, the still provide free tutorial and a JVM :)
  17. Yes, you do[ Go to top ]

    If it was not required, then no body will add it in C++ and use it. It has proved successful in the past, and it will be in future too.

    >

     Have you ever saw ATL code ?

    > It provides strong type checking.
    >
    > Eg. Vector<String> data = new Vector<String>();
    >
    > Now, i am very sure that only string is added in the variable data. Compiler will check this error and i dont have to wait till run time.
    >
     Do you have any problems with type checking at this time ? I can not remember any "ClassCastExeption" problems in code dependant on java collections.

    > Also, may be less code in some cases. Performance increase, may be yes, in future due to not requiring casting, etc.
    >
     
    I hope it so too.

    > Also, read the tutorial. How much you may hate SUN, the still provide free tutorial and a JVM :)

    I think SUN must be happy, some people hate SUN, but the same people ignore MS :)
  18. Yes, you do[ Go to top ]


    > Have you ever saw ATL code ?

    I was a C++ programmer before moving to Java. That is why i like it :)

    Also, Generic will prove its worth with time when more people get used to it.
  19. Do we really need all that ?[ Go to top ]

    I would like to ask - do you really feel you need Generics ? Are you going to use it ?


    Sure. I think it'll take some getting used to, but it will cut development time further by escalating some error checking from run-time to compile-time.
  20. Yes, we need all that.[ Go to top ]

    The claim that what generic do is "improve readability by removing one
    extra cast" completely misses the point.

    Strong typing is a good thing. It makes programs safer.
    It means the compiler catches errors instead of letting
    them fester until runtime. Generics means that strong typing exists for collections.

    Consider an API as a contract: if my interface I can say is that
    I'm returning a Set then the contract is weak. People implementing the interface and people using the interface's methods have to communicate
    via javadoc to get their typing right. If I can say that I'm returning a Set of Serializables then the contract is much stronger.

    I am not keen an what someone here said about wanting "AOP-related features"
    instead. Either damn well do AOP or don't do AOP, but don't piss about in the
    middle. Consider the language you know that aren't OOP but have some "OOP-related features" - disasterous hacks, aren't they? If you want to do AOP,
    then use AspectJ, no problemo.

    And I'm surprised to see claims that generics are not something that
    developers have wanted: lack of generics is one of the most common
    criticism that developers I know have of Java.


    Sean
  21. Do we really need all that ?[ Go to top ]

    I agree with the poster who said that Generics will benefit those who create APIs. I'd further venture to say that it will benefit those of us who use APIs. How many times have we all looked at the Javadoc for something that returns a Collection of Objects? If you know the API well, or the API developer has been very diligent and mentioned the type inside the Collection in his Javadoc, you can be sure to know what you're getting.
      However, when you're getting to know a new API, it can be frustrating to guess or hunt down what types are contained within a Collection. This is especially true for projects on which you're using each others' code, and not using a third party API. I know we use lots of Collections, and it can be difficult to quickly trace which type the Collection contains. With the explicit syntax of the Generic Collections, this becomes very easy.
      So, I'd say I welcome Generics.

      -T Sanidas
  22. For the developer[ Go to top ]

    A better choice to develper. You can use ,or use not. If there is no bad effect of performance or causing faults, what do you care? Using it for a convenience, using it not for your own manner.
  23. For the developer[ Go to top ]

    If there is no bad effect of performance or causing faults, what do you care?

    You mean, you do not care if they add any garbage to language as soon as it has no bad effect on perfomance or causing faults ?

    Too much fuss about such a small subject as generics.
    Generics proponents say that it makes programs type safe, meaning it fixes something. But they do not notice that no one in this forum ever had any problems with type errors on collections. I mean i do not mind if sun fixes problems in java. But this problem is purely theoretical and do not exist in real life.
    As far as simpler synthax. Not a big deal really.
    And implementation of generics in java just leaves much to be desired. We do not even enjoy performance benefit for using generics as say c# developers do.

    I do not think introduction of generics in java is such a big and important subject. Let's get over it. There's much more important features that we can ask for including in java. AOP for example.
  24. For the developer[ Go to top ]

    I do not think introduction of generics in java is such a big and important subject. Let's get over it. There's much more important features that we can ask for including in java. AOP for example.


    I agree with you, generistics are cool, but adds no value.
    Nobody has problem with "unsafe types" and it adds no readability,
    see examples in this tutorial, I am sure it will be even worse in the real code (It is cool to write, but try to read something STL or ATL code).
    I want to see more usefull features than cool like lambda functions (aka evil procedure pointers)

    BTW There is "typedef" in C++, it can help to make generistic code more readable: "<<String,<<Integer>List>>Map> list = new .... "
  25. definitely, we need it[ Go to top ]

    Guys, have you ever written code that had to create complex structures and graphs of data that had to be transferred in one go? When you have collections of maps, which, in turn, consist of keys and values as maps (again). And so on. Going for XML is a huge impact on performance here. So many man/hours have been spent on just finding and fixing all those runtime classcastexceptions.

    So, the answer is YES, WE URGE FOR IT. But, of course, nobody will hurt you if you just ignore it and write the code w/o generics. Just do not claim _we_ don't need it, say _only I_. (And I'm talking for my team, so consider it a group voice).
  26. definitely, we need it > YES[ Go to top ]

    I don't know why so many people votes are against Java generics. My opinions are: make everything as typesafe as possible, let the compiler check my code, let the development environment check my code. These all helps to produce more correct and safe programs. Even more - in the past I wrote caches, background tasks and many other things where I was really missing the generics because they would help me to solve my problems without code copy/paste programming (there where to less usages [approx. 5 - 10] that a code generator wouldn't be a suitable solution). Sure there may be some learning necessary to use Java generics in the rigth way. The more critical problem with generics is that tool and library vendors use the features perhaps in 6 months, even later or never. Some want to support even JDK 1.1 where I cannot profit from the extensions delivered with "Tiger".

    Concerning AOP: I vote for a standardized implementation too. But AOP is another topic and has not the aim to replace generics - IMHO.
  27. definitely, we need it[ Go to top ]

    Guys, have you ever written code that had to create complex structures and graphs of data that had to be transferred in one go? When you have collections of maps, which, in turn, consist of keys and values as maps (again). And so on.


    Yes I have. It use special API for complex structures and this kind of structures are "hidden" in implementation and looks like "objects" in public API. I am not very big OOP fan, but it is a good use case for OOP. I agree it can look very cool with generistics, but I see nothing practical in generistics if you know how to use OOP.
  28. For the developer[ Go to top ]

    It fixes something.

    It does not fix something, does improve something.
    Like ++ operation in language, this self added operation can be substitute by the evaluator operation directly, why has a ++ operation? Conveniency,more way to target. We can use generic in our program or not. AOP is a good, but it's not a part of J2SE now. :)
  29. For the developer[ Go to top ]

    Generics proponents say that it makes programs type safe, meaning it fixes >something. But they do not notice that no one in this forum ever had any >problems with type errors on collections. I mean i do not mind if sun fixes >problems in java. But this problem is purely theoretical and do not exist in >real life.


    Yes, I agree. Java/J2EE developers has a lot of real life problems. Just watch TSS panel discussion about that. But JCP are adding "syntactic sugar" to language.

    > I do not think introduction of generics in java is such a big and
    >important subject.

    We depend on so many libraries where raw collections are used. If I use Generics I will get millions of warnings.

    Maris
  30. Oh no, not again, not AOP[ Go to top ]

    I think AOP is nothing more than a buzzword. Oh, no, it's worse. It's a true evil which can bring the software development into chaos much more quickly than OOP did. It's like RDBMS triggers. Cool feature, eh, but would you remember when you've used it last time? And wow, how much time it took to debug the code?

    AOP is a two-dimensional chaos. You'll never know when and how the current aspect will work.
  31. Oh no, not again, not AOP[ Go to top ]

    I think AOP is nothing more than a buzzword. Oh, no, it's worse. It's a true evil which can bring the software development into chaos much more quickly than OOP did. It's like RDBMS triggers. Cool feature, eh, but would you remember when you've used it last time? And wow, how much time it took to debug the code?

    >

    Yes, AOP is very easy to missuse too. May be it is not so bad as you think
    (triggers are not so bad too, I use triggers for very complex data validation in RDBMS ). I use AOP ideas without problems and new programming languages too.
    I think AOP is more cool than usefull at language level too, there are
    a lot of good frameworks and tools to implement this idealogy and I do not think
    it is possible to find the best one and to use it as JAVA language feature.
    May be some core interception API can be more usefull for AOP implementations.

    > AOP is a two-dimensional chaos. You'll never know when and how the current aspect will work.
  32. Also I think that JCP is going into wrong direction with Generics. I would like to see more AOP related features in language rather that improving OOP related things.


    Generics are not about OOP they are about static type checking.

    > We all know that OOP cant deal with crosscuting aspects therefore it's very limited.

    OOP can't deal with anything, software designers deal with things. And they do it either by ways of language features or through design patterns. There are lots of patterns that deal with crosscutting concerns and there will always be a debate about which design patterns should be promoted to language features and which ones are too special purpose to merit direct language support. I haven't made my mind up with regard to aspects.

    > I would like to ask - do you really feel you need Generics ? Are you going to use it ?

    The question should be (and is often) asked more generally: Do you really feel you need static typing? My answer is: I need it at the boundaries of components where I want communicate in a formal manner what the requirements of the component are. I don't need it within the boundaries of a component where a single person is able to understand all the code. So, for me, static typing is an encapsulation thing and should therefore be optional.

  33. > Generics are not about OOP they are about static type checking.
    >
    Yes, Generics are more about anti OOP, it is workaround for
    static type data containers vs object model (it can be not so bad too for simple model too).
  34. generics[ Go to top ]

    ----------
    > Now, i am very sure that only string is added in the variable data. Compiler will check this error and i dont have to wait till run time.
    >
     Do you have any problems with type checking at this time ? I can not remember any "ClassCastExeption" problems in code dependant on java collections.
    ----------

    Generics make the code more self documenting - you can tell the type of a containers elements directly from its declaration. Persoanlly the risk of occasional class cast errors doesnt bother me, but having to read implementation code to figure out what coantainers contain does.

    Paul C.
  35. generics[ Go to top ]

    ----------

    > > Now, i am very sure that only string is added in the variable data. Compiler will check this error and i dont have to wait till run time.
    > >
    >  Do you have any problems with type checking at this time ? I can not remember any "ClassCastExeption" problems in code dependant on java collections.
    > ----------
    >
    > Generics make the code more self documenting - you can tell the type of a containers elements directly from its declaration. Persoanlly the risk of occasional class cast errors doesnt bother me, but having to read implementation code to figure out what coantainers contain does.
    >
    I do not think generistcs ar very usefull for self documenting :

    Collection<Menu> getItems();
    MenuItems getItems();
    Collection getMenuItems();
    Menu[] getItems();

    Try to write something more complex like list of maps and some operations with generistics and without ( model vs data containers ).
    I think you will start to hate this kind of self documenting in generistics,
    I do not want to write this example, you will start to hate me :)



    > Paul C.
  36. uglier than it has to be[ Go to top ]

    1. the discrepancy between compile time types and run time types will drive people nuts. java is f-ed when the source code doesn't look like the execution. I don't care whatever reasoning they had, this is a big mistake.

    2. I really miss the previous version with variance concept/syntax. sigh...

    overall I'll like to use it myself, and I'll hate to see bloody abuses by others:)
  37. Sun releases Java Generics Tutorial[ Go to top ]

    Why didn't they do it the C++ way? That is, the expansion of the type to have a copy per use?

    It gives more freedom and is more intuitive in my opinion. Is it just not feasible to do it in Java?

    <? super X> aargh!!!!!
  38. Give it another thought[ Go to top ]

    Here's one answer: Java doesn't have header files. Try to build a C++ DLL (without any header files) where you use templates and then try to use inline exapansion with that DLL. The DLL is just like a class file (i.e. a compiled binary), and inlining is too late when the stuff is compiled. This kind of thing would have changed Java quite a bit and at least I'm happy it didn't happen.

    And finally, with 15 years of C++ experience I have to say I'm really excited to see Java generics and auto-boxing in real use. I'll use them whenever it's possible, but in the world of diverse set of application servers we have to support this will probably take quite long time!

    Cheers,

    Paci
  39. Increased Maintainability[ Go to top ]

    I think a lot of people might be missing the point. Generics aren't just about strong type checking. The last time I had an error due to a miscast was about ... never. And if I ever did I'm sure it'd take about 30 seconds to fix. The real value of generics (and I think what swayed the jcp group) is that they make code easier to read and maintain. When you come back to a piece of code you wrote six months ago you no longer have to guess exactly what 'accessMap' is mapping or read the code to find out. Now it'll be clear, ie Map<String,User> so it's probably mapping logins to User objects. Contracts also become a lot more expressive. If you've ever dealt with old code that takes a List as a parameter but the javadoc don't say a list of what then you know what I mean. So yeah, generics are a good thing. They don't do too much that good javadoc didn't do before but since devs are often too lazy to write good javadoc, generics are a keen way to force em.
  40. Yet to be convinced[ Go to top ]

    My gripe with generics is their tendency to increase coding complexity rather than reduce it. I have many disturbing memories of generics in C++. Some of it was so complex that I had to give up understanding it and in the end just hoped it worked. As an example, look at the sources for the STL and the many interdependencies between the templates. I frequently delve in to the sources of the standard Java APIs; but STL? I always stayed clear.
  41. Yet to be convinced[ Go to top ]

    MJ wrote:

    > I have many disturbing memories of generics in C++.

    I must say I'm a bit surprised by the number of times C++ templates are referred to in an attempt to demonstrate that Java generics aren't a Good Thing[tm]. The two are totally different beasts. C++ templates are a Turing-complete language interpreted by the compiler; Java generics are definitely not.

    Virtually anything that makes the Java language more expressive of the programmer's intent pushes my buttons. Generics are a Good Thing[tm].

    Regarding AOP, it's already there and quite usable (Aspectwerkz, Nanning, Spring...). I don't think we're ready yet for AspectJ-style AOP that is part of the language itself.

     - Peter
  42. Yet to be convinced[ Go to top ]

    Giving the developers a choice is a good thing :)
  43. Yet to be convinced[ Go to top ]

    MJ wrote:

    >
    > > I have many disturbing memories of generics in C++.
    >
    > I must say I'm a bit surprised by the number of times C++ templates are referred to in an attempt to demonstrate that Java generics aren't a Good Thing[tm]. The two are totally different beasts. C++ templates are a Turing-complete language interpreted by the compiler; Java generics are definitely not.
    >

    Yes, java generistics are even more limited than C++ templates.

    > Virtually anything that makes the Java language more expressive of the programmer's intent pushes my buttons. Generics are a Good Thing[tm].
    >
    Yes, it is a Good Thing[tm] as ansver to .NET generistics or cool as something new in JAVA, but I see nothing practical in generistics (C++ templates are not very practical too, this kind of code generation in C++ sometimes helps to avoid OPP, but I think it is nothing bad to use OOP if you need it ).

    > Regarding AOP, it's already there and quite usable (Aspectwerkz, Nanning, Spring...). I don't think we're ready yet for AspectJ-style AOP that is part of the language itself.
    >
    >  - Peter
  44. all for it![ Go to top ]

    I had a project recently with several similarly named EJBs (Sample, SampleList, SampleInList, etc) and had ongoing headaches with type-casting typos causing runtime errors. The new generics feature, if incorporated into EJB iterators, would have been a blessing. Of course if i'd been a more attentive programmer i wouldnt have made the mistakes in the first place, but whats a compiler for if its not help slack programmers?
  45. Object Serializable someObject;[ Go to top ]

    I'm still missing an important feature:

      Object Serializable someObject;

    or

      void someMethod(Customizer JComponent Comparable customizerComponent);

    Without that, I'm forced to choose one of the interfaces and then typecast, if I want to address other interfaces.

    Holger Engels
  46. Sun releases Java Generics Tutorial[ Go to top ]

    Actually one place I feel generics will be used for a lot is in interviews. This will be where someone wants to show off how well they know the syntax of the language. :-)

    It is kind of a shame that most people including my self had exposure to the pain that was C++ templates. I suppose not matter how good generics turned out to be they would always be compared to their less than perfect brother in the religous wars that developers often have.

    The ability to compile time checking will be a big bonus especially for J2EE developers where compile and deployment times are high. Waiting 5 mins to find that you have accidently miss cast something in your code will be a big bonus. However I doubt there will be a 1.5 compliant app server for quite a while.

    For me I still have my doubts about adding something so complex into the language. One of the reasons I always think Java took off is becuase it was simple. People have from the early days have complained certain stuff was missing. However at the end of the day this allowed you to navigate around some of the programming pitfalls less all inclusive elegant languages had.

    Anyway in the end generics are here to stay now so I suppose we better get used to them.
    David
  47. Sun releases Java Generics Tutorial[ Go to top ]

    "The ability to compile time checking will be a big bonus especially for J2EE developers where compile and deployment times are high. Waiting 5 mins to find that you have accidently miss cast something in your code will be a big bonus. However I doubt there will be a 1.5 compliant app server for quite a while. "

    Sorry I mean not having to wait 5 mins....
  48. New generics[ Go to top ]

    Ok, I've read the tutorial. First time I've actually looked at this topic in any detail, and to be fair I "skimmed in detail" the tutorial and may have missed something subtle.

    With that said...

    I'm hating these things already.

    Specifically, I'm hating this detail:

    public class X { ... }
    public class Y extends X { ... }

    ArrayList<X> myXList = new ArrayList<X>();
    X x = new X();
    Y y = new Y();
    myXList.add(x);
    myXList.add(y);

    According to what I read, that last line will fail, because Y is not X.

    umm...Every OO text I'VE read had pretty much always said that, in this case, Y "isa" X.

    But not with the new generics framework.

    This seems SO wrong to me.

    I have extended many a OSS project by extending a few select classes and pluging in little bits of code to do what I want, but should these generics become popular, that's shut down completely. Now I either have to affect "stock" classes directly or, even worse, reengineer how those classes migrate through the system.

    If all you do it program to interfaces, then this isn't a problem, but inheritance is a perfectly valid technique to specialize classes.

    Retrofitting legacy code looks like its going to be an all-or-nothing affair. These things seem pretty darn viral and will bubble out of interfaces until they hit the entire system. Updating our 100,000 lines won't be any fun and I doubt we'll bother, since once we start a section we have to finish it and can't really go "part way". "Don't mind me while I check out the entire tree to type all of our collections, folks!"

    Finally, it's not clear to me how these are actually implemented.

    In Java:

    String s = (String)hashMap.get(key);

    The Cast has a cost at runtime, since it must ensure that we are actually getting a String.

    But, with generics:

    String s = stringMap.get(key);

    Does it still perform the cast internally? It has too, since at some point we could have "lied" to the system and cast an arbitrary Map into a Map<Key, String>. And this save us...what?

    Nope. Uhuh..I'm underwhelmed and I dred this being proliferated into the community.
  49. Re: New generics[ Go to top ]

    Specifically, I'm hating this detail:

    >
    > public class X { ... }
    > public class Y extends X { ... }
    >
    > ArrayList<X> myXList = new ArrayList<X>();
    > X x = new X();
    > Y y = new Y();
    > myXList.add(x);
    > myXList.add(y);
    >
    > According to what I read, that last line will fail, because Y is not X.

    You read incorrectly. This will work, of course.

    You are probably confusing it with being able to do

    List<Integer> lsti = new ArrayList<Integer>();
    List<Number> lstn = lsti;

    This will not work, because it could allow you to do

    lstn.add(new Double(3.14));

    which will screw up your program. The generics variance mechanism gives you the proper workaround for this, which is really great.

    > Retrofitting legacy code looks like its going to be an all-or-nothing affair. These things seem pretty darn viral and will bubble out of interfaces until they hit the entire system. Updating our 100,000 lines won't be any fun and I doubt we'll bother, since once we start a section we have to finish it and can't really go "part way". "Don't mind me while I check out the entire tree to type all of our collections, folks!"

    And why is that? From what I have seen a hell of a lot of compromises have been made to allow precise this.
     
    > String s = stringMap.get(key);
    >
    > Does it still perform the cast internally?

    Yes. Generics as it is implemented is just syntactic sugar, nothing else. Read the other messages.
  50. Generics and JDO[ Go to top ]

    I will definitely use generics and am most appreciative of the JSR group that defined them. Most of the good points have been stated already. I'd like to point out one more:

    In JDO it is necessary for the persistence descriptor to identify the "element-type" of each collection. Mapping to a database when the root type is "Employee" allows an efficient join to the EMPLOYEE table; if the root type is "Object" then such efficiency is not possible.

    e.g. <field name="employees"><collection element-type="com.staff.Employee"/></field>

    It is feasible that the burden of identifying such element types will be reduced by JDO Implementations whose enhancers correctly recognize these types. Should I ask the JDO Expert Group to specify in JDO 2.0 that the notation of element types be explicitly optional in a JDK 1.5 environment, so as to assure portability for such a short-cut?

    Kind regards, Robin.
  51. public class MyObjectList {
      ArrayList internal;
      public int size(){
        return internal.size();
      }
      public MyObject get(int i){
        return (MyObject)internal.get(i);
      }
      public void add(MyObject o){
        internal.add(o);
      }
    }

    I do this all the time. It's not that much code and
    that's about all I need in the facade (I think
    Iterators are slightly overrated).

    It may not be perfect but it does great in a pinch.

    I'll probably start using generics eventually anyhow tho.
  52. Generics is about code reusability[ Go to top ]

    I always feel that there are too many list interfaces just because their item types differ. For example, this is a W3C DOM API.

       interface NodeList {
          public Node item(int k);
          public int getLength();
       }

    It is unfortunate that their implementations do not also implement java.util.List<Node>. For example, we cannot reuse our code, e.g., to filter a NodeList to obtain a new NodeList whose items satisfying a given condition.

        class FilteredList<T> implements List<T> {
           public FilteredList(List<T> list, Predicate<T> condition) { ... }
           public T item(int k) { ... }
           public int getLength() { ... }
        }

    In my opinion, Generics will increase the conformance of existing code with standard Collection and Iterator libraries. I believe that this in turn allows us a completely new programming style.