Generics are cool

J

Joseph Dionne

I think the addition of "templates" (Generics) in 1.5 will reduce Class
casts considerably. With Java API syntax approaching the wordiness of
COBOL, and retaining the need of casts from c, code gets "messy" to read.

Good move by me.

Joseph
 
H

hiwa

Joseph said:
I think the addition of "templates" (Generics) in 1.5 will reduce
Class casts considerably. With Java API syntax approaching the
wordiness of COBOL, and retaining the need of casts from c, code gets
"messy" to read.

Good move by me.

Joseph

I feel Java generics is good only on its thinnest skin, like:

ArrayList<String> as = new ArrayList<String>();

And under that, whole messiness.
It's very hard and coufusing to teach it to students and/or beginners.
I'm quite lost at that.
 
P

philip.goh

Well, Generics are also very cool because you can now use primitives
(floats, ints, doubles, etc) with the supplied Collection framework.

P.
 
P

Phillip Lord

philip> Well, Generics are also very cool because you can now use
philip> primitives (floats, ints, doubles, etc) with the supplied
philip> Collection framework.


I thought this was autoboxing, not generics.

Phil
 
J

Joseph Dionne

Phillip said:
philip> Well, Generics are also very cool because you can now use
philip> primitives (floats, ints, doubles, etc) with the supplied
philip> Collection framework.


I thought this was autoboxing, not generics.

Phil


In the context of Collection(s), it would is Generics and not
autoboxing. Generics describe a new feature of Collection usage, where
the developer controls the contents of the Collection, and should not
have to cast the return Object to the data type his previous code added
into them.

joseph
 
P

Peter Ashford

Joseph said:
In the context of Collection(s), it would is Generics and not
autoboxing. Generics describe a new feature of Collection usage, where
the developer controls the contents of the Collection, and should not
have to cast the return Object to the data type his previous code added
into them.

Philip is correct - using primitives in collections is due to autoboxing
in 1.5, not generics. Even without generics, you'd be able to use
primitives in 1.5 containers due to autoboxing.
 
J

Joseph Dionne

Peter said:
Philip is correct - using primitives in collections is due to autoboxing
in 1.5, not generics. Even without generics, you'd be able to use
primitives in 1.5 containers due to autoboxing.


Please correct me if my reading of autoboxing is wrong, but it appears
to me autoboxing is more to do about up casting a primitive to a
function return automatically than casting a generic Object to the type
of the object receiving the assignment.

As I read Generics, they only apply to containers capable of holding
Objects of any type.

joseph
 
J

Joseph Dionne

Joseph said:
Please correct me if my reading of autoboxing is wrong, but it appears
to me autoboxing is more to do about up casting a primitive to a
function return automatically than casting a generic Object to the type
of the object receiving the assignment.

As I read Generics, they only apply to containers capable of holding
Objects of any type.

joseph

On second thought, perhaps Generics simply provides javac the
information it needs to implement autoboxing.

joseph
 
A

Alex Buell

In the context of Collection(s), it would is Generics and not autoboxing.
Generics describe a new feature of Collection usage, where the developer
controls the contents of the Collection, and should not have to cast the
return Object to the data type his previous code added into them.

Autoboxing, not generics.
 
P

philip.goh

My bad.

I've only just installed Java 1.5 on my Mac and haven't really used
collections with primitives yet. Turns out generics in Java is
sufficiently different from generics in C++. List<int> doesn't work in
Java....

ah well...

P.
 
M

Murat Tasan

My bad.

I've only just installed Java 1.5 on my Mac and haven't really used
collections with primitives yet.

did i miss something? i'm pretty sure java 1.5 STILL (ahem, apple...) has
not been released for macos 10.
Turns out generics in Java is
sufficiently different from generics in C++. List<int> doesn't work in
Java....

correct. generics in Java works only with reference objects. although,
you can certainly create a list such as:

List<Integer> myList = new ArrayList<Integer>();

and then add ints via autoboxing:

myList.add(5);

although, be sure to read about autoboxing/unboxing as for
high-performance applications this is not a good way of introducing
collections and primitives. if your app is of that nature
(high-performance), it is still better to use your own simple (and often
array-based) data structures. the Collection Framework is good to work
with at times, but can cause your app to be unbearably slow at times
(especially when considering the extra call stack items that are run when
doing auto boxing/unboxing).
 
J

Joseph Dionne

Murat said:
did i miss something? i'm pretty sure java 1.5 STILL (ahem, apple...) has
not been released for macos 10.




correct. generics in Java works only with reference objects. although,
you can certainly create a list such as:

List<Integer> myList = new ArrayList<Integer>();

and then add ints via autoboxing:

myList.add(5);

although, be sure to read about autoboxing/unboxing as for
high-performance applications this is not a good way of introducing
collections and primitives. if your app is of that nature
(high-performance), it is still better to use your own simple (and often
array-based) data structures. the Collection Framework is good to work
with at times, but can cause your app to be unbearably slow at times
(especially when considering the extra call stack items that are run when
doing auto boxing/unboxing).

You make an interesting observation, that autoboxing affects
performance. Do you know by how much? Will using a Hotspot VM regain
any performance loss?
 
P

Phillip Lord

Joseph> On second thought, perhaps Generics simply provides javac
Joseph> the information it needs to implement autoboxing.


No. The information is there anyway....


Collection c = new Collection (of somekind);
boolean b = false;

c.add( b );

boolean r = c.get();


We know that c is of type Collection and b is a primitive. Therefore
we autobox, compiling to effectively into something like..

Collection c = new Collection (of somekind);
boolean b = false;

c.add( new Boolean( b ) );

boolean r = c.get().booleanValue()


In the first case we know to use new Boolean( b ) because b is a
boolean, in the second we use booleanValue because r is.


Of course, generics would make this type safe.

Phil
 
T

Tim Tyler

Joseph Dionne said:
Alex said:
Phillip Lord wrote [or quoted]:
philip> Well, Generics are also very cool because you can now use
philip> primitives (floats, ints, doubles, etc) with the supplied
philip> Collection framework.

I thought this was autoboxing, not generics.
[...]
Autoboxing, not generics.

I'll stand corrected. Either way, the functionality is still very cool.

IMO, autoboxing sucks.

AFAICS, it's only good if your point of comparison is the previous version
of Java.

Take a slightly less myopic perspective - and surely the best thing is
never to have had primitive types in the first place.
 
P

Phillip Lord

Joseph> I read that this weekend. Oh, well, yet another Java
Joseph> feature I will not be using. Too bad.


Don't be so hasty. If you write an app which this feature a lot, then
it might cause performance problems. But it is nearly always wrong to
assume that know what will cause performance problems, with the broad
acceptance of algorithmically expensive code (anything in exponetial
or worse time is always going to be a problem soon or later; probably
sooner).

Premature optimisation is a cause of many bugs. If autoboxing makes
code easier to read (which I think it will), you should throw it away
only if you know it too be causing problems, that is, if you have
profiled your code.

Besides which autoboxing should cause no performance problems that


c.add( new Boolean ( false ) );

does not. It's the same thing. If you are writing performance code
then you should be wary of this anyway. The only thing that autoboxing
does is hide the object creation (in much the same way as the string +
operator).

Phil
 
A

Antti S. Brax

Joseph> On second thought, perhaps Generics simply provides javac
Joseph> the information it needs to implement autoboxing.

No. The information is there anyway....

No. There are only assumptions.
Collection c = new Collection (of somekind);
boolean b = false;
c.add( new Boolean( b ) );
boolean r = c.get().booleanValue()

In the first case we know to use new Boolean( b ) because b is a
boolean, in the second we use booleanValue because r is.

In the second case you do not know what comes out of the
collection. You only _assume_ it is a boolean, since the
programmer wants one.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top