If you could get rid of one thing from Java... - Java SE (Archived)

If you could get rid of one thing from Java (http://weblogs.java.net/blog/johnm/archive/2004/08/if_you_could_ge.html), what would it be?

All deprecated classes/methods between JDK 1.0 through ... X where you guys decide what X should be.
Deprecated classes/methods that are left around for too long cause usability problems. There should be only one way to do any one thing in Java to avoid confusion. I'm not refering to "helper classes/methods". Those are fine. I'm talking about having a billion different image types and different ways to build images. The "new way" and the "old way". There should only be one way.

There should not only be one way to achieve something, particularly if there have previously been various ways.
But maybe some time the methods that were already deprecated in JDK 1.0 and 1.1 should be removed. This would make the JRE more efficient, wouldn't it?
Monika.

java.util.Date should have been immutable

Same for Point, Dimension and so on.

generics

;-) the one who agreed to disagree ;-)

> ;-) the one who agreed to disagree ;-)
I said disagree, not be quiet about it :)
And, you keep continuing to say.. this is great.. but it's broken...  It's like the two old guys in the resturant.... first one says... the food is horrible.. and the second say, yes, and the portions are small also!!!

oh no no no :-)
you do not want generics because you think it is a bad idea, you don't need them (or you think you don't). You do not even care about how the are implemented. In your case, it's just 'hate at first sight' :-)
As for me, on the other hand, I think generics are good idea, and I have whole bunch of resons for this claim, I only insist the need to be implemented differently.
There are many people who think they need generics, that they are best solution for [i]some[/i] of their problems. These people have sound reasons why they ask for generics.
If you do not belong to them, it does not mean generics are bad thing. You think you can live without them. Then live without them, don't use them. But don't force us to throw them away because of you.

Agree.

Well, is the only reason is JavaDoc, you are not fair.
You code can be completely free of generics so what is your problem?

Monitors as part of every object, rather than separate Lock objects.  Keep the synchronized statement, but require that it take Lock objects as arguments.  Lose the synchronized method flag.   Much more clarity, much better control, and 4 bytes less per object.  Sadly, it's way too late to make this change.

I think this depends on what you need. For many use cases the built-in mechanism is the best and managing extra Lock instance is overhead (at least maintenance overhead). For all other scenarios that require more flexibility, we are now lucky to have java.util.concurrent package.

> oh no no no :-)
>
> you do not want generics because you think it is a
> bad idea, you don't need them
Not only do I not need them... I don't really need typing but that said, I'm willing to live with it ;)
(or you think you
> don't). You do not even care about how the are
> implemented. In your case, it's just 'hate at first
> sight' :-)
Sorry, I don't really function that way. I look at a technology and try to make a determination on a cost benefit basis. For example, you won't see me putting the for syntax on the list even though I believe that the polymorphic way with closures is a far superior way of achiving the same effect. The fact is, the new for syntax encourages people to violate encapsulation and in doing so, violate DRY. But since people do this anyway (and heaven forbid we alter the language to prevent this fomr happening ;)) it's syntax is only mildly offensive.
In the case of generics, I have not seen where they help all that much.  I certianly can see where they've hindered (in cost of syntax and inconsistancies that they've introduced). Hence cost - benefit = loss IMHO. Until someone comes up to me and says... look this is something that you couldn't have done with generics.. the equation stays the same. Until someone comes up and says... look at the savings because of generics... same result... generics = loss. So far in several days of talking, all you've been able to do is spout the same old stuff that IMHO hasn't done anything to impress me for the last year.
The question here is, if there was one thing I could get rid of.... and since generics adds relativily little for the cost it imposes... generics gets the nod.  As Trump would say... generics.. your fired ;)
>
> There are many people who think they need generics,
> that they are best solution for [i]some[/i] of their
> problems. These people have sound reasons why they
> ask for generics.
I respectfully have not seen anyone put forth an arguement that was strong enough to warrent changing the language.
>
> If you do not belong to them, it does not mean
> generics are bad thing. You think you can live
> without them. Then live without them, don't use them.
> But don't force us to throw them away because of you.
I would argue that the onus of proof to change the language is on those that think they need generics. We should not have to define what is there. Unfortunately this premise that was in place has broken down and hence we are stuck with this hidous implementation.
Everything I've read and experienced say that less syntax helps make us productive. I don't feel the need to appologize for saying.. hey more syntax... not good! lets think about this!

Related

1.4.2 "wrapping" collections

Howdy,
I had a full on barny with my tech manager regarding "wrapping" a Map to provide "type safe" get and put (etc) methods. (We're stuck on 1.4.2)
He hates the concept on the grounds that "all that extra code (80 odd lines) for nothing" when you KNOWN that you're adding and getting the correct type, becuase YOU are doing it.
I'd like the compiler to tell me if I (or more likely the next numbnutt who plays with the code) add an object of inappropriate type to a collection... and it's worth 80 extra lines of code to me to get it.
Can anyone point me to "the definitive article" on the subject?
And how say you all?
Thanx. Keith.
Edited by: corlettk on Feb 28, 2008 9:59 AM - I need to go eat - I'll check this thread again in about half an hour. 
corlettk wrote:
He hates the concept on the grounds that "all that extra code (80 odd lines) for nothing" when you KNOWN that you're adding and getting the correct type, becuase YOU are doing it.This assumes that you never make mistakes. If he's serious about that bullshit, then he must also hate Java's strong typing, because YOU KNOW whether you want an int or a double or a String, so the compiler should never complain about type mismatches along those lines.
I'd like the compiler to tell me if I (or more likely the next numbnutt who plays with the code) add an object of inappropriate type to a collection... and it's worth 80 extra lines of code to me to get it.Typesafe collections are a godsend with generics. They're a pain in the ass wihtout. They're easy to implement--i.e., nothing particularly tricky--but they're tedious and error prone if you have to do it yourself.
Why, FFS, are you on 1.4?
Can anyone point me to "the definitive article" on the subject?Hmm.... I'd guess google for Josh Bloch and generics, but I'm not sure. 
Sorry but you will probably not find such an article since we managed to use "unsafe" collections for several years without any problems. It does however sound like good design if you take the extra time to write those wrappers (but I never did that, and I have been using Java since -96)
Kaj 
lorax,
I know I make mistakes, and I've found a few oopsies in the existing code-base by simply eyeballing the code (looking for other stuf), so I also know my colleges occassionally make the odd mistake.
I should mention the boss's second point on the matter was "If you unit test it properly then such bugs will NOT make it through to production." Fair cop that... except it still leaves the door open for bad/incomplete testing... and no-ones ever been guilty of that, especially when they're under the hammer to punch out a production patch pronto, and never mind the bollocks.
They [type-safe collections] are easy to implement.. ie
nothing particularly tricky... but they're tedious and
error prone if you have to do it yourself.Hmmm... Yeah I suppose it's tedious, but because it's so simple it's relatively quick... I've been doing them by copy & paste and search & replace. I think I'll write a code generator for it... it'd be simple enough.
Why error prone? I don't see that? It might be more code but it's simple code... I'd expect my co-ops to punch one out in hour, tested... which makes the code-gen less valuable... they need the practice ;-)
Why, FFS, are you on 1.4?Because we're stuck on Weblogic 8.1 until mid 2009, when 8.1 goes end of life... then we upgrade ALL our sytems (h/w, o/s, server, jdk) to weblogic 10 and off we go for another 4 (or 5) years. Not the incremental change for us. It's all for one and one for all, and I personally think they're nuts... we loose a few good techies every time they do "the big technology upgrade". I just tell them "Yep, we're over time and over budget again, and if you don't like it then fire me". They haven't fired me yet.
Josh Bloch and genericshttp://java.sun.com/features/2003/05/bloch_qa.html is a succinct "show case" of the advantages of 1.5's generics, autoboxing, enhanced for-loops, etc... an interesting read... but it's not really on the money. I also had poke around mindprod and came up with this...
mindprod on Java Casts: (sarcasm befits him)
Java?s casting scheme is a gift from the Gods.
You can use it without guilt since the language
requires it. Every time you retrieve an object from a
Collection you must cast it back to its original type.
Thus the type of the variable may be specified in
dozens of places. If the type later changes, all the
casts must be changed to match. The compiler may
or may not detect if the hapless maintenance
programmer fails to catch them all (or changes one too
many).javaranch has (suprise surprise) got diddly... likewise dev2dev.
Thanx for your reply. Cheers. Keith. 
we managed to use "unsafe" collections for several years without any problems.Well when I was lad there where 13 of us living in shoe box on bottom of septic tank! We had to get up half an hour beofre we went to bed... http://www.phespirit.info/montypython/four_yorkshiremen.htm
Still doesn't make it a good idea though does it? ;-)
Keith. 
Can you use Retroweaver?
http://retroweaver.sourceforge.net/ 
corlettk wrote:
lorax,
I know I make mistakes, and I've found a few oopsies in the existing code-base by simply eyeballing the code (looking for other stuf), so I also know my colleges occassionally make the odd mistake.
I should mention the boss's second point on the matter was "If you unit test it properly then such bugs will NOT make it through to production." Fair cop that... except it still leaves the door open for bad/incomplete testing... and no-ones ever been guilty of that, especially when they're under the hammer to punch out a production patch pronto, and never mind the bollocks.Again, that attitude assumes that you're writing perfect unit tests. This guy really seems to have a bit of a blinkered view. Maybe it's time you reminded him that he's a manager, not a techie, and as such shouldn't be worrying himself with details like this. Ask him why he's fighting his developers so hard to make their code less robust. Also, if he trusts you to NOT pass the wrong types in and out of collections, and trusts you to write comprehensive enough unit tests, why can't he trust you to make this judgement call? 
Still doesn't make it a good idea though does it? ;-)I never said that it's better do use untyped collections, but it will be very hard to convince someone that something that used to work doesn't work any longer. Remember that there are lots and lots of Java systems in production without any problems (related to untyped collections). It should be very easy to know what you have in your collections if you have small classes that don't expose their internals.
Kaj
Ps. I'm not against generics and I use it when I can, but I wouldn't put in the extra effort to write those wrappers if I were using 1.4 
Kaj,
Sorry if I sounded snippish. I didn't mean to. I'm not disagreeing with you.
Ps. I'm not against generics and I use it when I can, but I wouldn't put in the
extra effort to write those wrappers if I were using 1.4I take your point. I'm starting to flip-flop.
Thanx. Keith. 
he's a managerYes, and (I should have said earlier) a bluddy good techie.
Again, that attitude assumes that you're writing perfect unit tests.He's a fan of less code, more test cases/ I'm a fan of using the compiler to verify everything that the compiler can verify... I started out in scripting languages, with on-the-fly variable declaration... so I really see the benifits of compile time checking, and I want to make it work for me. 
mlk,
I'll take a quick look at Retroweaver.
Thank you. Keith. 
I'm a whimp... I'm not even going to suggest Retroweaver... Not because I don't expect it will work, but just because if I suggest it, and it gets implemented, and it doesn't work my #ss will be cactus.
http://retroweaver.sourceforge.net/guide/retroweaver-guide.pdf (old version doco)
Looks good though, thanx again. Keith. 
corlettk wrote:
he's a managerYes, and (I should have said earlier) a bluddy good techie.I don't doubt it. But he's a manager now, his role now isn't really to argue about things like this, if you ask me. He should be trusting you to make these judgement calls
Again, that attitude assumes that you're writing perfect unit tests.He's a fan of less code, more test cases/ I'm a fan of using the compiler to verify everything that the compiler can verify... I started out in scripting languages, with on-the-fly variable declaration... so I really see the benifits of compile time checking, and I want to make it work for me.Well, why rely on unit tests to do things when - as you say - you can rely on the compiler to do it? I'm not convinced what you're doing is really necessary, since you're hopefully encapsulating access to these collections anyway. But it's up to you, it's not exactly wasteful, and if it makes you more comfortable, go ahead. I don't really see why a manager would want to make such a big deal out of something so trivial. 
Access to the collections isn't exactly encapsulated, no.
It wasn't our design... these classes where inherited from a prototype written by a guy with PHD in "geospatial stuff" who had no formal education in programming
They're not bad... they're just not good.
I don't really see why a manager would want to make such a big deal out of something so trivial.Yep... I'm starting to think the boss is more about "you can't do differently to me or that makes me wrong." ... I can see all the arguments and they're valid. I just personally PREFER to do things the "paranoid" way. That doesn't make anyone wrong. It's just a personal preference.
I shall, having calmed myself... go discuss it again tomorrow.
Cheers mate. Keith. 
corlettk wrote:
Access to the collections isn't exactly encapsulated, no. That changes everything. :)

Generics?

Hi, I just recently learned about Generics in Java. I couldn't quite get the point of them, and me professor couldn't really give a solid answer. Correct me if I'm wrong, but it seems that generics simply make certain runtime errors show up as compiler errors.
We are just introducing something in the code to catch our errors. The more code that is introduced, the easier it is to make errors. We are increasing the chance of making an error simply to ease the process of finding others. This seems somewhat nonsensical to me. Where is the flaw in my logic? 
Correct me if I'm wrong, but it seems that generics simply make certain runtime errors show up as compiler errors.That's about right.
Where is the flaw in my logic?The new errors we might introduce are easier to find than the ones they replace, because the compiler will point them out. 
Hi, I just recently learned about Generics in Java. I
couldn't quite get the point of them, and me
professor couldn't really give a solid answer.
Correct me if I'm wrong, but it seems that generics
simply make certain runtime errors show up as
compiler errors. Yes. And this is a good thing.
You want to catch errors at build time, rather than once your app is out there running.
We are increasing
the chance of making an error simply to ease the
process of finding others.That's a valid argument. Generics are complicated, and in practice, I've rarely if ever come across the kind of error they're designed to prevent. I'm not sure whether I consider them worth it.
The big trump card generics have is that they move runtime errors to compile time errors, and that can make up for a lot of downside. On the whole is it a positive? I don't know. I think that's largely a situational and subjective call. 
Hi, I just recently learned about Generics in Java. I
couldn't quite get the point of them, and me
professor couldn't really give a solid answer.
Correct me if I'm wrong, but it seems that generics
simply make certain runtime errors show up as
compiler errors.
We are just introducing something in the code to
catch our errors. The more code that is introduced,
the easier it is to make errors. We are increasing
the chance of making an error simply to ease the
process of finding others. This seems somewhat
nonsensical to me. Where is the flaw in my logic?On top of what the previous two posters have said, which I agree with almost entirely, generics does do more than move runtime errors to compile time. They make your code more readable and understandable for future developers in addition to preventing them from introducing bugs. Generics make code more robust and flexible, not locknig you into a specific type. Overall you'll actually write less code, not more code, with generics because of all the casting and checks that are no longer necessary. Plus, because generics are more or less self-documenting you eliminate documentation that would have been necessary as well, regardless of whether or not that documentation was included. 
That's a valid argument. Generics are complicated,
and in practice, I've rarely if ever come across the
kind of error they're designed to prevent. I'm not
sure whether I consider them worth it.I would agree that it's a valid concern, but I'm not sure I would call it an argument against generics. Like anything, generics should be used when appropriate. Whether or not generics will simplify and aid development in a particular class is a concern to be weighted against whether or not it's appropriate to use generics in that case. I don't see it as an argument against generics on the whole.
I've rarely come across a ClassCastException, but I have come across many bugs related to programmers expecting one thing and getting another in terms of type. Generics would hae prevented those, but generics offers more than this so even if you did not see these errors a lot it has other values that should be considered. 
more than move runtime errors to compile time. They
make your code more readable and understandable for
future developers I'm not sure I totally agree. I do like to see spelled out clearly that this is a List of Foo, so in the simple case, yeah, they provide additional valuable information at a glance.
But it seems really easy to for things to get fugly fast with <List <Foo super ? <Bar extends Baz>>> or whatever.
I'm not using 1.5 for real yet, so I'm not in a position to comment on how things settle out overall.
I do like them in general, and I do plan on using them. It's just that I'm not convinced that they add as much value as they do complexity. Not saying they don't, just that it could probably be reasonably argued that they don't.
Overall you'll actually write less code, not moreAgain, I'll reserve judgement on that until I've used generics enough for real to make firsthand observations.
checks that are no longer necessary. Plus, because
generics are more or less self-documenting you
eliminate documentation that would have been
necessary as well, regardless of whether or not that
documentation was included.This I agree with in theory, but I have to admit, when I see all the <E> and <T> etc. in the javadocs, it's like a major speed bump to my reading. That may just be a matter of getting used to it, so again, I'll temper this by saying I don't use them enough yet to form valid opinions. My initial reactions are mixed, is all. 
I'm not sure I totally agree. I do like to see
spelled out clearly that this is a List of Foo, so in
the simple case, yeah, they provide additional
valuable information at a glance.
But it seems really easy to for things to get fugly
fast with <List <Foo super ? <Bar extends Baz>>> or
whatever.There may be two sides to this too, using generified classes versus writing them. If you go and look at something like the generified Collection interface it can be daunting. Using it on the other hand is fairly simple and straightforward.
I'm not using 1.5 for real yet, so I'm not in a
position to comment on how things settle out
overall.
I do like them in general, and I do plan on using
them. It's just that I'm not convinced that they add
as much value as they do complexity. Not saying they
don't, just that it could probably be reasonably
argued that they don't.In some cases they don't add as much value as they do complexity. I've written clever little generified classes only to realize it was overly complex and convoluted without any substantial benefit more than once, at which point I prompty changed them to be non-generic. That's why I would refer to it as a concern, since it's a case by case issue I believe.
This I agree with in theory, but I have to admit,
when I see all the <E> and <T> etc. in the javadocs,
it's like a major speed bump to my reading. That may
just be a matter of getting used to it, so again,
I'll temper this by saying I don't use them enough
yet to form valid opinions. My initial reactions are
mixed, is all.I think in most cases it's not a speed bump at all. There are certainly cases where it can get very convoluted and hard to discern, but that's the exception rather than the rule. Generics are pretty easy to grasp once you sit down and read up on them for a couple hours. Then it's not much different than seeing "Object" or "String", it's just another tool in the toolbox, but until you know what that tool is it's confusing.
This is not meant to contradict, but to give my experience as I felt very much the same way before I decided to delve into it. 
Run-time errors or compile-time errors, which is better?
Nothing to do with generics, but I have recently been writing a web application with servlets and JSPs (using JSTL). If I get a method name wrong in a servlet it's a compile-time error, but if I get it wrong in JSTL it's a run-time error. The compile-time error is much more helpful. The run-time error is much more tedious to fix. I'm not sure why some people think that scripting languages are faster to develop in than strongly-typed languages, but they do seem to think that.
However I never got class cast exceptions with my collections before Java 5, so generics (neat as they are) really don't solve a problem that I had. 
I'm not sure why some
people think that scripting languages are faster to
develop in than strongly-typed languagesProbably in a lot of cases, for small to medium sized apps, they're faster to learn enough of to produce something, and to get something out the door that more or less works.
Then maintenance and enhancement come, and by that time the people who know nothing but the spaghetti-wad app they wrote and the language they scripted it in conclude that that's just the way programming is, and they should get beaucoup bucks because they're the big swingin' d1ck studs who created that--complexity being a sign of intelligence and manly endowment after all. 
Probably in a lot of cases, for small to medium sized
apps, they're faster to learn enough of to produce
something, and to get something out the door that
more or less works.
Then maintenance and enhancement come, and by that
time the people who know nothing but the
spaghetti-wad app they wrote and the language they
scripted it in conclude that that's just the way
programming is, and they should get beaucoup bucks
because they're the big swingin' d1ck studs who
created that--complexity being a sign of intelligence
and manly endowment after all.Chicks dig short methods, it's the wave of the future. Objects with only one responsibility also turns them on. Maybe that only works when your girlfriend is a programmer. 
However I never got class cast exceptions with my collections before Java 5, so generics (neat as
they are) really don't solve a problem that I had.The first commercial maintenance work I did didn't throw ClassCastExceptions, but I did sometimes have to spent a long time tracking down what was supposed to be in a list. (Well-used) generics would have helped me there. 
Thanks for all the input everyone!

Must we uses generics always

Hi,
We are using eclipse as a tool with java 1.5 development.
But the tool issues warning for the below code.
ArrayList list = new ArrayList();The problem is it is expecting
ArrayList[u]<E>[/u]  list = new ArrayList();Is it wrong to ignore using the "Generics".
Or does it in anyway make the code non-compliant with 1.5.
I dont feel the need to use Generics,
so cant i ignore it ?
Any thoughts on this matter are appreciated.
Regards,
Shailesh 
Yes, you can ignore it. 
I dont feel the need to use Generics, Why not? You like making your life harder? And your code more error prone? 
I dont feel the need to use Generics, Why not? You like making your life harder? And your
code more error prone?Meh. You kids these days. Back when I was coming up, we didn't have none of these fancy generics. We had to know what we was putting into our collections, and if we put in or tried to take out the wrong type, they killed us. And then they ate us. And then they made us start over from the beginning. And we were grateful. 
Pah! Collections? Types? Everything is an 8 bits wide byte and fits into one of three registers: the accumulator or the X or Y registers. That's it. God help you if you want to multiply or divide anything... 
Is this the Java Kindergarden?
Of course, one can use Java the raw fashion. Generics "only" provide some compile-time type safety in many situations, but not all of them. Often enough, you will work with bound types or even wildcards, which not helps much.
It surely is possible to safely develop applications with less or no types (e.g. dynamic typing, cf. Ruby, Smalltalk, Python etc.). It all depends on who will write the code, who will maintain the code, and how experienced the developers are.
Comparisons to assembler or register manipulations are quite off. Types alone do not guarantee a stable or maintainable application. 
Thank you for all your replies.
Let me rephrase one of the questions in the original message.
"If i do not use generics does the code become non 1.5 complient?"
As an additional info
javac only gives a "note" when you compile, but it gives a warning with -Xlint option. 
"If i do not use generics does the code become non
1.5 complient?"No, it does not. 
Is this the Java Kindergarden?In my experience, mostly yes.
Of course, one can use Java the raw fashion. The fact that you can doesn't make it a good idea. Generics are one of the most beneficial new feature in Java.
Generics
"only" provide some compile-time type safety in many
situations, but not all of them. Often enough, you
will work with bound types or even wildcards, which
not helps much.In most cases compile-time is the best time to be as safe as possible.
It surely is possible to safely develop applications
with less or no types (e.g. dynamic typing, cf. Ruby,
Smalltalk, Python etc.).Of course it is, it's also easier to make mistakes which burn you at runtime.
It all depends on who will
write the code, who will maintain the code, and how
experienced the developers are.In which case I find it best to assume the worst.
Comparisons to assembler or register manipulations
are quite off. Types alone do not guarantee a stable
or maintainable application.But they do help. 
Comparisons to assembler or register manipulations
are quite off. Types alone do not guarantee astable
or maintainable application.But they do help.But that wasn't the question. It's one thing to advice using Generics (as I always would) and another to imply the OP being an idiot for not using them, as it's similar to going back to stone age in programming. 
"If i do not use generics does the code become non
1.5 complient?"Depends on your definition of "1.5 compliant." 
But that wasn't the question. It's one thing to
advice using Generics (as I always would) and another
to imply the OP being an idiot for not using them, as
it's similar to going back to stone age in
programming.I don't believe I did. 
But that wasn't the question. It's one thing to
advice using Generics (as I always would) and another
to imply the OP being an idiot for not using them, as
it's similar to going back to stone age in
programming.Who did that then? I was having a laugh at jverd, jverd was having a laugh at dwg and dwg's comment was perfectly valid and reasonable.

Does Java really need closures?

Hi, I read some blogs about the new feature which is going to be added to Java 7, called "closures".
What do you think about that? Or perhaps about these "new features" in the Java language syntax? I personally think it would be much better to keep Java as simple as possible and prevent it from being a mess like C++.
I don't really know whether closures is worth to be added or not. Please comment on this. 
Part of me really likes the idea, but I'm with you on the "keep it simple" thing. We've already got people who know Java 5 and it's features, and people who don't, do we really want 3 very different forms of the language?
You can get closure-ish behaviour using anonymous inner classes anyway 
That's right, I completely agree. 3 different forms of the language is very confusing for newcomers. IMHO, having a simple syntax and insignificant less possibilities in coding is much better than having a complex and big syntax with lots of features which are not so useful.
As an example, operator overloading is a great feature but ruins the simplicity, and brings no more "power". So it's better to omit it. 
no, there's no need for it whatsoever. It's simply something a few kiddos (which is a state of mind, not an indication of age per se) want "because Ruby has it", just like they want operator overloading "because C++ has it" and "properties" "because C# has it".
In their mindset anything another language (and especially a hyped one like Ruby) has that Java doesn't indicates that "Java is dead" unless and until that feature is introduced into Java as well.
They may come up with highly elaborate scenarious how in some narrow niche case it could be helpful, but never are able to show the general usefulness or how it would be an improvement for the majority of people over the way things are handled now (remember that Java already is a complete general purpose language, it doesn't need new things to enable it to do any of the things closures or any of the other "proposed" "improvements" supposedly allow). 
I'm just amazed why some people like James Gosling gave the basic ideas to add "closures" to Dolphin release.
I read another couple of blogs yesterday which they were talking about "Cleaning up Swing listener syntaxes" or "Getting Swing runnables clean". I did not find anything in those areas unclean.
Adding closures also needs lots of code rewriting. Is there somebody who can explain why it is being done? A general and reasonable argument, not a very specific case as jwenting said. 
I'm just amazed why some people like James Gosling
gave the basic ideas to add "closures" to Dolphin
release.
I read another couple of blogs yesterday which they
were talking about "Cleaning up Swing listener
syntaxes" or "Getting Swing runnables clean". I did
not find anything in those areas unclean.
Adding closures also needs lots of code rewriting. Why? Existing code works just fine without them, no reason why it would suddenly stop working is there??
Is
there somebody who can explain why it is being done?
A general and reasonable argument, not a very
specific case as jwenting said.I think JW's reasoning was quite general. That sort of pressure is probably enough on it's own to push a committee in a certain direction 
Why? Existing code works just fine without them, no
reason why it would suddenly stop working is there??I don't know why. I agree with you, but they want to do this. Specially with Swing/AWT listeners. As I said, I think there's no need for closures at all.
I think JW's reasoning was quite general. That sort
of pressure is probably enough on it's own to push a
committee in a certain directionI didn't express clearly. I meant: Give us a general and reasonable argument. As JW said, do not discuss very specific cases. 
Adding closures also needs lots of code rewriting.Why? Existing code works just fine without them, no
reason why it would suddenly stop working is there??At least some of the proposals would break the existing language syntax and classfile format, meaning a complete loss of backwards compatibility with existing code and binaries both.
Is
there somebody who can explain why it is beingdone?
A general and reasonable argument, not a very
specific case as jwenting said.I think JW's reasoning was quite general. That sort
of pressure is probably enough on it's own to push a
committee in a certain directionAs has been shown in the recent past. Including a webserver and database server in the core distribution? That was done solely to please the ".NET has it, i wan it 2" crowd. 
I really want closures in the language. I just love them :) 
Adding closures also needs lots of coderewriting.
Why? Existing code works just fine without them,no
reason why it would suddenly stop working isthere??
>
At least some of the proposals would break the
existing language syntax and classfile format,
meaning a complete loss of backwards compatibility
with existing code and binaries both.Really? Again? Silly boys!
Is
there somebody who can explain why it is beingdone?
A general and reasonable argument, not a very
specific case as jwenting said.I think JW's reasoning was quite general. Thatsort
of pressure is probably enough on it's own to pusha
committee in a certain directionAs has been shown in the recent past. Including a
webserver and database server in the core
distribution? That was done solely to please the
".NET has it, i wan it 2" crowd.Argh! Go use .NET then, kids! Will they not be happy until every friggin' language is identical? 
> I really want closures in the language. I just love them :)
There's always Groovy...
1.upto(5) { print it + ' ' } // 1 2 3 4 5 :o)
~ 
I really want closures in the language. I just love
them :)Please have a look at the first three posts and answer my questions. That will be highly appreciated. 
> Please have a look at the first three posts and
answer my questions.
If you want Groovy, it's out there. :o)
~ 
Slow down, you move too fast.
You got to make the morning last.
Just kicking down the cobble stones.
Looking for fun and feelin' groovy.
Hello lamppost,
What cha knowing?
I've come to watch your flowers growing.
Ain't cha got no rhymes for me?
Doot-in' doo-doo,
Feelin' groovy.
Got no deeds to do,
No promises to keep.
I'm dappled and drowsy and ready to sleep.
Let the morning time drop all its petals on me.
Life, I love you,
All is groovy. 
Very good example yawmark. It simply shows how "closures" and something alike can ruin the simplicity and code readability.

Java 'Pet Hates'

Prompted by this thread ( http://forum.java.sun.com/thread.jspa?threadID=784333&tstart=0 ), in no particular order, my 'Pet Hates' -
1)System.getProperty(�line.separator�) - the use of which is often recommended as solving all the worlds eol problems. Since I work on many different platforms transferring files between them it actually does very little for me.
2)�String.getBytes()� and it's inverse �new String(bytes)� - two of the most dangerous methods (OK new String() is not a method but ...) in Java and it would be much much better if they were not available. One only has to follow these forums and see how many people get into trouble by blindly using these without thinking about the possible portability problems when running a program on different computers (never mind different operating system).
3)Being able to declare an array using �byte fred[]�. I always use �byte[] fred� since I find this a much more intuitive.
4)�goto� being a reserved word. I can't see the point of making �goto� a reserved word because I would hate Java if it introduced �goto� as an operation.
5)EJB � most particularly 'bean managed persistence' . I have never worked on a database where the flat model implied by 'bean managed persistence' applies. I could be out date with 'bean managed persistence' since it is over 4 years since I used it in anger and then only with WebSphere 3.5 and 4.0.
6) WebSphere 3.5 and 4.0 .
Please feel free to shoot me down and/or add to the list. 
I agree with any of them, 'though I don't dislike 1) and 4) as much as I do 2) for example.
Regarding 2.) I'd like to add FileReader which basically promotes the same problem and new String(String) which is a different "problem" but is used a lot by people who don't know about it. 
1) Autoboxing and Rene's Rubber Chicken Voodoo.
2) The classpath. Necessary but annoying.
3) No package-private interface methods.
I guess there's some more stuff I don't like that I'll only remember when I have to use it again. Suppression is a Good Thing™.
® 
Regarding 2.) I'd like to add FileReader whichAgreed!
basically promotes the same problem and new
String(String) which is a different "problem" but is
used a lot by people who don't know about it.I only partially agree with this since, other than use memory, it does no real harm. 
1) Autoboxing and Rene's Rubber Chicken Voodoo.I like autoboxing but I have never heard of "Rene's Rubber Chicken Voodoo".
>
2) The classpath. Necessary but annoying.Good one but I really only hate $CLASSPATH (or %CLASSPATH%).
>
3) No package-private interface methods.I need to think about this one.
>
I guess there's some more stuff I don't like that
I'll only remember when I have to use it again.
Suppression is a Good Thing�.
�:-) 
basically promotes the same problem and new
String(String) which is a different "problem" butis
used a lot by people who don't know about it.I only partially agree with this since, other than
use memory, it does no real harm.Not at runtime, true, but at code-review-time it can definitely hurt those who wrote that code. And at code-maintainance time it hurts my mind.
My problem with that construct isn't even about wasting memory (there are far better ways to achieve that), but that it shows how little the coder knows about Java. 
I only partially agree with this since, other than
use memory, it does no real harm.Not at runtime, true, but at code-review-time it can
definitely hurt those who wrote that code. I'm a great believer in code reviews since my experience is that one finds more bugs during a code review than during testing. Unfortunately, in my last 3 years of contacting I never once was able to manage to introduce formal code reviews (other than checking code meets the cosmetic coding standards). The reason given by management was normally that �testing will find the bugs�.
And at
code-maintainance time it hurts my mind.I just smile, take note of the name of the coder, and move on.
>
My problem with that construct isn't even about
wasting memory (there are far better ways to achieve
that), but that it shows how little the coder knows
about Java.Yes. I have seen this in live code and it makes me double check everthing done by that particular coder. 
I like autoboxing but I have never heard of "Rene's
Rubber Chicken Voodoo".http://forum.java.sun.com/thread.jspa?forumID=425&threadID=661520 - Reply 18
While this is simply malevolence and black magic, autoboxing can also lead to unxeplainable NPEs in ternary operators when they do type promotion on a null return value. 
1) Hardly the fault of Java, not can I see how Java could have solved it.
2) Occasionally you need to do this. With the benefit of hindsight it would have been better to make you use Charset methods, but then the offending methods pre-date the big Internationalization drive and you can't remove them now.
3) Neve seen it done
4) Yes, a tad cowardly but its hard to imagine using goto as a variable name.
5) I've never had the misfortune to be required to use EJB-2, but my reaction was it was very badly thought out, and overkill for 99.99% of projects. I think EJB-3 is better.
6) Websphere isn't Java's fault.
My own pet hates:
a) java.sql.Date
b) Blob/Clob handling
c) Over-eager name completion in IDEs.
d) Exceptions that are checked, and shouldn't be e.g. UnsupportedEncodingException. 
regarding new String(), http://findbugs.sourceforge.net/ will highlight use of this construct, amongst many many many other common mistakes, sources of bugs, convoluted conditional logic, overly-large methods and classes etc. basically an automated code review, and it integrates very nicely with cruise control et al 
a) java.sql.DateAt least a c'tor java.sqlDate(java.util.Date d) would be nice.
d) Exceptions that are checked, and shouldn't be e.g.
UnsupportedEncodingException.Yeah. 
regarding new String(),
http://findbugs.sourceforge.net/ will highlight use
of this construct, amongst many many many
other common mistakes, sources of bugs, convoluted
conditional logic, overly-large methods and classes
etc. basically an automated code review, and it
integrates very nicely with cruise control et alIn some equals() implementation, I use == to compare a String-type attribute, to both deal with null and identic elements. Afterwards I do an equals() on the String nevertheless, but it saves me one check for null.
Due to our code review rules, that == is a no-go, red alert, highly-critical violation. At least our code reviewers seem clever enough to recognize that and not submit a CR to me. 
ACKs to all the posts above. I'd add generics and static imports to the list of evil things introduced by Java5.
Here's my addon:
a) java.util.Date; mutable and almost unusable due to deprecation while Calendar lacks simple construction methods.
b) The JAI; never seen a library less understandable and worse documented
d) Exceptions that are checked, and shouldn't be e.g. UnsupportedEncodingException.Really, really, really annoying.
c) Calendar.JANUARY == 0 
I like autoboxing but I have never heard of"Rene's
Rubber Chicken Voodoo".http://forum.java.sun.com/thread.jspa?forumID=425&thre
adID=661520 - Reply 18Another one I need to study! 
some of my pet hates
1) lack of a 'Money' class. virtually every enterprise application contains a proprietary Money class in it, why can't the standard libraries include one, or at least the supposed "enterprise" edition
2) Date - wtf??
3) generics not existing at runtime - I know why they don't, but still....
4) lack of a 'method' equivalent of 'class'. if we can query a class for it's Class object without reflection, why can't we do the same for Method?
5) the fact that there are so many different types of type. primitives, reference, array, now enum. all need specialized handling in reflective code. why??
6) no command-line interpreter. in order to do anything, I need to write a class, compile it and run it. shorter feedback loop would be nice

Categories

Resources