This week's book giveaway is in the Kotlin forum.
We're giving away four copies of Kotlin in Action and have Dmitry Jemerov & Svetlana Isakova on-line!
See this thread for details.
Win a copy of Kotlin in Action this week in the Kotlin forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

The Good; The Bad and The Ugly of Java 5  RSS feed

 
Anselm Paulinus
Ranch Hand
Posts: 390
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi K&B:

There has been a lot of noise about the new features of Java 5. What in your opinion are the caveats of java 5.
 
Bert Bates
author
Sheriff
Posts: 8945
17
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Boy this one could get sticky

I'll try to get Kathy to share her opinions also...

IMHO generics verge on being more trouble than they're worth. I'm not saying that I know how they should have been implemented, but it sure seems to me they can get awfully complicated for what they offer.

I like enums, the new "for", StringBuilder seems like a nice idea, varargs seem ok. Boxing seems to be mostly good, with a few gotchas like you can't unbox and widen at the same time. Annotations could be good but I'm afraid they will be misused and all hell will break loose :roll: Static imports seem handy, the new formatting seems handy... Frankly I haven't studied most of the new threading features, so I'm on thinner ice than usual, but it seems like very specialized stuff.

(Why do I have a feeling I've just stepped in it? )

- Bert
 
Nicholas Cheung
Ranch Hand
Posts: 4982
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Bert,

Some features are not that good, like static import, would you recommend those non-good features to be taken out at JDK 1.6?

Also, any features that you think they are good but still they are not in Tiger?

Nick
 
Jeroen Wenting
Ranch Hand
Posts: 5093
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'd like to see a LOT of the dead wood cut out of Java in 1.6, but I fear it will instead add a lot of completely useless crap.
Just follow the forums on java.net and the constant screaming demands for silly new keywords and operators (not to mention complete new classlibraries because someone doesn't like the way some default class works).

Reading that I feel inclined to abandon Java and go back to a simple language like C++...
 
Jeroen Wenting
Ranch Hand
Posts: 5093
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
As to the new features in Tiger, I mostly agree with Bert.
Generics are extremely powerful and have their use, but the implementation seems overly complex (not that I know how it could have been done simpler without loosing backwards compatibility).

Annotations are bad news, they just ask to be heavily abused to provide compile time code generation from comments, something that's a big nono. All they do IMO is obfuscate source to the point of illegibility.

Static imports similar. Import a single field from a class with the same name as another class you also import and see the confusion mount.
 
Nicholas Cheung
Ranch Hand
Posts: 4982
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In general, I only like the invitation of Generics. Other features seem not that useful, but introduce new problems.

Nick
 
Anselm Paulinus
Ranch Hand
Posts: 390
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Personally; I feel that simple generics would have been alright but as it is right now it is going to get overly complicated, boxing and unboxing would do more harm than good to beginners. static imports - do not really see the need; Annotations, hmm - do not see its value per se, have to re-read that baby.
 
Joel McNary
Bartender
Posts: 1840
Eclipse IDE Java Ruby
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think that Generics are good; they provide a lot more power then simply typing collections (one of the least useful reasons for generics that I see). I think that Generics make the Factory design pattern much more straightforward.

I like Autoboxing (although I would have been happy if Java had no primitives in the first place, and that code like:

was how Java did it.)

The new syntax for for is nice.

Other features I see as mere clutter.
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Joel McNary:
I like Autoboxing (although I would have been happy if Java had no primitives in the first place, and that code like:

was how Java did it.)


I *so* agree! Also no more need for java.lang.Math

System.out.println(2.sqrt());





Other features I see as mere clutter.


Please say that you simply forgot enum. I really love it! (In fact, I'm currently working in 1.4, and therefore have to write a lot of boiler plate code for the Typesafe Enum pattern...)
 
Anselm Paulinus
Ranch Hand
Posts: 390
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I so agree with you guys and that would have automatically eliminated one of the clutters known as autoboxing.
 
Anselm Paulinus
Ranch Hand
Posts: 390
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Bert Bates:
Boy this one could get sticky

I like enums, the new "for", StringBuilder seems like a nice idea, varargs seem ok. Boxing seems to be mostly good, with a few gotchas like you can't unbox and widen at the same time. Annotations could be good but I'm afraid they will be misused and all hell will break loose :roll: Static imports seem handy, the new formatting seems handy... Frankly I haven't studied most of the new threading features, so I'm on thinner ice than usual, but it seems like very specialized stuff.

(Why do I have a feeling I've just stepped in it? )

- Bert



Bert this topic was more about the bad and ugly sides of Java 5. Not really about the good; you seemed to have pointed so much about the good than the ugly sides of the new features.
 
Bert Bates
author
Sheriff
Posts: 8945
17
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Anselm -

Ok, I'll simplify... I'm not too fond of annotations or generics
 
Jeroen Wenting
Ranch Hand
Posts: 5093
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In fact, this would not exist if Java had no primitives.
You'd perforce have something like


Not exactly pleasing to the eye.
 
Pradeep bhatt
Ranch Hand
Posts: 8933
Firefox Browser Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Some features are not that good, like static import, would you recommend those non-good features to be taken out at JDK 1.6?


I dont think that anything will removed from java 5 when newer version comes up.
 
Pradeep bhatt
Ranch Hand
Posts: 8933
Firefox Browser Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Bert Bates:
Hi Anselm -

Ok, I'll simplify... I'm not too fond of annotations or generics


If you guys are following the www.theserverside.com, you might have read an article when the writer plans to use annotations for validation purpose. Another one talks about eliminating getter/setter methods.
 
Nicholas Cheung
Ranch Hand
Posts: 4982
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

I dont think that anything will removed from java 5 when newer version comes up.




Would such things being marked deprecated even if it is not being removed?

Nick
 
Pradeep bhatt
Ranch Hand
Posts: 8933
Firefox Browser Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Nicholas Cheung:




Would such things being marked deprecated even if it is not being removed?

Nick



I havent seen any language feature being deprecated. Do you know any? API are the one which are deprecated.
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Jeroen Wenting:
In fact, this would not exist if Java had no primitives.


Why not? After all you can also write

String aString = "my String".substring(1);

So why should you not be able to write

double rootOfTwo = 2.sqrt();

???

In fact, in Smalltalk (which is "more OO" than Java), the statement

2 + 3

calls the method "+" on the number literal "2" and passes it a number literal "3" as an argument.

You'd perforce have something like


Not exactly pleasing to the eye.


And, with all due respect, total nonsense...
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Just in the case it wasn't obvious in my previous post: number literals are objects in Smalltalk, just in the same way String literals are in Java.
 
M Beck
Ranch Hand
Posts: 323
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
caveat: i have not actually used, nor even seriously studied, Java 5. so everything i know and think about it comes mostly from reading JavaRanch and other websites, second- and third-hand.

that said, i think autoboxing is probably a good idea. it brings Java one step closer to having no non-object primitives, which is a win. i've seen the Python language go down the same road - from separate primitives to being much closer to Smalltalk - and that language improved immensely from the conversion. granted that Python had the advantage of dynamic typing, which perhaps made the conversion process smoother and easier, but still.

i can see how autoboxing might make the textbook writer's job trickier. introducing types, typecasts and type errors in the presence of autoboxing would likely demand a careful approach and a very clear exposition, or one might end up just confusing the beginning student more. well, i'm not a textbook author, so...

one of these days, the notion of autoboxing will have to be expanded to the point where an integer literal will be automatically boxed into a BigInteger, for example, if needed. and Integers will need the ability to widen automatically to BigIntegers instead of overflowing, and vice versa. it just makes more sense that way - trust me, there's just no point worrying about the "size" of a number when your real worry should be about the problem you want to solve with the number.

enumerations i don't have much opinion on. i guess they're nice for people who really like to push the type-checking system for things like "typesafe enums", but again, i have a dynamic-typing kind of brain; i wouldn't do that, but i wouldn't deny others the tool either, if they wish to use it.

(edited to add: i will likely use enums very much as i would static integer enums, to make my switch statements more readable. they seem even better for this than the old way. there's still a lot i would wish for in the switch statement's syntax, but this will help a bit.)

generics i've only seen in examples, and those examples seem to have been geared towards the very simplest, most basic utilization of the feature. that usage, i will grant, seemed like a great idea - a way to make code clearer and more explicitly typed without adding in too much verbosity or code duplication. if you like static typing, then such usage of generics seem to me like they should be a natural, useful thing. however, i hear comments that seem to imply generics as implemented in Java 5 have more complicated, more subtle details that might not have been apparent to me through the examples i've seen. those, of course, i can't comment on, but i have to wonder how many people will run across them.

varargs, of some kind or other, is a standard thing in every other serious language i know. i've heard tell that Java 5 does them by putting some syntactic sugar on top of an array of arguments. all i can say is, what took so long? that should have been in Java ages ago.

that "new for" loop, again, is familiar to me through Python (where, in fact, it's the only for loop construct), and i'm very happy with it there - it'll do Java a heap of good, too, i'm sure.

annotations are a new thing to me, which i'll have to get used to myself; they're new in the most recent Python, also. done right they could get quite useful, i believe; done wrong, they could be worrisome. they almost echo of Lisp's syntax-redefining macros, to my ear - or at least the Python version of them does, i haven't looked closely at Java 5's implementation.

threading of any kind i hate. always have. too much headache for the tiny benefits it gives; i avoid it strenuously. i won't be looking into the threading additions to Java 5 unless forced to.

(on edit: what i would prefer, instead, would be a way to check whether a subprocess has exited yet without blocking on its doing so. Process.waitFor() blocks, which is a problem for non-threaded applications.)

string-this, string-that, string-builder... yeah, maybe some day i'll be writing Java 5 code and find that interface to be useful. but come that day, i'm sure there'll be yet another couple of string-something interfaces for me to choose from... how hard can it be for the Java designers to get a simple string datatype right, anyway? let's hope this one fixes it for good!

static imports seem like a weak, watered-down approach towards something better, to me. there should be a more generic, more powerful way to do the same thing, for more than just static members, in my arrogant opinion - but i suppose this is better than nothing. my opinion here might be influenced by Python, again; that language has twisted my mind, and i'm afraid it shows every time i comment on any programming language these days. :roll:

C-printf - like formatting is way overdue. let's face it, the C-and-Unix approach to this problem won long before Java was created. the only real competitor to it was Common Lisp, way back in the day, which still had an analogous formatter only with different syntax. it lost; today, a language without this functionality is crippled. sorry, that's just a fact.

the fact that Java never really throws away any old junk will be a serious concern in the future. all those deprecated methods and classes will just have to be thrown out one of these days, or the API will collapse under the weight of its own dead wood. but that might be a worry for a more distant future; it's certain to happen, but it doesn't seem to be happening right now.
[ March 31, 2005: Message edited by: M Beck ]
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by M Beck:
enumerations i don't have much opinion on. i guess they're nice for people who really like to push the type-checking system for things like "typesafe enums", but again, i have a dynamic-typing kind of brain; i wouldn't do that, but i wouldn't deny others the tool either, if they wish to use it.

(edited to add: i will likely use enums very much as i would static integer enums, to make my switch statements more readable. they seem even better for this than the old way. there's still a lot i would wish for in the switch statement's syntax, but this will help a bit.)


The nice thing about Java's enums is that they can have polymorphic behaviour. That is, they actually make the switch statement obsolete in many cases...
 
M Beck
Ranch Hand
Posts: 323
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Ilja Preuss:
The nice thing about Java's enums is that they can have polymorphic behaviour. That is, they actually make the switch statement obsolete in many cases...


oh, there's many good ways to make switch obsolete. my personal favorite is to populate a dictionary (Map) with the "case"s as keys and method references - or even entire anonymous functions - as the values. then all you do is dereference the map on the variable to be switched on, and execute what you get back; one-line switch.
 
Jeroen Wenting
Ranch Hand
Posts: 5093
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Ilja Preuss:
Just in the case it wasn't obvious in my previous post: number literals are objects in Smalltalk, just in the same way String literals are in Java.


Maybe, but you forgot to make operators firstclass objects...
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Jeroen Wenting:
Maybe, but you forgot to make operators firstclass objects...


When you become interested in a constructive discussion instead of a slugfest, please let me know. Thanks.
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!