|
Sponsored Links
Resources
Enterprise Java
Research Library
Get Java white papers, product information, case studies and webcasts
|
News
News
News
|
Messages: 226
Messages: 226
Messages: 226
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
Wicket and generics and the end of Java
Last in the thread of "The END 0f J4VA!!!11!one!1one!BBQ" topics for the day comes "Wicket and generics and the end of Java," an actual and serious post from Jonathan Locke: "if the problem can't be solved in such a way that ordinary programmers can write and not just use generics, I think Java has jumped the shark."Having a single situation where not everybody is happy with the implementation of something as basic as type safety is a major problem ... However, at this point I think there is a much bigger problem looming in the background: the viability of Java generics and possibly even Java itself. If this were the first time I had seen smart people spend enormous energy spinning their wheels with generics, that would be one thing. But this is now part of a larger pattern I’m seeing from project to project and company to company. At my last job, probably more time and brainpower was spent fussing with generics than any other single thing. You can spend enormous amounts of energy adding generics to something only to find your only option is to remove it all (or worse, gradually and iteratively find the maximum you can do before it all collapses). And the trap is so intricate that even seasoned developers can find themselves suddenly and unexpectedly stumped, bringing everything to a grinding halt.
I used to think we were wasting time with all these endless discussions of closures and that we should be working on some kind of mix-in or type arithmetic architecture. Now, I still think we’re wasting time on closures, but it’s completely clear to me that generics is the biggest problem in Java. In fact, if the problem can’t be solved in such a way that ordinary programmers can write and not just use generics, I think Java has (in the words of somebody who I never ever thought would say this about Java) “jumped the shark”.
|
|
|
Message #253264
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Wicket and generics and the end of Java
They should read "Java Generics and collections" book and learn how to use generics.
|
|
|
Message #253270
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Feh - time warp ?
According to the logs I haven't Read / Posted to TSS in the last 2 years. But it seems like I haven't missed anything - people are still talking out of their arses and proclaiming Java is dead for some reason. Java is just too big to fade away any time soon. If you are proclaiming that today - you are no less stupid than the people who said it 5 years ago.
Joe - does a "Java is dead because XXX" headline even raise an eyebrow these days.
And no I didn't RTFA. See you in 2 years.
Rich Sharples
JBoss, a division of Red Hat
|
|
|
Message #253272
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
I think we have a few things a work here...
1. Parametric polymorphism is inherently complex
2. Java generics are intentionally "broken" in order to maintain backwards compatibility.
3. Core Java libraries (e.g. collections) were not originally designed with collections in mind.
#1 is never going away. I invite you to take a look at generics in Scala which are based on much tighter theory than Java generics (#2 issue at work) and are substantially more complex...and they are continually evolving. They are more expressive so you are much less likely to run into the "it can't be done" situation, but that doesn't mean you won't run into the "I did this all wrong" situation after putting in a lot of work. Given that truly grokking Scala generics seems to require a good grasp of category theory many may never bridge the gap. Of course using generified classes is much more common than creating them, so most will never need to bridge the gap, either.
#3 hits the list example. The Java list interface allows you to both read and modify the list (or, well, any collection). You can't safely insert an Object into a list of Strings, but you could iterate over a list of Strings as if it were a list of Objects. If these aspects of the interface were separated then life would be a little easier.
|
|
|
Message #253274
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Feh - time warp ?
Rich: does a headline like that still raise eyebrows? I don't know - occasionally, yes. People keep saying it. You'd think that logic factors in.
That said, they say it for a reason. In this case, it's because generics are ... hard? He didn't give enough of an example to validate anything behind his statement. But that's okay: he said it, and it's worth considering because in a lot of ways, I can easily see where his point might be valid.
First part of solving a problem is seeing a problem.
|
|
|
Message #253275
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Tabloid people
I totally agree with Rich Sharples. Nothing to add here. Maybe the thing that this subject is a "tabloid" one for me. "Naked Java swimming drunk in the Generics swimming pool"! Cool, huh? I want to puke when I read "Java will die"-like posts.
Anyway - it will die some day in 40 years maybe. The same way the COBOL died (well in fact it hasn't died yet).
|
|
|
Message #253278
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Feh - time warp ?
First part of solving a problem is seeing a problem.
And the problem is?
|
|
|
Message #253279
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Feh - time warp ?
First part of solving a problem is seeing a problem.
And the problem is?
Generics + type erasure + the complexity of declarations, I'd imagine.
But think about it: he's saying "there's a problem" -- and that's it. But now PERHAPS people are saying "is there? Really?" and considering the validity of the claim.
Maybe it'll turn out there's no problem. That's fine. But if there IS... they're now considering it. That contributes to the global knowledgebase, so to speak, and that is a Good Thing.
|
|
|
Message #253280
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
It was never about backwards compatibility
2. Java generics are intentionally "broken" in order to maintain backwards compatibility.
It was never about backwards compatibility. They allowed a niche concern called migration compatibility to dominate in the design of generics. Nothing stopped a generic-aware JVM with reified generics from being backwards compatible.
Type erasure only became nessecary because the initial nince constraint was never challenged.
Some complexity of Java generics comes from its attempt to provide variance support; but the incomprehensible parts can be traced directly back to type erasure.
|
|
|
Message #253281
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Feh - time warp ?
That seems rather abstract. Can you please define concrete problem in form of:
1) Business level problem
2) Solution in language with non-erasure generics
3) Solution in Java
List of benefits and drawbacks for 1, 2 and 3.
|
|
|
Message #253282
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Feh - time warp ?
That seems rather abstract. Can you please define concrete problem in form of:
1) Business level problem
2) Solution in language with non-erasure generics
3) Solution in Java
List of benefits and drawbacks for 1, 2 and 3. I don't know. I don't personally have the same problem as the blogger did; I manage to use generics without the same frustration. That said, he's doing different things than I am. That doesn't invalidate his point; it just means I might not be the one to see the solution.
|
|
|
Message #253286
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Wicket and generics and the end of Java
if the problem can't be solved in such a way that ordinary programmers can write and not just use generics....
Not at all sure that this is valid... Writing useful reusable/generic code that will stand the test of time and will be voluntarily reused is hard; it doesn't matter what the language structure/syntax/concepts/mapping/etc are.
Maybe the problem is too many people trying to write generic code? (after getting "hello world" to compile, we all want to right?) Maybe stuff should only be "genericified" by popular demand after it has proved itself worthy in specific cases. At that point it should just be a matter of syntax which could be automated?
the original blogger might have a good point but it reads like a rant
|
|
|
Message #253283
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Feh - time warp ?
That seems rather abstract. Can you please define concrete problem in form of:
1) Business level problem
2) Solution in language with non-erasure generics
3) Solution in Java
List of benefits and drawbacks for 1, 2 and 3. I don't know. I don't personally have the same problem as the blogger did; I manage to use generics without the same frustration. That said, he's doing different things than I am. That doesn't invalidate his point; it just means I might not be the one to see the solution.
Fair enough.
Can any of Java-haters out there provide such reference where we can have quality discussion about the matter at hand?
One can only seen Java qq-ers doing "Java generics suck" but they like never provide concrete problem definition.
|
|
|
Message #253285
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Feh - time warp ?
And the problem is?
There are some people who always blame everyone else if they can't understand something. The author of this blog is a typical example. He decided that "java is going to die" simply because he was unable to cast list of strings to list of objects. :-)
|
|
|
Message #253290
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Feh - time warp ?
It is interesting to note that high majority of "Java sucks" posts/blogs comes from people developing UI/Web applications.
Coincidence? I think not.
|
|
|
Message #253293
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Paradox much?
No, writing generics in Java is not hard. Some people should just take a look at Java source code that comes with JDK, such as Collections classes and so on and learn from it. You cant learn generics for the first time in your life in 5 minutes.
It is VERY interesting observation that at one side we have people qq-ing how writing generics in Java is hard, and at the other side we have people demanding addition of closures to Java, which would add additional complexity.
And the REAL FUN part when same people promote both of those things.
|
|
|
Message #253300
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Generics - great, but with a learning curve
Personally, I think generics are great, but they have somewhat of a learning curve in terms of learning when to use it and when to avoid it.
Once I started using generics, it took me the better part of a year to actually get my head around how to best use them, and when to avoid them.
The problem probably lies in that there are lots of cases that look like open and shut cases for generics, but where you should actually avoid it. The other side of it is to gain the understanding to really leverage the power of generics.
|
|
|
Message #253302
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Wicket and generics and the end of Java
Java generics work for simple things like lists of Strings but when you get into something a little more deep, they start to get into the way. The most important feature of generics is SupressWarnings("unchecked") despite what hardly-coding 'experts' tell you. But sometimes I get hard errors on things that should be fine. And then I'm never sure if it's an error in the compiler and frankly I don't have time for that bullshit so I drop back and do some casts and move on with my life. Where I work we have just recently had the option to move to Java 5 and I'm not really sure we should do it.
|
|
|
Message #253305
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Problem
Maybe it'll turn out there's no problem. That's fine. But if there IS... they're now considering it. That contributes to the global knowledgebase, so to speak, and that is a Good Thing.
Maybe there is a problem. Or maybe, the problem is that there is no problem, but there is a problem seeing that fact. Is that a problem? I don't know... I have a problem seeing problems sometimes, when there may or may not be a problem with the problem-seeing of my problem problem. Problem problem? Problem!
And in conclusion, problem.
|
|
|
Message #253306
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Best description of anti-java qq-ers so far...
Maybe it'll turn out there's no problem. That's fine. But if there IS... they're now considering it. That contributes to the global knowledgebase, so to speak, and that is a Good Thing.
Maybe there is a problem. Or maybe, the problem is that there is no problem, but there is a problem seeing that fact. Is that a problem? I don't know... I have a problem seeing problems sometimes, when there may or may not be a problem with the problem-seeing of my problem problem. Problem problem? Problem!
And in conclusion, problem.
Hahaha. Nice one.
|
|
|
Message #253310
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Paradox much?
No, writing generics in Java is not hard..
agreed its not hard to use generics and the collections examples you give are great starting points to learn the syntax and indeed the concepts... great classes/interfaces that were proven great in early versions of Java and improved and made "generic" when the language evolved.
If you are an experienced programmer with knowledge of equivalents in say c++, yeah 5 minutes is about right, but for an inexperienced programmer it could be 5 years...
Now back to what I actually said....
Writing useful reusable/generic code that will stand the test of time and will be voluntarily reused is hard;
a related topic -- my point is that you're often better to develop and prove the specific solution and then make it generic, most of the problems I see come from people who have specific problems to solve and try to craft generic solutions too early.
And that once you do this
a) If its not a great solution well theres no harm done.
b) If it is a great solution the process for making it generic is largely mechanical.
On balance
1) The benefits of having type safety when writing code which uses generic classes are worth the additional complexity they have added to the language. and that they were right to support backwards compatibility.
2) However the language has got very big, I would hate to see it getting bigger without some very good reasons.
3) It is right that all programmers have access to all the language features that the SDK developers use.
4) My personal opinion is if you're working on a application and find yourself coding lots of generic classes, factories etc, stop and think. Definitely if you're struggling with the language syntax its a sign that you are suffering from a bout of "frameworkitisis" or "architectitisis", painful conditions that affect groups more than individuals and are best detected early and treated by halving the schedule for the first prototype.
|
|
|
Message #253314
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
ok everybody, tell me in 5 seconds whats i the big difference?
public void setResponsePage(Class <? extends Page<?>>) {}
and
public void <C extends ><Page><?>> setResponsePage(Class <C>) {}
For all the people that think that generics are easy to understand/implement and use :)
The problem is that for wicket some people find it to verbose, i am on the side that i think it is pretty good, but i dont mind a bit more code, that also clarifies the code.
also just see this thread:
http://www.nabble.com/(Class%3C--extends-Page%3C-%3E%3E)--casting-troubles-td17355847.html
for the big discussion that is going on.
It would be already quite a bit better if for example instead of this:
Map<String, List><String>> map = new HashMap<String, List><String>>();
we could do this:
Map<String, List><String>> map = new HashMap();
this would cleanup the code already quite a lot for many cases.
|
|
|
Message #253316
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: ok everybody, tell me in 5 seconds whats i the big difference?
this:
public void <C extends ><Page><?>> setResponsePage(Class<C> c) {}
is this ofcourse:
public void <C extends Page><?>> setResponsePage(Class<C> c) {}
|
|
|
Message #253323
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
It deserves more attention ...
Jonathan Locke and wicket people are smart java developers, pushing java web development and the use of java as an object oriented language to new levels.
They deserve you to spend some of your time to understand the problem. If they met a problem, something has happened.
Please stay on the code... and after that desagree if you think so.
|
|
|
Message #253324
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Feh - time warp ?
And the problem is?
There are some people who always blame everyone else if they can't understand something. The author of this blog is a typical example. He decided that "java is going to die" simply because he was unable to cast list of strings to list of objects. :-)
And you are a typical example of someone who only reads the head lines.
In his blog he refers to controversy on how to implement generics the best way in the Wicket framework. Implementing it as part of a framework is a lot more difficult than just applying it, and part of the controversy is not just the 'hardness' but the verboseness.
|
|
|
Message #253325
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Generics - great, but with a learning curve
+1
Generics are complex to grab at first sight but with a bit of poking and reading, we can get to use them well.
As a matter of fact, the following 2 posts generate most of my visits on my blog; that certainly means the official documentation could do with a little bit more explanation, wouldn't it?
http://blog.guillaumebertrand.com/2007/03/14/type-erasure-with-java-generics/
http://blog.guillaumebertrand.com/2008/01/31/fun-with-java-generics/
Well, what is not immediately clear from Johnathan's blog is that the controversy is not just about having a hard time implementing stuff (though read the threads on the mailing list, and you'll see that some things are hard to wrap your mind around, even for experienced programmers), but also the verbosity.
MyComp<Foo> fooComp = new MyCompo<Foo>("myId, new PropertyModel<Foo>(bar, "foo"));
that looks pretty aweful to me.
So part of the controversy is that some people - like me - don't think the extra verbosity is offset by the 'gain', while others think it is worth the pain.
|
|
|
Message #253326
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Paradox much?
No, writing generics in Java is not hard. Some people should just take a look at Java source code that comes with JDK, such as Collections classes and so on and learn from it. You cant learn generics for the first time in your life in 5 minutes.
It is VERY interesting observation that at one side we have people qq-ing how writing generics in Java is hard, and at the other side we have people demanding addition of closures to Java, which would add additional complexity.
And the REAL FUN part when same people promote both of those things.
Well, if you write framework code it can be hard, period. Mainly because the effects trickle down to all parts of the framework and code users wrote to it.
Generics made Java more verbose than it already was, and there are plenty of limitations to it. Take a look at Scala as a contrast of how the same things can actually be expressed in a compact fashion.
|
|
|
Message #253328
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Paradox much?
Take a look at Scala as a contrast of how the same things can actually be expressed in a compact fashion.
Just for the sake of clarity, thinking that Scala does things nicer doesn't mean I think Java is a dead end :-) Still plenty to like about Java and the available tools for it, and I'm using it with mucho pleasure most of the time.
|
|
|
Message #253330
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Generics - great, but with a learning curve
Yes, that's exactly it. Six months ago I had mainly been a user of generics (I read the tutorials and the books and the websites and have been using it since the beginning) and a writer of generics in simple cases... and at that time I would've had all the same opinions of the users saying "read the manual". I don't really have the time or the patience to go through and step-by-step resurrect and reproduce any of the horrible meltdowns I've seen (it would take hours just to explain the circumstances, which is really part of the problem). I'm just reporting on what has been happening on the ground. And all I can say is, when the posters who love generics run into this stuff (and you haven't until you try to generify something fairly complex) I promise not to say "I told you so."
|
|
|
Message #253331
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Broken and Dead
I thought Java was broken and dead because Bruce Eckel doesn't like Exceptions and because Bruce Tate likes Ruby.
|
|
|
Message #253338
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Generics - great, but with a learning curve
Yes, that's exactly it. Six months ago I had mainly been a user of generics (I read the tutorials and the books and the websites and have been using it since the beginning) and a writer of generics in simple cases... and at that time I would've had all the same opinions of the users saying "read the manual". I don't really have the time or the patience to go through and step-by-step resurrect and reproduce any of the horrible meltdowns I've seen (it would take hours just to explain the circumstances, which is really part of the problem). I'm just reporting on what has been happening on the ground. And all I can say is, when the posters who love generics run into this stuff (and you haven't until you try to generify something fairly complex) I promise not to say "I told you so."
Noone said generics are easy, of course they take time to master.
However title of your blog post has "end of Java" in it, which implies you either wanted to increase visits to your blog or you really did not master concepts at hand. Or maybe you are just trolling.
|
|
|
Message #253339
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Broken and Dead
I thought Java was broken and dead because Bruce Eckel doesn't like Exceptions and because Bruce Tate likes Ruby.
Latest headlines:
Quote:
"37Signals knows a Truth. Chase the big customers, and they own you. Chase little customers, and even if you piss one off totally, the other 9,999 still love you. I'm with them. Big customers are a big pain. The only trick is to find a market"
http://www.wired.com/techbiz/media/magazine/16-03/mf_signals
|
|
|
Message #253340
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Generics - great, but with a learning curve
Noone said generics are easy, of course they take time to master.
What's your definition of mastering generics? I would say it's knowing most of the information in this FAQ by heart:
http://www.angelikalanger.com/GenericsFAQ/JavaGenericsFAQ.html
Most FAQ's don't need alphabetized indexes. Think about that for a while. The frequently asked questions about generics could fill a book. I think there might be nearly as much to know about generics than there was to know about the whole Java language prior to 1.5.
|
|
|
Message #253344
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Example
This is my favourite example of generics horror.
Question for generics fans: what do you see as the overriding benefit which outweighs the cost in increased complexity? Is it because it makes the code seem more aesthetically pleasing, or is it because you used to be continually plagued by runtime ClassCastExceptions? I have to say I can't remember the last time I got a ClassCastException but then I'm the sole author and maybe generics has greater advantages in large teams.
|
|
|
Message #253345
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Example
This is my favourite example of generics horror.
Question for generics fans: what do you see as the overriding benefit which outweighs the cost in increased complexity? Is it because it makes the code seem more aesthetically pleasing, or is it because you used to be continually plagued by runtime ClassCastExceptions? I have to say I can't remember the last time I got a ClassCastException but then I'm the sole author and maybe generics has greater advantages in large teams.
Even though I've been bashing generics here, I actually like them up to a point. I use maps and lists in my code and freshing my memory of the types in the collections slows me down a bit. Generics solves that problem well. But I'm not convinced it's enough to outweigh the downsides.
|
|
|
Message #253347
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Generics - great, but with a learning curve
I think if this isn't fixed, generics represents the same fatal level of complexity in C++ which led to Java. When I say "the end of Java" I of course mean the beginning of the end. C++ has clearly begun to end and there's no reason Java can't follow. I personally think we're in a period where the paradigm is breaking down and all that's left is to find a successor. I initially thought Scala might be that successor, but I don't think they will achieve mainstream adoption as not enough effort was put into making it simple and intuitive (too much academia oriented notation). On the other hand, it clearly solves a whole bunch of problems that Java does not solve and represents a viable solution for some minority of determined programmers.
|
|
|
Message #253349
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Example
That is exactly my experience. It's great when someone else writes a generic library that I use and is great for simple cases. I just don't ever want to write a generic framework and I would be wary in the future of applying generics to anything but the simplest problems.
|
|
|
Message #253350
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: It deserves more attention ...
Jonathan Locke and wicket people are smart java developers, pushing java web development and the use of java as an object oriented language to new levels. AFAICS, the wicket people created a user-friendly, not a geek-friendly Java framework without the (old) XML mess and without the (new) Annotations mess. It's not difficult to bloat a language or a framework (examples abound in Java land). The real challenge for a designer is to make things simple.
|
|
|
Message #253351
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Generics ARE Hard
People who say that Generics aren't difficult don't know what they're talking about. If you doubt it, go read the FAQ:
http://www.angelikalanger.com/GenericsFAQ/JavaGenericsFAQ.html
The PDF version is ~350 page last time I checked. If Generics are so simple, why do they need a 350 page FAQ to explain?
Yeah, writing "Map<String, List><Integer>>" or whatever is trivial, but try doing anything complicated with wildcards and/or inheritance and get ready to lose your mind.
|
|
|
Message #253353
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Paradox much part 2?
People who say that Generics aren't difficult don't know what they're talking about. If you doubt it, go read the FAQ:
http://www.angelikalanger.com/GenericsFAQ/JavaGenericsFAQ.html
The PDF version is ~350 page last time I checked. If Generics are so simple, why do they need a 350 page FAQ to explain?
Yeah, writing "Map<String, List><Integer>>" or whatever is trivial, but try doing anything complicated with wildcards and/or inheritance and get ready to lose your mind.
So whats the problem again? If you dont understand them dont use them. If you dont have time to invest in know-how, then dont qq here.
My prediction is, if closures are added in Java 1.7 we will see same topics like this one in years to come.
I bet that majority of people hating generics would like to see closures added to Java.
|
|
|
Message #253354
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Generics - great, but with a learning curve
I think if this isn't fixed, generics represents the same fatal level of complexity in C++ which led to Java. When I say "the end of Java" I of course mean the beginning of the end. C++ has clearly begun to end and there's no reason Java can't follow. I personally think we're in a period where the paradigm is breaking down and all that's left is to find a successor. I initially thought Scala might be that successor, but I don't think they will achieve mainstream adoption as not enough effort was put into making it simple and intuitive (too much academia oriented notation). On the other hand, it clearly solves a whole bunch of problems that Java does not solve and represents a viable solution for some minority of determined programmers.
You dont have to use generics if you dont want to. That is good thing.
Can you please provide example how problem that is hard in Java can be solved significantly easier in Scala please? I dont care how good it looks in the eye, all I wanna see if there is some business benefit from using Scala.
Please enlighten me, show me what you can do in Scala which is undoable in Java.
Thanks
|
|
|
Message #253355
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Paradox much part 2?
People who say that Generics aren't difficult don't know what they're talking about. If you doubt it, go read the FAQ:
http://www.angelikalanger.com/GenericsFAQ/JavaGenericsFAQ.html
The PDF version is ~350 page last time I checked. If Generics are so simple, why do they need a 350 page FAQ to explain?
Yeah, writing "Map<String, List><Integer>>" or whatever is trivial, but try doing anything complicated with wildcards and/or inheritance and get ready to lose your mind.
So whats the problem again?
They add more complexity than they are worth.
If you dont understand them dont use them.
Perhaps if you live on planet "isolated nerd" that's an acceptable answer but here on earth, people have to work together with a shared language. And it's not a question of not undestanding, it's a question of having to write stupid code to get avoid useless error messages.
If you dont have time to invest in know-how, then dont qq here.
My prediction is, if closures are added in Java 1.7 we will see same topics like this one in years to come.
I bet that majority of people hating generics would like to see closures added to Java.
My guess is you haven't invested much time in know-how with generics.
|
|
|
Message #253356
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Generics - great, but with a learning curve
Please note that relevant benefits I wanna see are only those that affect costs in development phase of any software project.
We can assume for the sake of simplicity that runtime performance of both Java and Scala is equal.
So, I would like to see, if you would be kind to provide, how much money can be saved using those featires from Scala in development phase.
Thanks
|
|
|
Message #253357
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Paradox much part 2?
People who say that Generics aren't difficult don't know what they're talking about. If you doubt it, go read the FAQ:
http://www.angelikalanger.com/GenericsFAQ/JavaGenericsFAQ.html
The PDF version is ~350 page last time I checked. If Generics are so simple, why do they need a 350 page FAQ to explain?
Yeah, writing "Map<String, List><Integer>>" or whatever is trivial, but try doing anything complicated with wildcards and/or inheritance and get ready to lose your mind.
So whats the problem again?
They add more complexity than they are worth.
If you dont understand them dont use them.
Perhaps if you live on planet "isolated nerd" that's an acceptable answer but here on earth, people have to work together with a shared language. And it's not a question of not undestanding, it's a question of having to write stupid code to get avoid useless error messages.
If you dont have time to invest in know-how, then dont qq here.
My prediction is, if closures are added in Java 1.7 we will see same topics like this one in years to come.
I bet that majority of people hating generics would like to see closures added to Java.
My guess is you haven't invested much time in know-how with generics.
You keep describing the problem yet you dont propose solution.
If you know a better way to implement erasure-based generics than Neal Gafter, please enlighten us all.
Eagerly looking forward to your response.
|
|
|
Message #253358
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Generics - great, but with a learning curve
Please enlighten me, show me what you can do in Scala which is undoable in Java.
Thanks
Anyone with the slightest knowledge of computer science knows that anything you can do in one Turing-complete language can be done in another Turing-complete language. So the question as stated is just a strawman.
If you want to know what features exist in Scala that don't exist in Java, that's too much information to explain in a forum post.
Whether there's a business benefit to going to Scala from Java is something I kind of doubt (well, where I work anyway) but I feel the same about introducing generics.
I think Scala is not the likely successor to Java but maybe the ancestor of the future successor of Java. It includes too many features that could wreak havoc in your average chaotic shop. My least favorite of these is global implicit conversions. Non-local effects are a huge problem when you have different developers of varying skill levels and ideas about how much they owe others in terms of easily maintained code.
|
|
|
Message #253361
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Paradox much part 2?
You keep describing the problem yet you dont propose solution.
The solution is to not go to Java 5. It's not a great solution. Another one is to go to Java 5+ and restrict the use of generics. But that's difficult considering that I have a hard time keeping contractors in line when using Java 1.4.
If you know a better way to implement erasure-based generics than Neal Gafter, please enlighten us all.
Eagerly looking forward to your response.
Erasure is the main problem. Neal Gafter is brilliant and I figure that if he had left Sun earlier, Java 5 would have been a total disaster. He and his team pulled off a pretty amazing feat given the constraints. From reading his blogs and conversing with him on forums, I get the impression that he thinks erasure isn't such a good idea either. And that Scala has inherited erasure is another annoyance.
|
|
|
Message #253362
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Generics - great, but with a learning curve
Whether there's a business benefit to going to Scala from Java is something I kind of doubt
Yeah, thought so. Lets have a talk again in 10-15 years if you agree, I am kinda busy now, like, you know, building business application with best platform on market.
|
|
|
Message #253363
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Paradox much part 2?
The solution is to not go to Java 5. It's not a great solution.
I have to disagree with this statement big time. Java5 is big, I mean, really big step forward from Java 4. Generics are just one small part of overall Java5 benefit.
If you dislike, them dont use them (generics).
|
|
|
Message #253364
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: It deserves more attention ...
It's not difficult to bloat a language or a framework (examples abound in Java land). The real challenge for a designer is to make things simple.
Yeah. That's exactly why we're having the discussions about how to implement generics. We want it to make the framework better (for users), not just because it's a new feature.
In the case of generics, it really boils down (imho) to a tradeoff between more type safety, API discoverability/ clarity on the one side, and verbosity (which if taken too far can make code harder to read) on the other.
Specifically for Wicket, I like it that you can now (with generics applied as they are in 1.4) say that your component can only be created with model (IModel) instances that produce objects of type X. That's a great addition that improves readability, API clarity, etc.
For example:
public PersonView(String id, IModel<Person> model)
to me is a great improvement over:
public PersonView(String id, IModel model)
In the old situation you'd either have to implement run time checks (preferably in the constructor, while at that point you may not even know whether the model will actually be accessed and at what point by the component or it's children) or you'd have to use a generified base implementation of IModel.
So that's good. Avoiding casts however, like being able to do:
new RefreshingView<Foo>("id") {
protected Iterator<IModel><Foo>> getItemModels() { return getFooItems(); }
protected void populateItem(Item<Foo> i) {
Foo f = i.getModelObject();
...
compared to the old way:
new RefreshingView("id") {
protected Iterator getItemModels() { return getFooItems(); }
protected void populateItem(Item i) {
Foo f = (Foo)i.getModelObject();
...
is something I don't care about at all. It wouldn't help me avoid making mistakes, because that's not the area I or my colleagues make them, it imho actually hurts readability because of the verbosity.
Not everyone agrees with me though, and that's why we're discussing on the list :-) And I'm actually close to giving it a rest and just settle for 'Java isn't perfect, but still better than most of the alternatives'.
|
|
|
Message #253365
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Paradox much part 2?
I bet that majority of people hating generics would like to see closures added to Java.
For the record, I don't hate generics. Applying them with taste is another matter though, and I do think that we could have had a nicer implementation if the authors would have been able to start clean slate (I guess I'd love advanced type inference like Scala has and generics are only part of that).
Yes, I'd love to have closures. I'm using anonymous classes very often and closures would often provide a more concise way of expressing most of them. As to wether it is a good idea to add them to Java... well, I'm kind of torn on that. I agree with people like Bloch who prefer Java to be kept simple. Adding more ways to achieve the same thing is typically a bad idea, and I agree with you that there will probably be controversy in the future on closures.
Again for record, Jonathan (the author of the blog that is referred to in this article) thinks adding closures is a bad idea.
|
|
|
Message #253366
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: It deserves more attention ...
Java isn't perfect, but still better than most of the alternatives.
Exactly. I would just fix this statement a bit:
Java isn't perfect, but still better than any of the alternatives for any enterprise development with backend processing.
|
|
|
Message #253367
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Generics - great, but with a learning curve
It includes too many features that could wreak havoc in your average chaotic shop.
Yeah, one of the things that I don't like in Scala is that there are so many ways to achieve the same. And things like operator overloading (even though technically it isn't that, but just for the sake of the argument)... well that alone is something that scares the sh*t out of just about every experienced programmer I know.
My least favorite of these is global implicit conversions.
Oh, I actually like these! Lots of dangers with that, I agree, but great for doing things like Nathan describes in one of his blog items.
|
|
|
Message #253368
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Generics - great, but with a learning curve
Please note that relevant benefits I wanna see are only those that affect costs in development phase of any software project.
Sounds like you have a real passion for software engineering! ;-)
We can assume for the sake of simplicity that runtime performance of both Java and Scala is equal.
That's basically the reality yes.
So, I would like to see, if you would be kind to provide, how much money can be saved using those featires from Scala in development phase.
17,61 USD per hour/ development seat. Give or take 2 cents.
What are the advantages of using Java over Cobol? Or Ruby? You can write books about the differences and it all depends on your team, your projects, etc, etc
Scala is a type safe, statically compiled language that runs on a JVM can can fully interact with your Java programs. Some of the things that I like in Scala compared to Java are it's advanced type inference, which would make much my code easier to read/ maintain, things like support for mixins, which would make some of the things I do more straightforward and elegant to implement (and pls don't give me that elegance doesn't save you money crap, because in the long term it just does), and the same goes for having functions as a first class citizen in the framework.
You can read the rest on the Scala web site and book.
|
|
|
Message #253369
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
I just use arrays
I understand the issue of generics, but I think generics is a big solution for a small problem. I just convert all my lists to arrays and try to keep my use of maps and tables to a minimum.
|
|
|
Message #253371
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Generics - great, but with a learning curve
Sounds like you have a real passion for software engineering! ;-)
For me Java is just a tool to accomplish business goals. When I wanna to some geek stuff just for myself, to have some so to say casual fun, I check out GridGain, ActiveMQ, and similar, tools/concepts independant of language of implementation.
I just prefer to have passion in software engineering at different level of abstraction, so I dont think its right to assume I am only for money in IT.
That's basically the reality yes.
Hm hm hm, dont have data to back up my claim but I doubt it. Sun invested loads of money in JVM. Are there any benchmarks out there to double check this?
What are the advantages of using Java over Cobol? Or Ruby? You can write books about the differences and it all depends on your team, your projects, etc, etc
You seems to think only at programming language level of abstraction. Java has ecosystem, like this one:http://java-source.net/. We gotta take into consideration tools and frameworks built on top of Java.
You have open source, production ready tools for almost any domain and every phase of software development lifecycle, and other programming languages you are mentioning do not have such features, and hence that is advanatage of using Java, small to mid sized companies can builkd solutions with 0/nada investment in software, just have to invest in know-how.
|
|
|
Message #253373
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Generics - great, but with a learning curve
Hm hm hm, dont have data to back up my claim but I doubt it. Sun invested loads of money in JVM.
Read more about Scala and you'll see that it was designed to run on the JVM, compiles to classes, etc. It's statically typed so it can be optimized the same way Java code is.
You seems to think only at programming language level of abstraction
Nope. I'm a big fan of IDEs and the open source ecosystem around Java (I'm even involved in a couple). But tooling is only part of it, the language is very important as well, and in fact often determines what can be done with tooling. Besides, there's plenty of tooling around that looks great in an advertisement but aren't helping developers much the end of the day.
|
|
|
Message #253376
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Generics - great, but with a learning curve
Whether there's a business benefit to going to Scala from Java is something I kind of doubt
Yeah, thought so. Lets have a talk again in 10-15 years if you agree, I am kinda busy now, like, you know, building business application with best platform on market.
I use Java now where I work too. I actually dabble with Jython too but that's a little too "out-there" where I work.
I have to disagree with this statement big time. Java5 is big, I mean, really big step forward from Java 4. Generics are just one small part of overall Java5 benefit.
I agree but I would have to find a way to effectively keep generics out of the picture or at least make sure developers aren't wasting time f'ing around with generics.
But this is the problem with generics. It's creates more trouble than it's worth.
|
|
|
Message #253377
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Generics - great, but with a learning curve
It includes too many features that could wreak havoc in your average chaotic shop.
Yeah, one of the things that I don't like in Scala is that there are so many ways to achieve the same. And things like operator overloading (even though technically it isn't that, but just for the sake of the argument)... well that alone is something that scares the sh*t out of just about every experienced programmer I know.
Maybe I've just not dealt with enough operator overloading, but it doesn't scare me that much. I'm tired of having to write out add and subtract.
The more I use Python thise looks like crap. It's not just a typing issue. When used appropriately, operator overloading makes code easier to read. When used inappropriately it makes things worse but I've seen a lot of hard to read code in Java. Eliminating operator overloading didn't eliminate confusing naming for methods.
My least favorite of these is global implicit conversions.
Oh, I actually like these! Lots of dangers with that, I agree, but great for doing things like Nathan describes in one of his blog items.
I like implicit conversions. I just don't like the idea of making them global. I think you should have to either import them or define them in your source file. I don't like the idea of looking and code and thinking it does one thing but really it does something else entirely because of some global conversion I didn't know about.
|
|
|
Message #253378
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Java is faster than Scala
Well you first said Scala can compare in performance with Java didnt you? =)
I just proved you wrong, kind of.
No I don't feel you proved me wrong. I was sarcastic towards benchmarks. People have holy wars on how to create proper ones, and I've seen plenty myself that were pretty meaningless.
More importantly, like I said, Scala runs on the JVM in the same way Java does. There is no reason why it can't run just as fast.
|
|
|
Message #253380
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
NICE JOE!
Glad you're continuing with your endless "Java is Dead" subjects! TSS is just so interesting these days...
|
|
|
Message #253383
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Wicket and generics and the end of Java
Well said Bill.
I think the quality of posts on TSS has considerably gone down since Joe appeared on the scene and I strongly feel this would hurt the TSS community in the long run.
Mr. Joe, you may have very strong opinions about "Java is dead" (because Joe doesn't like it!!!) but please stop pushing your point again and again. From your recent post I feel what you really want to say is this,
"Java should be dead because Joe doesn't like it".
I'll suggest you to start working on "earning your respect" and stop this childish behavior of bitching java. But I also know that it's going to be difficult for you. You may never be able to keep aside your ego to overcome this.
Hope you get the point.
|
|
|
Message #253385
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Generics - great, but with a learning curve
I think if this isn't fixed, generics represents the same fatal level of complexity in C++ which led to Java. When I say "the end of Java" I of course mean the beginning of the end. C++ has clearly begun to end and there's no reason Java can't follow. I personally think we're in a period where the paradigm is breaking down and all that's left is to find a successor. I initially thought Scala might be that successor, but I don't think they will achieve mainstream adoption as not enough effort was put into making it simple and intuitive (too much academia oriented notation). On the other hand, it clearly solves a whole bunch of problems that Java does not solve and represents a viable solution for some minority of determined programmers.
I agree! They need to make FIXING generics in Java 7 the TOP priority. We don't need more junk in the language making it even more complex (i.e. closures, etc).
What ever happened to the work that was going on to fix generics in Java 7?
|
|
|
Message #253386
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Wicket and generics and the end of Java
Good discussion. I have recently started working on a Java 1.5 project for the first time, lost a battle over using a single persistence (Entity) manager and casting over tons of "type safe" DAO's using generics. Does Hibernate still do a cast? Yes. Is the code bug free due to the use of Generics? No. Is it more complex and verobose? Yes.
So why do people want to use this stuff? I think it comes back to Steve Yegges post about Noob programmers. Other than these guys are not newbies they are seasoned, but they have been brought up on a diet of trust the compiler, the compiler is always right, and the compiler is your best friend. What we have here I think is modeling in the code with the compiler backing you up, so it must be a good thing right?
Well no. Generic programming is a different beast to Object Orientated programming and the two can conflict. So if your design is meant to be OO then what you want to do is hide as much of the implementation as possible. Generics do the opossite by exposing implmentation so that your compiler can perform a static check. This implementation (type) exposure limits polymorphism, which is something that happens at runtime (I won't start about needing late-binding for full ploymorphism :)). So you are restricting how Object Orientated your design can be.
So are these people stupid? No I don't think they are, they just don't fully understand objects. Is this a surprise given that most Java programmers have only come to objects through an hybrid language? No I don't think so.
OO has still got a lot to offer I think. I'm not sure about generic programming. I don't claim to understand it well enough to say. But OO is very powerful, and most of that power hasn't yet been exploited by the mainstream. All you need to do is take a look at something like Open Croquet with synhcronised, distributed, replicated objects over the internet to see the yet untapped power of Objects:
http://www.opencroquet.org/index.php/Main_Page
The problem I think is that most of us have not been exposed to pure OO and end up mixing hybrid ideas that just don't work that well together.
Paul.
|
|
|
Message #253387
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
its not all more verbose it also saves.. but if sun did a few ..
Currently the only thing that is bothering people that it is more verbose (i am on the pro side by the way, i like it because i dont mind a litle more verbosity on the declaration side).
We did fix most annoying problems one of them is what i said above with the setResponsePage() example. Because 1 compiles and 1 doesnt for certain situations.
So many people are complaining about the verbosity but if we just look at map:
Map<String,List><Person>> map = new HashMap<String,List><Person>>()
yes that is a more verbose. But it saves for me many characters after that!! Why dont people say that. If i now what i do many many times get the entrySet() of that map in a foreach loop.. then i have saved in the end a lot more chars typing then the declaration created.
So only if sun would fix the declaration side so that you can do this for example:
Map<String,List><Person>> map = new HashMap()
or the other way around, dont know which one would be best..
Map map = new HashMap<String,List><Person>>()
then also that would be in wicket a big saver. We would gain 50% or 33%.
But i wicket i would like to have another option but that is pretty advanced type guessing i guess. Because i would like to say that something that goes into the constructor as a parameter would type back the component,
Now it is so that TextField<String> is leading that fixes what IModel can be given to the constructor (must be of type <String>) i would like to have it the other way around.
So if i just say this:
TextField field = new TextField("id", new Model<String>());
then the field gets the type from the model... so the field is is now TextField<String> under the hood.
Then if we could also declare a default generic type if you dont specify it and dont use a model (<Void>) then all our code would be completely clean and perfectly generified.
|
|
|
Message #253388
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Wicket and generics and the end of Java
Well said Bill.
I think the quality of posts on TSS has considerably gone down since Joe appeared on the scene and I strongly feel this would hurt the TSS community in the long run.
If you dont like this thread you can go that way ------>.
Actually your post is bringing the quality of posts down because you use personal attacks. You use public place to attack someone for no other reason than someone posted something you dont like.
|
|
|
Message #253393
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: its not all more verbose it also saves.. but if sun did a fe
Map<String,List><Person>> map = new HashMap<String,List><Person>>()
TSS is overly aggressive in matching angle brackets...
|
|
|
Message #253400
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Generics - great, but with a learning curve
MyComp<Foo> fooComp = new MyCompo<Foo>("myId, new PropertyModel<Foo>(bar, "foo"));
that looks pretty aweful to me.
So part of the controversy is that some people - like me - don't think the extra verbosity is offset by the 'gain', while others think it is worth the pain.
I like generics (and Wicket), but I don't see the point of writing code like that.
Personally, I tend to only use generics when defining something where type safety makes sense, like where you know you will retrieve objects of a certain type (ie. there are getters to get objects of a type, as is the case with the java Collections classes).
Writing "<Foo>" where you as a developer are actually never retrieving objects of type Foo is just verbose and a waste of space.
|
|
|
Message #253401
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Generics - great, but with a learning curve
but you do retrieve objects of that type...
|
|
|
Message #253402
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Generics - great, but with a learning curve
but you do retrieve objects of that type...
Depends. I often let the models (property models typically) do the work, and only retrieve the object on a form submit. The types of the nested form components doesn't matter much then.
|
|
|
Message #253408
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Generics - great, but with a learning curve
yeah we should have something like this:
class Link<T default Void> extends Component<T>
|
|
|
Message #253413
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Avoiding a little bit of verbosity
TextField field = new TextField("id", new Model<String>());
Actually you can get pretty close to that by using static
generic methods. It is possible to write the following at the cost of two new factory methods:
TextField<String> field = createTextField(createModel("..."));
I posted the full code on my blog (no bracket problems):
http://coding-exercises.blogspot.com/2008/05/avoiding-java-generics-verbosity.html
Yeah, that can be a good solution for individual projects. However, doing it as part of the base project would explode the API possibilities, which wouldn't make it easier to use. Also, factory methods pins down to specific classes, while I often override components (typically using anonymous classes) to e.g. specify a custom isVisible etc.
Thanks for the post.
|
|
|
Message #253417
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Paradox much part 2?
Hi James,
From reading his blogs and conversing with him on forums, I get the impression that he thinks erasure isn't such a good idea either.
It is a bad idea, but all the other ideas are worse.
We already knew that many years ago, even when Generics were beginning to surface in Pizza and similar attempts. We knew that if Generics were going to come to Java, we would have to either choose erasure (and maintain backward compatibility) or pick reification (and tell everyone that they need to recompile, and possibly rewrite, all their code).
What I find striking in Jonathan's blog is that he says that he prefers C# for its support of reification but apparently didn't think of verifiying that the anecdotal problem he uses to blast Java Generics ("I can't cast a list of strings into a list of objects") works in C#. Surprise: it doesn't either. And to top it all: the reason why this doesn't work has *nothing* to do with erasure or reification.
The bottom line is that allowing this kind of cast makes no sense, regardless of the implementation.
I don't know Jonathan, I'm sure he's a good Java developer, but this kind of outburst on a blog without doing some simple homework makes me think that his assessment of Generics, and the health of Java in general, cannot be trusted until he does some reading on the subject.
--
Cedric
|
|
|
Message #253418
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: its not all more verbose it also saves.. but if sun did a few ..
So many people are complaining about the verbosity but if we just look at map:
Map<String,List><Person>> map = new HashMap<String,List><Person>>()
By the way, you can also implement a helper method that will reduce this code to:
Map<String,Person> map = Maps.newHashMap();
I have a bunch of these for various concrete collections and they make my code much more readable (on top of giving me a chance to change the initialization values later down the road).
--
Cedric
|
|
|
Message #253420
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Paradox much part 2?
God no, that was just a personal gripe of no real substance.
The anecdote I would use to bash Java generics was the original post: teams of very smart engineers who have read about generics are failing spectacularly with them.
|
|
|
Message #253421
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Paradox much part 2?
I would also like to point out that this was not part of my original post.
It seems to me that what you want to do is pick a sidebar gripe I made in response to the original post to criticize and frame as my core argument so you can avoid even considering that I might have a valid point here.
|
|
|
Message #253422
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: its not all more verbose it also saves.. but if sun did a fe
I have a bunch of these for various concrete collections and they make my code much more readable (on top of giving me a chance to change the initialization values later down the road).
--
Cedric
Yeah, that can improve your code somewhat. However, I often do things like this:
MyComp = new MyComp("id", model) {
public boolean isVisible() {
return someAlgothmExecutedHere();
}
}
And factory methods don't support that.
It is somewhat specific to Wicket to prefer doing this rather than initializing the object with a specific value (like calling setVisible), but basically this achieves lazy initialization or makes up for the fact that you can't pass in functions (yes, we could have introduced another indirection for this, e.g. working with an interface instead of a boolean member that determines whether the component should be rendered, but this would again explode the API and now users can decide to implement such a thing regardless), and it can also save memory as you can avoid having to use member variables (not true in the case of visible, and a Wicket specific problem since Wicket depends on utilizing server side memory).
|
|
|
Message #253423
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: its not all more verbose it also saves.. but if sun did a fe
it can also save memory as you can avoid having to use member variables
... at the expense of creating an anonymous class. Not convinced it's a good compromise, memory-wise :-)
--
Cedric
|
|
|
Message #253424
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Paradox much part 2?
It seems to me that what you want to do is pick a sidebar gripe I made in response to the original post to criticize and frame as my core argument so you can avoid even considering that I might have a valid point here.
Well, it's the only technical point that I could find in your post. I would love to see more examples of your problems with Generics, if only to figure out if these are legitimate points or just a manifestation of the fact that Generics might not be a good match for Wicket
--
Cedric
|
|
|
Message #253425
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: its not all more verbose it also saves.. but if sun did a fe
it can also save memory as you can avoid having to use member variables
... at the expense of creating an anonymous class. Not convinced it's a good compromise, memory-wise :-)
--
Cedric
Why not? Surely introducing an instance variable used in every instance is more expensive than introducing an extra class once.
|
|
|
Message #253426
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Paradox much part 2?
It wasn't meant to be a technical post and the worst problems I've seen were not on Wicket. It would be extremely difficult and time-consuming to explain the meltdowns I've seen as not only are the problems intricate, but all the source code is proprietary.
|
|
|
Message #253427
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Paradox much part 2?
or just a manifestation of the fact that Generics might not be a good match for Wicket
Generics are a good match for Wicket, if only because Wicket tries to provide programming model based on regular (imperative) Java programming (opposed to declarative models in use by most of the alternative web frameworks).
The controversy* on the Wicket mailing list is mainly about the fact that coding with Wicket - or any other API that uses generics - gets a lot more verbose, up to the point that some people (y.t. included) wonder whether the benefits offset the decreased readability. Whether is decreases readability is subjective of course.
Another thing - maybe what triggered Jonathan to post his rant - is that there have been several discussions on how to implement certain things properly with generics. I've had several such discussions on my day job, and so had many other people I know in theirs. The typical answer to that from 'people who get it', is that you should re-read the specs/ book/ etc. and/ or get a better brain. Others (like y.t.) think this is just a indication that generics hurt Java as much in some areas as it benefitted it in others. It is hard enough to design APIs well, and generics - as we now find out - make it even harder.
* The whole issue actually isn't as big as you'd think reading John's blog and this thread; we were merely discussing on the mailing list how far to go with implementing generics.
|
|
|
Message #253430
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Paradox much part 2?
We already knew that many years ago, even when Generics were beginning to surface in Pizza and similar attempts. We knew that if Generics were going to come to Java, we would have to either choose erasure (and maintain backward compatibility) or pick reification (and tell everyone that they need to recompile, and possibly rewrite, all their code).
Hi Cedric,
Maybe you can help me here. Why use generics at all? When is it a good idea and when is it a bad idea? The problem I have with generics is similar to the problem I had with C++ many years ago. I just don't know when OO programming starts and something else (Generic Programming, Procedural programming, etc) ends.
Is Generic programming Object Orientated? Or is it something else? With an hybrid language it is hard to maintain uniformity when you have competing concepts. Does OO and Generic programing compete or do they compliment each other?
Regards,
Paul.
|
|
|
Message #253431
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
NOT backwards compatibility
It is a bad idea, but all the other ideas are worse.
We already knew that many years ago, even when Generics were beginning to surface in Pizza and similar attempts. We knew that if Generics were going to come to Java, we would have to either choose erasure (and maintain backward compatibility) or pick reification (and tell everyone that they need to recompile, and possibly rewrite, all their code)
This is a myth. Type erasure is not about backwards compatibility; it is about an niche constraint called migration compatibility. If you watch closely that is also the term Neil Gafter uses.
Get this straight: Backwards compatability was entirely possible with reified generics. You would be have been able to run old code - without recompilation - alongside new code. Code using generics would have been able to call old (non-generic) code, even pass new-style generic collections to old code which expected IList, ISet or something like that. This is what C# and VB.NET did.
Migration compatability is backwards compatability taken to the extreme, a situation where two libraries in your stack are - out of your control (i.e. no source code),
- directly dependant on eachother (you cannot go in between)
- one library evolves faster than the other and uses new generic collections where the other does not, thus making the libraries incompatible
- you absolutely need the features of the latest version of the library and cannot wait for the library vendors to sort out their incompatibilities.
If any one of the above bullets did not apply, you would not need migration compatibility.
That is the scandal of type erasure. It solves a niche constraint - one of temporary nature, mind you - which it is unlikely to have benefitted anyone, ever. The price is a plethora of freak constraints imposed on an entire community for all time to come.
The migration compatability constraint was imposed on the JCP from the start. They did their best job with it. The JCP members knew and discussed all of these contraints. But they failed to put a foot down and take the contraint back to be erased once they realized the tremendous cost of type erasure could render generics "not worth the trouble".
C# and Visual Basic.NET got reified generics with .NET 2.0. It was backwards compatible: Old code run on the 2.0 engine without recompilation, old code calls new code, new code calls old code. Get over the "backwards compatibility" thing. It is a red herring.
|
|
|
Message #253433
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: NOT backwards compatibility
I agree with you C#/.Net have done a fabulous job with generics.
|
|
|
Message #253438
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: NOT backwards compatibility
I agree with you C#/.Net have done a fabulous job with generics.
I would not say C#/.NET did a fabulous job; they just did not mess up the way Sun/JCP did.
Type erasure has turned out to be a very bad idea. I trust that Java generics with type erasure are best possible solution given the imposed constraints; but it also comes very close to render generics almost unusable for anything but the standard collection types.
What I find difficult to comprehend is how the the niche constraint migration compatability was allowed to dominate the entire design process and solution. You would think somebody at some point would have asked:
"Given all of the complexity, gotchas and limitations imposed by type erasure, is this really worth it?".
|
|
|
Message #253442
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
"the java problem is".
You guys must not be reading the blogs on Java.
Let me put it in context w/ a why.
Java 1.4 was kool, problem was EJB.
Some creeps still try to fix EJB by adding XDoclets.
Sun, in order to give us more EJB copies this and adds creepy hard to read syntax for EJB into Java.
A notations, generics, all for EJB.
EJB crept into Java.
Of course if you like EJB tech, then you like the new Java.
I don't like EJB.
It comes down to purpose of writing code, the purpose of writing code is someone can read it. It has now become a lot less elegant, thanks EJB, now I am searching for new language, so far D language w/ Tango library looks kool.
.V
|
|
|
Message #253454
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Paradox much part 2?
Hi Paul,
I suspect that you already know many of the answers to these questions, which makes me wonder if you're not setting me up for some kind of semantic trap :-)
Anyway, here are my two cents.
To me, Generics and OOP are orthogonal. Generics simply add a level of safety to any kind of code they are applied to. Admittedly, the code usually gets a bit harder to read in the process, but in my experience, this hurdle is usually overcome fairly rapidly and is dwarfed in the long run by the extra type safety that Generics add.
I recently had to "downgrade" some of my Generic code to the 1.4 syntax (for a GWT project. Yes, I know that GWT now supports Generics), and it was a very depressing experience to have to suppress all this very important information (List<Person> -> List) and add a bunch of casts in the process.
I don't really believe that Generics make runtime errors less likely because I think runtime errors related to types are already rare in the first place (I don't know about you, but I get NullPointerException a lot more often than ClassCastException), but I still consider Generics a huge step forward 1) in the way they formalize the contract between callers and callees and 2) how they make API documentation clearer.
I agree that the syntax and semantics can become very complex (and there are certainly quite a few code snippets that I still don't understand), especially if you start using captures and wildcards.
I have two recommendations for people who are skeptical of Java Generics:
1) Avoid using wildcards and captures at first. Stick to explicit types and just stay with the non-Generic version of your code whenever you find yourself having to use a wildcard. Once you get familiar with the syntax, you can decide whether you want to do the jump to the next level of complexity.
2) Don't be afraid to introduce intermediate classes to simplify your code (this is basically similar to using a typedef). For example, nesting Generics is usually a good indication that you might want to consider introducing such a class:
Compare:
(note: the TSS formatter messes up my angle brackets, so I'm using regular brackets instead. This should please Scala people :-))
Map[String, List[Person, Integer]] departments;
with
/**
* Maps a department name with all the employees and their employee number
*/
class Departments extends Map[String, List[Person, Integer]] {
}
Departments departments;
Finally, I challenge anyone who's saying that Java Generics are needlessly complex to show me semantically equivalent code in another language that supports Generics (probably one of Scala, C++ or C#, but feel free to pick more exotic languages) and then explain to everyone why that code is simpler. You'll probably find out that a vast majority of the readers will disagree with your assessment.
The point I'm trying to make here is that implementing an extensive Generic system in a modern language is extremely hard, and anyone who's focusing on using examples of complex Generic corner cases to blast the entire concept is missing the big picture.
--
Cedric
|
|
|
Message #253456
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Paradox much part 2?
I don't really believe that Generics make runtime errors less likely because I think runtime errors related to types are already rare in the first place (I don't know about you, but I get NullPointerException a lot more often than ClassCastException), but I still consider Generics a huge step forward 1) in the way they formalize the contract between callers and callees and 2) how they make API documentation clearer.
I feel the same.
And that's exactly why I like generics applied to Wicket's models but not components, since the purpose of the latter is entirely type safety, whereas applying it to models help you establish a clearer contract. Anyway, the rest of that discussion should be held on the Wicket list.
|
|
|
Message #253457
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: its not all more verbose it also saves.. but if sun did a fe
it can also save memory as you can avoid having to use member variables
... at the expense of creating an anonymous class. Not convinced it's a good compromise, memory-wise :-)
--
Cedric
Why not? Surely introducing an instance variable used in every instance is more expensive than introducing an extra class once.
You're right, because of the reference to the outer class and copies of any final variables it uses from that outer class. So it can easily be more expensive.
|
|
|
Message #253459
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: its not all more verbose it also saves.. but if sun did a fe
it can also save memory as you can avoid having to use member variables
... at the expense of creating an anonymous class. Not convinced it's a good compromise, memory-wise :-)
--
Cedric
Why not? Surely introducing an instance variable used in every instance is more expensive than introducing an extra class once.
You're right, because of the reference to the outer class and copies of any final variables it uses from that outer class. So it can easily be more expensive.
Though it's only the reference to outer that is really 'extra'. So it's the space of that reference vs the space of whatever variable you look to avoid.
|
|
|
Message #253460
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Paradox much part 2?
(note: the TSS formatter messes up my angle brackets, so I'm using regular brackets instead. This should please Scala people :-))
Map[String, List[Person, Integer]] departments;
with
/**
* Maps a department name with all the employees and their employee number
*/
class Departments extends Map[String, List[Person, Integer]] {
}
Departments departments;
In Scala you could just do:
type Departments = Map[String, List[Person, Integer]]
val departments: Departments
It's pretty much just like an old-fashioned typedef.
|
|
|
Message #253461
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Type erasure - much ado about nothing?
It was never about backwards compatibility. They allowed a niche concern called migration compatibility to dominate in the design of generics. Nothing stopped a generic-aware JVM with reified generics from being backwards compatible.
Type erasure only became nessecary because the initial nince constraint was never challenged.
Some complexity of Java generics comes from its attempt to provide variance support; but the incomprehensible parts can be traced directly back to type erasure.
Hello,
Maybe someone can help me understand because I don't see the issue regarding type erasure.
Believe it or not, the generic information is in your bytecode.
I wrote an application that had to extract method signatures from compiled classes at runtime. Using various bytecode engineering libraries (BCEL, ASM, etc.) I discovered this information is readily available to the programmer.
Consider the following example:
import java.util.List;
public class Test {
public void doSomething(List<Test> list) {
}
} When disassembled with javap, the class file produces the following output (emphasis added), clearly indicating the type parameter of the List:
Compiled from "Test.java"
public class Test extends java.lang.Object
SourceFile: "Test.java"
minor version: 0
major version: 49
Constant pool:
const #1 = class #2; // Test
const #2 = Asciz Test;
const #3 = class #4; // java/lang/Object
const #4 = Asciz java/lang/Object;
const #5 = Asciz <init>;
const #6 = Asciz ()V;
const #7 = Asciz Code;
const #8 = Method #3.#9; // java/lang/Object."<init>":()V
const #9 = NameAndType #5:#6;// "<init>":()V
const #10 = Asciz LineNumberTable;
const #11 = Asciz LocalVariableTable;
const #12 = Asciz this;
const #13 = Asciz LTest;;
const #14 = Asciz doSomething;
const #15 = Asciz (Ljava/util/List;)V;
const #16 = Asciz Signature;
const #17 = Asciz (Ljava/util/List<LTest;>;)V;
const #18 = Asciz list;
const #19 = Asciz Ljava/util/List;;
const #20 = Asciz LocalVariableTypeTable;
const #21 = Asciz Ljava/util/List<LTest;>;;
const #22 = Asciz SourceFile;
const #23 = Asciz Test.java;
{
public Test();
Code:
Stack=1, Locals=1, Args_size=1
0: aload_0
1: invokespecial #8; //Method java/lang/Object."<init>":()V
4: return
LineNumberTable:
line 3: 0
LocalVariableTable:
Start Length Slot Name Signature
0 5 0 this LTest;
public void doSomething(java.util.List);
Signature: length = 0x2
00 11
Code:
Stack=0, Locals=2, Args_size=2
0: return
LineNumberTable:
line 7: 0
LocalVariableTable:
Start Length Slot Name Signature
0 1 0 this LTest;
0 1 1 list Ljava/util/List;
LocalVariableTypeTable: length = 0xC
00 01 00 00 00 01 00 12 00 15 00 01
} What is the big fuss about type erasure? The information is there if you need it, and libraries provide APIs to access it when you do.
Ian
|
|
|
Message #253465
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Paradox much part 2?
Hi Cedric,
No I wasn't trying to set you up. I truly wanted to get your take on OO:
To me, Generics and OOP are orthogonal. Generics simply add a level of safety to any kind of code they are applied to. Admittedly, the code usually gets a bit harder to read in the process, but in my experience, this hurdle is usually overcome fairly rapidly and is dwarfed in the long run by the extra type safety that Generics add.
I understand this view, but I think it reveals a different understanding of what Object Orientated programming is all about, then the one I share.
I agree that generics in the simple cases do make the programmers intent more clear, but I'm not sure that it doesn't break encapsulation and hence is incompatible with OO principles.
The problem of complexity seems to come when you try to write frameworks and libraries that use generics. In such instances you hope to allow people to reuse your code in as yet unforeseen circumstances. With generics you fix the type of object you are expecting so:
List<String> getStuff()
Means that your library method can only return a collection of Strings. Yet in the future you may decide that the standard String implementation isn't what you want so you subclass it to String2
List <String2> getStuff()
So what happens to all your previous clients that used the old library? Well you'll get compilation errors I think. If you hadn't used generics and had used a cast your existing code would still be fine. So with generics you have introduced a dependency, unless you had the foresight to declare your original library like this:
List <? extends String> getStuff()
So to me it means that you need to be able to predict the future when using generics. Either that or not use generics in Libraries and frameworks unless you want to be ever tied to specific concrete implementations. To me String and String2 are both Strings and the client shouldn't care about the actual implementation. Generics expose the actual implementation in a way that breaks encapsulation in my opinion. This breaking of encapsulation also further restricts polymorphism, as the concrete implementation is fixed and cannot now be replaced by a subclass. This is contrary to the Liskov substitution principle which says that an object should be substitutable by any object which class is a subclass.
I could be wrong, and I'm interested in how others see this.
Paul.
|
|
|
Message #253466
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Type erasure - much ado about nothing?
I don't think it's that simple. Consider the following:
Foo<Bar> foo = new Foo<Bar>();
foo.doSomething();
Can you get the type of foo inside foo.doSomething()? I don't think so.
|
|
|
Message #253467
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Paradox much part 2?
Everything`s cool but String class is final and i dont think its gonna be unsealed in jdk7 ;)
|
|
|
Message #253468
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Paradox much part 2?
Everything`s cool but String class is final and i dont think its gonna be unsealed in jdk7 ;)
Well that settles it. So if I stick to using generics with final Classes everything will be just fine :)
|
|
|
Message #253477
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Type erasure - much ado about nothing?
Hi Ian,
Believe it or not, the generic information is in your bytecode.
You are correct, but this is a common misconception about type erasure.
You can access the static type that was associated in the declaration (with getGenericType()) but you can't access *runtime* information (what type is associated to the *object*, as opposed to what was declared in the class).
Hope this clears things up.
--
Cedric
|
|
|
Message #253478
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Paradox much part 2?
Hi Paul,
So to me it means that you need to be able to predict the future when using generics.
True, but I'm surprised you see this as a problem.
List<String> is very different from List<String2>, and forcing the author of the method to think about whether both of them are legal is a good thing, in my opinion.
Basically, the expertise needed to expose good API's has just been increased a notch with Generics. Fortunately, the number of API developers is dwarfed by the number of users, so in the long run, this should be of benefit to everyone.
--
Cedric
|
|
|
Message #253479
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Paradox much part 2?
Basically, the expertise needed to expose good API's has just been increased a notch with Generics. Fortunately, the number of API developers is dwarfed by the number of users, so in the long run, this should be of benefit to everyone.
I think that almost every non-trivial project has plenty of API development going on within. It's a shame that that got harder.
I've seen people argue that it was OK that e.g EJBs or JSF components are hard to write, because you should have specialists to do that, and on the longer term you'd just buy them as COTS components. :-)
|
|
|
Message #253480
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Type bounds
With generics you fix the type of object you are expecting so:
List<String> getStuff()
Means that your library method can only return a collection of Strings.
Means that your library returns a collection that can contain any subclass of String AND you can add any subclass of String.
Yet in the future you may decide that the standard String implementation isn't what you want so you subclass it to String2
List <String2> getStuff()
Means that your library returns a collection that can contain any subclass of String2 AND you can add any subclass of String2. So it can not contain String and you can not add String.
So with generics you have introduced a dependency, unless you had the foresight to declare your original library like this:
List <? extends String> getStuff()
Means that your library returns a collection that can contain any subclass of String. You can not add something, because the compiler can not know wether a list of Strings or a list of String2 is returned.
|
|
|
Message #253489
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Type bounds
Hi Thomas,
Thanks for clarifying. As you can tell I'm new to generics. What you say makes sense.
I was basing my example on what read here:
http://java.sun.com/j2se/1.5/pdf/generics-tutorial.pdf
I guess I interpreted things wrongly :) A better example of what I mean is on page 6:
public void drawAll(List<Shape> shapes)
This method will only draw shapes apparently, but not circles. To draw Circles you need to declare the method as:
public void drawAll(List<? extends Shape> shapes)
It seems to me that intuitively a Circle is a Shape. So this method should draw a collection of Circles too. So the second form is for the benefit of the compiler I guess :)
Confusing...
|
|
|
Message #253490
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Type bounds
Paul,
public void drawAll(List<Shape> shapes)
will also draw circles, as long as the Circle extends Shape and that it is kept in a List<Shape> collection.
It will not, however, accept a List<Circle> as parameter, even though this may seem logical. That's what
public void drawAll(List<? extends Shape> shapes)
is for.
|
|
