We need some programing topics. How about Java 1.5 ?

[AFB]

Text

[*]Generics: Seems to add more type safety. Good idea IMO.

[*]The new for-each type for loop: Why couldn't we get a for-each keyword :|

[*]Autoboxing: I think this will lead to people getting sloppy with Java code and a bad idea IMO. Whar's wrong with the primitive type objects ?

[*]Enums: Seems to work well

What do you think ?

 

[notfred]

I don't really have a problem writing "for" instead of "foreach" it's shorter and means the same thing. I also think autoboxing is a good idea. Casting an int to an Integer is stupid.

 

[AFB]

Originally posted by: notfred
I don't really have a problem writing "for" instead of "foreach" it's shorter and means the same thing. I also think autoboxing is a good idea. Casting an int to an Integer is stupid.

A Perl man's opinion 😉😀😛
The only problem I have with the new for loop syntax is that I find it a little strange. Its not that big a problem. 🙂
But really, what's wrong with this:

 

[kamper]

Holy crap. Thanks for pointing this out amdfanboy. I knew 1.5 was around but I didn't think to read about the changes.

The only one I've read so far is the enumeration stuff and I think it's absolutely brilliant. I've worked in other languages where enums are an extremely good design tool in terms of type safety (namely Delphi) but lack abstraction. I actually had a situation where I had to define several hundred enums that fulfilled very similar roles and in order to process them I had to rewrite the same functions over and over again because each function could only handle one type (ok, so maybe there were some design issues 😱).

Anyways, it's always bugged me that you have to use stupid things like naming conventions to enforce enumerations in java. Most developers I know will use ints but never check to make sure that valid values are being used. Enums let the compiler do it for you so you end up with much safer code with little effort. The fact that they've made efforts to make enums object oriented as well is great (and just what you'd expect from Java).

Now I've got to read up on that funny angle bracket syntax. Seems to be another type-safety feature. This is so sweet, I love compiler-enforced type-safety 🙂

 

[AFB]

Originally posted by: kamper
Holy crap. Thanks for pointing this out amdfanboy. I knew 1.5 was around but I didn't think to read about the changes.

The only one I've read so far is the enumeration stuff and I think it's absolutely brilliant. I've worked in other languages where enums are an extremely good design tool in terms of type safety (namely Delphi) but lack abstraction. I actually had a situation where I had to define several hundred enums that fulfilled very similar roles and in order to process them I had to rewrite the same functions over and over again because each function could only handle one type (ok, so maybe there were some design issues 😱).

Anyways, it's always bugged me that you have to use stupid things like naming conventions to enforce enumerations in java. Most developers I know will use ints but never check to make sure that valid values are being used. Enums let the compiler do it for you so you end up with much safer code with little effort. The fact that they've made efforts to make enums object oriented as well is great (and just what you'd expect from Java).

Now I've got to read up on that funny angle bracket syntax. Seems to be another type-safety feature. This is so sweet, I love compiler-enforced type-safety 🙂

Enums aren't just ints, they are actually real objects and have methods/fields.(See the explination , I just scanned it) The angle bracket syntax helps get rid of the container cast problem.

example

 

[kamper]

I know enums aren't ints, that's why I'm happy 😉

Thanks for the angle bracket explanation, that's about what I suspected. Very cool stuff.

 

[kamper]

Something I don't see that I'd like to is a new scope. I don't like that protected scope members can be accessed at a package level (this makes no sense to me). There really needs to be a scope that can be accessed by a class and it's subclasses only. Kind of like when you write without packages all together.

That annotation stuff is pretty cool. I can see that coming very much in handy for enterprise development with ejbs and stuff where half the work is generating extra code and deployment descriptors. Currently the metadata is written in javadoc comments, if you are using code generation tools like xdoclet.

I have to say that I don't like static imports. They look too easy to abuse and seems like they could become very confusing. What I'd like to see is a kind of block-level non-static import something like so: (see code snippet below)...

Of course this is a bit of a pointless example but notice how you can call get() and size() on the List without saying numbers.get()...? This is kind of like static import except that it's scoped down so it's easier to remember where the get() and size() methods are coming from and you can also use it on non-static members. (Also note the use of generics and and autoboxing, in case that syntax seems weird).

It seems that there are a tonne of syntactical additions in this version. I think if java gets too much richer it will be hard for beginners to keep their heads above water. I've been doing java in school for 3 years and my job is java programming and I'm still learning the syntax (nested classes, static initialization blocks, inline class definitions...). I think I can handle this new stuff but for a beginner programmer it's hard enough already.

Just my 2 cents.

 

[AFB]

Yeah, I can't see how someone who was just beggining could figure it out.