behaviour of the generics

[Rachit Kumar Saxena]

as we see from the java api,the peculiar behaviour of generics.Can you give us an idea why generics behave in such a fashion and source code of the stuff behind codes like:

public <t extends a> void abc(a1<t> g)

[Jeff Verdegan]

It's not at all clear what you're asking. If you want to know how to use generics, google for java generics tutorial.

[Rachit Kumar Saxena]

Sorry to have not got you right.But I am not asking what the code does.I am asking what do you feel about how the Sun developers developed the peculiar generics mechanism?

[Winston Gutkowski]

Rachit Kumar Saxena wrote:Sorry to have not got you right.But I am not asking what the code does.I am asking what do you feel about how the Sun developers developed the peculiar generics mechanism?

Personally, I think it's fine. I guess my only criticism would be that the compiler messages (some of which are pretty arcane) could do with an overhaul.

My question to you: Why do you think it's "peculiar", and what would you prefer to see?

Winston

[Rob Spoor]

The only problem I have with the way they implemented generics is type erasure - the removal of generic information in byte code. This disallows us to create instances or arrays of generic types (no new T() or new T[10]), or runtime type checking (no instanceof List<String>). Other than that it works quite good.

[Winston Gutkowski]

Rob Spoor wrote:The only problem I have with the way they implemented generics is type erasure - the removal of generic information in byte code. This disallows us to create instances or arrays of generic types (no new T() or new T[10]), or runtime type checking (no instanceof List<String>). Other than that it works quite good.

I'm not sure they had much choice, what with backwards-compatibility and all, but I agree: Array.newInstance() is a pretty poor substitute (and incredibly slow).
Not so sure about runtime type-checking though: Wasn't the whole point of generics to eliminate (or at least reduce) the need for it?

Winston

[Rob Spoor]

Winston Gutkowski wrote:I'm not sure they had much choice, what with backwards-compatibility and all

They perhaps could have added a special marker after the regular class information inside byte code, to indicate that a generic type would follow. If this marker is missing (which it would be in existing byte code) then no generic type is available.
This would allow existing code to run, albeit without the type safety. Existing code wouldn't be able to use new T() anyway so no worries about that. As for new code running on older JVMs, that's not possible at the moment anyway.

This does pose one potential problem. Right now there is one Class object for a class like ArrayList (Class<ArrayList>). Without type erasure, there would be one for each actual generic type; you could have a Class<ArrayList<Integer>>, Class<ArrayList<String>>, etc. The number of Class objects would increase drastically.

Array.newInstance() is a pretty poor substitute (and incredibly slow).

That method was already available before Java 5.0, and it still requires a Class<T> to be available to create a T[].

Not so sure about runtime type-checking though: Wasn't the whole point of generics to eliminate (or at least reduce) the need for it?

Imagine a very valid example using servlets. One servlet stores a List<String> as a session attribute. Since session attributes can be anything, getAttribute returns Object. Right now, the only way to retrieve the session attribute as a List<String> is to cast and ignore a warning. Wouldn't it be great to get a ClassCastException if you would cast it to List<Integer>?

[Rachit Kumar Saxena]

I would rather have the same old java code do the job.You are just restricting the runtime problems by catching most of the problems at compilhat waye time.Maybe the compiler and JVM could have been designed in that way.

[Matthew Brown]

Winston Gutkowski wrote:I'm not sure they had much choice, what with backwards-compatibility and all

But that was a choice. For example, C# took the other approach - the generic and non-generic versions of classes are completely separate classes.

[Bill Johnston]

I don't like Java Generics. I think the language was much more intuitive without them and Java was initially intended to be a simpler OOPs language to learn and use than C++. I think that Generics breaks with that intention. But they aren't going away so we either get used to them or use another language or don't use Generics in our coding and hope the compiler won't mandate them in the future.

[Martin Vashko]

Rachit Kumar Saxena wrote:... You are just restricting the runtime problems by catching most of the problems at compilhat waye time. ...

Exactly, and in my opinion, that is about bazillion times better than the other way around. With compiler check, I can deal with the problem sitting in my comfortable chair with a cup of coffee (ok, maybe half a dozen cups) without much stress. In ideal conditions, anyway. However, with runtime check, chances are I'll get a call at 2:30 am and will be trying to sort out the issue half sleeping with equally predisposed help desk technician who barely knows my application since he's a backup. The days when I was most productive (or productive at all) after midnight are gone for good

[Martin Vashko]

Bill Johnston wrote:I don't like Java Generics. I think the language was much more intuitive without them and Java was initially intended to be a simpler OOPs language to learn and use than C++. I think that Generics breaks with that intention. But they aren't going away so we either get used to them or use another language or don't use Generics in our coding and hope the compiler won't mandate them in the future.

There is a conflict between simplicity and usefulness, and generics certainly shift the balance towards the latter.

I started with Java only a few years ago and generics were already in the game. I'd dislike the language if they weren't, and frankly, it is hard to me to understand why there were not here right from the start. They might be even made a bit easier that way.

It took me some time to understand generics, however. Especially when I upgraded NetBeans somewhere around version 6.5 and all of sudden I got hundreds and hundreds of generics-related warnings. It took me several weeks to sort everything out, mostly thanks to long sessions over Angelica Langer's FAQ. But it was worth it. If you're really careful with the @SuppressWarnings("unchecked"), you can be pretty sure you'll scarcely get CastClassExceptions after a clean compile.

[Winston Gutkowski]

Martin Vajsar wrote:I started with Java only a few years ago and generics were already in the game. I'd dislike the language if they weren't, and frankly, it is hard to me to understand why there were not here right from the start.

I'm with you; and I've used Java since 1.2.

It does take a bit of getting used to, and you can probably nitpick at some of the decisions they made, but Gilad Bracha's tutorial is very good, and covers most of the things you'll run into (especially weird stuff like Comparable<? super T> ).

I usually think of it as a 90% solution - and, as you say, possibly higher if you're really careful - it won't solve all your problems, but it covers most of the major gotchas of runtime checking; and if I find myself really stuck with it, I often discover that there's a basic flaw in my thinking, which to me is the sign of a very useful feature.

My 2 cents.

Winston

[Bill Johnston]

Martin Vajsar wrote:

Bill Johnston wrote:I don't like Java Generics. I think the language was much more intuitive without them and Java was initially intended to be a simpler OOPs language to learn and use than C++. I think that Generics breaks with that intention. But they aren't going away so we either get used to them or use another language or don't use Generics in our coding and hope the compiler won't mandate them in the future.

There is a conflict between simplicity and usefulness, and generics certainly shift the balance towards the latter.

I started with Java only a few years ago and generics were already in the game. I'd dislike the language if they weren't, and frankly, it is hard to me to understand why there were not here right from the start. They might be even made a bit easier that way.

It took me some time to understand generics, however. Especially when I upgraded NetBeans somewhere around version 6.5 and all of sudden I got hundreds and hundreds of generics-related warnings. It took me several weeks to sort everything out, mostly thanks to long sessions over Angelica Langer's FAQ. But it was worth it. If you're really careful with the @SuppressWarnings("unchecked"), you can be pretty sure you'll scarcely get CastClassExceptions after a clean compile.

In general I agree that if they were put into the language from the start that would have been better, since likely there wouldn't be the runtime type erasure issue for one thing and probably would have been done more intuitively. Now I say "in general" because in my case, coming from a COBOL background and not a C/C++ background, and therefore having to learn both the totally new syntax and OOPs concepts at once, and learning that after work because I didn't need it for my job at that time, I think I likely would have given up if Generics were thrown into the mix - I had a hard enough time with up and down casting and inheritance as it was.

However, that said, I can certainly see your side of the issue. If you work with Java as your main language - or one of your main languages - professionally I certainly see your point. In my case, however, I still mostly use Java as a secondary language - I use it because I like it; it's my favorite language to work in. But I don't get a lot of my Java code into production because we're not a "Java" shop. Therefore, I really don't have the time to learn Generics inside and out (to pour over the tutorials, as it were). I have read quite a bit on them, and in their simplest form

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

... they are intuitive and fine. If it stopped not far after that I'd like them. But they allow a coder to shoot the next person working on the code in the foot, so to speak.

But that's why I said I personally don't like them. I didn't intimate that they should not be in the language, only that "I" wish they were not. And that's what the OP was asking.

[Winston Gutkowski]

Bill Johnston wrote:But that's why I said I personally don't like them. I didn't intimate that they should not be in the language, only that "I" wish they were not. And that's what the OP was asking.

I guess my question would be then: what language are you using? Not COBOL still - surely

I'm an old COBOL duffer myself, dragged screaming into the world of OOP via C→C++; and it still took a couple of years of writing Java for me to have my "Eureka" moment about OO. Now, I hate to say it, but I'm a bit like a born-again Christian - willing to swallow all sorts of crap put out by "expert evangelists" until I work out for myself that it is crap.

After 35 years, my 'code-nose' is pretty good though, and I don't think that Java generics is crap (apart, maybe, from some of the compiler warnings).

Winston

[Bill Johnston]

Winston Gutkowski wrote:

Bill Johnston wrote:But that's why I said I personally don't like them. I didn't intimate that they should not be in the language, only that "I" wish they were not. And that's what the OP was asking.

I guess my question would be then: what language are you using? Not COBOL still - surely

I'm an old COBOL duffer myself, dragged screaming into the world of OOP via C→C++; and it still took a couple of years of writing Java for me to have my "Eureka" moment about OO. Now, I hate to say it, but I'm a bit like a born-again Christian - willing to swallow all sorts of crap put out by "expert evangelists" until I work out for myself that it is crap.

After 35 years, my 'code-nose' is pretty good though, and I don't think that Java generics is crap (apart, maybe, from some of the compiler warnings).

Winston

I'll answer you upside down. I don't think Generics in general are bad. I do think Generics in Java are bad. But I don't think that they are so bad that I'd label them junk. A lot of thought and work went into them; and if kept on the simple side I have no problem with them. But often they are not kept on the simple side and I do then have a very big problem with them.

I won't touch the religious comment. I'm not a born-again Christian, but I am a religious Christian. I'll leave it there.

As to which languages I use ... Pro*C and proprietary SQR for DB background jobs and PL/SQL with Javascript mixed in for web programming. I have written some Java DB stored procedures for my job, but my personal uses for Java are desktop GUIs (mostly MS Windows) and Unix utility programming for the most part. I studied up on Servlets/JSP - really just scratched the surface though, because we likely won't be using them at work and I can't see myself using them personally just yet. We are being thrust into Groovy/Grails now because the main product we support is going from Oracle Forms (which I don't do) and PL/SQL over to G+G. I've also dabbled with learning some basics of Mobile computing with G+G. So I have to spend my time leaning Groovy and Grails, and don't have much time to fool around with the finer points of Java Generics.

[Martin Vashko]

Thanks for the follow up, Bill. Yes, it does make sense to me now.

I'd still think it can be easy to avoid generics (just use raw types and configure your ide to hide the raw type warnings from your sight) if you learn Java and want to postpone the tough stuff, especially if you do it as a hobby and don't come in touch with other people's code very often (well, this was how it worked for me when I still had some time to do hobby programming...). Depending on the tutorial and/or path you'd choose to learn the language, this possibility (leaving out the generics) might be less obvious and it conceivably might discourage a hobby programmer with no background in OOP from ever starting to learn/use it.

Bill Johnston wrote:... But they allow a coder to shoot the next person working on the code in the foot, so to speak.

Certainly, but this is not a domain specific to generics. For example, there are some 600 lines worth methods somewhere in our code base (just to clarify, not written by me ).

I may be still missing some pieces of the picture, but I think you should be able to avoid the complex stuff if you want to and don't do Java for living (ie., don't actually have to disentangle some imaginative use of generics by the next developer).

[Bill Johnston]

Martin Vajsar wrote:Thanks for the follow up, Bill. Yes, it does make sense to me now.

I'd still think it can be easy to avoid generics (just use raw types and configure your ide to hide the raw type warnings from your sight) if you learn Java and want to postpone the tough stuff, especially if you do it as a hobby and don't come in touch with other people's code very often (well, this was how it worked for me when I still had some time to do hobby programming...). Depending on the tutorial and/or path you'd choose to learn the language, this possibility (leaving out the generics) might be less obvious and it conceivably might discourage a hobby programmer with no background in OOP from ever starting to learn/use it.

Bill Johnston wrote:... But they allow a coder to shoot the next person working on the code in the foot, so to speak.

Certainly, but this is not a domain specific to generics. For example, there are some 600 lines worth methods somewhere in our code base (just to clarify, not written by me ).

I may be still missing some pieces of the picture, but I think you should be able to avoid the complex stuff if you want to and don't do Java for living (ie., don't actually have to disentangle some imaginative use of generics by the next developer).

Thoughtful answer Martin,

Here's what you're missing. I got into this discussion merely to weigh in on the OPs request for responses. I do use Generics in my code now because, as I said in my first posting on this topic, I can see three routes to take: 1. learn to use them; use another language; don't use them and hope they will never be mandated. I take the first path because I believe it to be the most sensible one for me to take. However, I answered the OP's question as truthfully as I could.

[Winston Gutkowski]

Martin Vajsar wrote:...don't actually have to disentangle some imaginative use of generics by the next developer...

Yeah, 'imaginative generics': that's definitely where I usually run into trouble.

Winston