Forums Register Login

The Good; The Bad and The Ugly of Java 5

+Pie Number of slices to send: Send
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.
+Pie Number of slices to send: Send
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
+Pie Number of slices to send: Send
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
+Pie Number of slices to send: Send
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++...
+Pie Number of slices to send: Send
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.
+Pie Number of slices to send: Send
In general, I only like the invitation of Generics. Other features seem not that useful, but introduce new problems.

Nick
+Pie Number of slices to send: Send
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.
+Pie Number of slices to send: Send
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.
+Pie Number of slices to send: Send
 

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...)
+Pie Number of slices to send: Send
I so agree with you guys and that would have automatically eliminated one of the clutters known as autoboxing.
+Pie Number of slices to send: Send
 

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.
+Pie Number of slices to send: Send
Hi Anselm -

Ok, I'll simplify... I'm not too fond of annotations or generics
+Pie Number of slices to send: Send
In fact, this would not exist if Java had no primitives.
You'd perforce have something like


Not exactly pleasing to the eye.
+Pie Number of slices to send: Send
 

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.
+Pie Number of slices to send: Send
 

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.
+Pie Number of slices to send: Send
 


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
+Pie Number of slices to send: Send
 

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.
+Pie Number of slices to send: Send
 

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...
+Pie Number of slices to send: Send
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.
+Pie Number of slices to send: Send
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 ]
+Pie Number of slices to send: Send
 

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...
+Pie Number of slices to send: Send
 

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.
+Pie Number of slices to send: Send
 

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...
+Pie Number of slices to send: Send
 

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.
Amateurs built google. Professionals built the titanic. We can't find the guy that built this tiny ad:
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com


reply
reply
This thread has been viewed 1145 times.
Similar Threads
java 1.4 or 5.0
heap size
Strange Behaviour -- Pls Advice
Vote here: I'm studying for the SCJP 1.5 exam
Show me the Path...
Thread Boost feature
More...

All times above are in ranch (not your local) time.
The current ranch time is
Mar 28, 2024 04:13:56.