ArrayList.Iterator.remove()

[Roedy Green]

There really is no reason not to be aware of the basic collection classes.

For a quick overview of what each Collection is good for, see
http://mindprod.com/jgloss/collection.html
--
Roedy Green Canadian Mind Products
http://mindprod.com

"Deer hunting would be fine sport, if only the deer had guns."
~ William S. Gilbert of Gilbert and Sullivan

 

[Donkey Hottie]

What?! Are you kidding me? I'm sorry but this is
bull****. How the hell can you program in Java at all
with out at least bumping into the Collections classes? This is really
amazing to me. They're in every tutorial.
It's basic algorithms and should be instantly familiar to
anyone who made it through their lower division course
work.... I'm just aghast. Seriously.
Especially a C++ programmer should be on the lookout for
something in a new language to replace the STL, and
Collections is a big part of Java's answer to the STL.

I was aware of the Collections, with ArrayList, but not *LinkedList*. It's a
late addition, and I have moved out from Java 1.4.2 only lately... Now using
Java 6.

 

[Eric Sosman]

I was aware of the Collections, with ArrayList, but not *LinkedList*.
It's a late addition, and I have moved out from Java 1.4.2 only
lately... Now using Java 6.

java.util.LinkedList is "since 1.2" in the Javadoc.

 

[Lew]

I was aware of the Collections, with ArrayList, but not *LinkedList*.
It's a late addition, and I have moved out from Java 1.4.2 only
lately... Now using Java 6.

Yeah, it wasn't introduced until Java 1.2, ten and a half years ago.

 

[Lew]

generics insanity,

To what insanity do you refer?

 

[charlesbos73]

To what insanity do you refer?

erasure? (say as opposed to the way they're done in C#),
making them useless from an OO point of view?

public interface UselessGenerics extends Handable<A>, Handable<B> {

"Duplicate class: '.....Handable'

AAAAAAlllllrrrriiiigggghhhhhttttt.

It's just like the broken Java equals() concept: it "works" only
as long as you're doing procedural programming.

As soon as you want to some real OOA/OOD->OOP translation you're
out of luck.

But I'll give it to you: for 99.9% of all the Java programs out
there are just glorified procedural programs it's no big deal.

 

[Lew]

This sort of issue is one of the reasons why I read this newsgroup
regularly. It is especially valuable for a solo programmer. I know a lot
of things exist because people have asked questions about them, or they
have been recommended as solutions.

You make a very good point. However, the collections classes are
among the Java features that are quite fundamental, and when working
with such things as collections one should be in the habit of
reviewing the Javadocs to see what exists already. For one accustomed
to using the Javadocs it would be quite clear after having been
alerted to the existence of a decade-old API that the class is not
new, even if they didn't discover the class until having been alerted
to it.

Usenet is useful, but not the best as the primary source of Java
knowledge, let alone the only one. To achieve competence in Java
programming, let alone virtuosity, one must be in the habit of reading
the Javadocs, the tutorials, search engine results, and yes, even
books. It helps to be aware of third-party library sources, too, like
Apache Commons (which has even more collections classes), sourceforge
and the like.

LinkedList, HashMap, java.util.Collections and other such have been
officially part of the Java API since 1998. Like, say, large parts of
the java.io and javax.swing packages, there's precious little reason
for a professional Java programmer not to be at least aware of their
existence, nor to think that they're brand new.

 

[Mayeul]

erasure? (say as opposed to the way they're done in C#),

Point taken I guess. No erasure would have horribly broken Java 1.4 code
and previous, so it is necessary. Still, it is a flaw.

making them useless from an OO point of view?

Seems like an overstatement. The commodity of generics fairly
facilitates OO design, which is just as valid as an 'OO point of view'.

public interface UselessGenerics extends Handable<A>, Handable<B> {

"Duplicate class: '.....Handable'

AAAAAAlllllrrrriiiigggghhhhhttttt.

Just because this doesn't work, doesn't make everything useless.

It's just like the broken Java equals() concept: it "works" only
as long as you're doing procedural programming.

It's not the first time you criticized Java Object.equals(), and you've
been asked for clarifications, but I didn't see them. I still fail to
understand how not OO or how anti-OO that is.

As soon as you want to some real OOA/OOD->OOP translation you're
out of luck.

[Citation needed]

But I'll give it to you: for 99.9% of all the Java programs out
there are just glorified procedural programs it's no big deal.

Actually that might be true, considering that the vast majority of
programming done on the whole world is not done by skilled software
designers.

Same for just about any well-known language, I guess.

 

[Lew]

Point taken I guess. No erasure would have horribly broken Java 1.4 code
and previous, so it is necessary. Still, it is a flaw.

While there are definitely times when having generics information at
run time would help, the fact that it's compile-time only does benefit
in that it forces one to handle type issues at compile time, when bugs
are much cheaper to fix than at run time. In practice, the need for
run-time generification is only for corner cases; most of the time
it's completely sufficient to have only compile-time checking.

People misunderstand the generics mechanism. Generics support type
analysis, and type analysis can be quite tricky. Hence, use of
generics can be tricky. However, once you get all the generics
compiler messages ironed out, you have a self-documented ironclad type
contract in your code. It's well worth the effort.

It's not the first time you criticized Java Object.equals(), and you've

And probably not the last.

been asked for clarifications, but I didn't see them. I still fail to
understand how not OO or how anti-OO that is.

He's just being trollish. Making inflammatory comments without
evidence or logic is one of those classic trollish Usenet behaviors.

Others have responded to his criticism that Java is not object-
oriented, which, of course, it is, and "charlesbos73" was equally
silent regarding their responses. At any rate, I haven't seen anyone
respond to any of his responses. For example, his misrepresentation
of statements from /Effective Java/ was called to account.

Polymorphism is one of Grady Booch's six pillars of object orientation
- by that standard 'Object.equals()' definitely fits the O-O paradigm.

I see no way in which Java violates object orientation except perhaps
the support for static members. Java is clearly an object-oriented
language. (OK, Smalltalk fans, settle down.)

 

[Arved Sandstrom]

Eric Sosman wrote:
[ SNIP ]

Some of the corners are fairly gently rounded, as witness the
number of questions that arise here about them. Perhaps the two
most common "smooth corners" are constructing instances of and
making arrays of the parameterized type:

class Generic<T> {
T instance = new T(); // no good
T[] array = new T[42]; // no good
}

[ SNIP ]

About the closest you can get is to use
java.lang.reflect.Array.newInstance(Class<?>, int) or
java.lang.reflect.Array.newInstance(Class<?>, int[]). It's not perfect,
as pointed out by
Goetz(http://www.ibm.com/developerworks/java/library/j-jtp01255.html,
about halfway down the page).

AHS

 

[Tom Anderson]

When I think of hidden Java features I think of secret accessor methods,
generics insanity, -XX switches, FinalReference, and in-place math
operators lacking narrowing checks.

FinalReference is new to me. Now i know what it is, but that's it - what
can you do with it?

tom

 

[Knute Johnson]

You make a very good point. However, the collections classes are
among the Java features that are quite fundamental, and when working
with such things as collections one should be in the habit of
reviewing the Javadocs to see what exists already. For one accustomed
to using the Javadocs it would be quite clear after having been
alerted to the existence of a decade-old API that the class is not
new, even if they didn't discover the class until having been alerted
to it.

Usenet is useful, but not the best as the primary source of Java
knowledge, let alone the only one. To achieve competence in Java
programming, let alone virtuosity, one must be in the habit of reading
the Javadocs, the tutorials, search engine results, and yes, even
books. It helps to be aware of third-party library sources, too, like
Apache Commons (which has even more collections classes), sourceforge
and the like.

LinkedList, HashMap, java.util.Collections and other such have been
officially part of the Java API since 1998. Like, say, large parts of
the java.io and javax.swing packages, there's precious little reason
for a professional Java programmer not to be at least aware of their
existence, nor to think that they're brand new.

I'm with Patricia on this. I work by myself and while I read books, the
docs and the tutorials, the API is staggering in its size and
complexity. The news groups have been invaluable for me in my work. On
the Collections issue specifically, I've used them for years but I don't
know all the ins and outs of what is more efficient for a particular
type of operation. This thread gave me a lot of valuable information
that I will use in the future and now to look at code already written
with an eye to better performance.

I am not however making any excuses for the OPs ignorance of the API.
You are right about that, he should have some clue. We do get folks in
here though that have never written a lick of Java code and need to fix
something. I have to fix Perl once in a while (and I need the three
books I have for that) and have to learn new languages periodically.
Sometimes you can be pretty clueless and a good pointer or two will get
you going.

The two main reasons I inhabit these newsgroups, is that I received so
much help here when I really needed it and that I learn so many new
things by reading the posts. Not as many today as in the beginning but
like this post some valuable tidbits here and there.

 

[Kevin McMurtrie]

FinalReference is new to me. Now i know what it is, but that's it - what
can you do with it?

tom

Try to avoid them! When you override finalize(), each instantiation of
your object creates a Finalizer that's a subclass of FinalReference. A
Thread polls its ReferenceQueue and calls to finalize() during the GC
process. Overriding finalize(), even with an empty method, on
frequently created objects can be a catastrophic drain on performance
and memory.

 

[Kevin McMurtrie]

generics insanity,

To what insanity do you refer?[/QUOTE]

Simple generics work fine but all hell breaks loose on complex data. The
solution just isn't very robust. This sums it up well:
http://www.ibm.com/developerworks/java/library/j-jtp01255.html

Don't even get me started on ReferenceQueue generics.

It also forgets to mention that each genericized method has a
non-genericized method automatically created by the source compiler:

class Foo extends HashSet<Integer>{}
class Bar<T> extends HashMap<Integer, T>{}
class Moo<T> extends HashMap<Integer, T>
{
@Override public T put(Integer key, T value)
{
return super.put(key, value);
}
}

new Foo().add("hello"); //Compile Error
new Bar<String>().put("hello", "there"); //Compile Error
new Bar().put("hello", "there"); //OK... until later.

//Drumroll....
new Moo().put("hello", "there");
//ClassCastException on a bogus line number

 

[Lew]

Simple generics work fine but all hell breaks loose on complex data. The
solution just isn't very robust. This sums it up well:
http://www.ibm.com/developerworks/java/library/j-jtp01255.html

I don't see insanity here.

Don't even get me started on ReferenceQueue generics.

It also forgets to mention that each genericized method has a
non-genericized method automatically created by the source compiler:

The output of the compiler is generics-free, of course. This is well documented.

class Foo extends HashSet<Integer>{}
class Bar<T> extends HashMap<Integer, T>{}
class Moo<T> extends HashMap<Integer, T>
{
@Override public T put(Integer key, T value)
{
return super.put(key, value);
}
}

new Foo().add("hello"); //Compile Error

Duhhh. That's the purpose of generics.

new Bar<String>().put("hello", "there"); //Compile Error

Duhhh. That's the purpose of generics.

new Bar().put("hello", "there"); //OK... until later.

//Drumroll....
new Moo().put("hello", "there");
//ClassCastException on a bogus line number

Well, duhhh. You used a raw type, which does create a compiler warning. One
is thoroughly advised not to mix raw types and generics. That
ClassCastException is exactly what one would have gotten before generics were
added to Java.

What you illustrate here is not generics insanity but a typical programmer error.

 

[Lew]

Try to avoid them! When you override finalize(), each instantiation of
your object creates a Finalizer that's a subclass of FinalReference. A
Thread polls its ReferenceQueue and calls to finalize() during the GC
process. Overriding finalize(), even with an empty method, on
frequently created objects can be a catastrophic drain on performance
and memory.

Could someone please point to a FinalReference reference?

 

[Arved Sandstrom]

Could someone please point to a FinalReference reference?

I couldn't find one myself. Looking at the code for
java.lang.ref.Finalizer, which extends java.lang.ref.FinalReference, is
probably the best way to figure it out.

AHS

 

[Kevin McMurtrie]

Simple generics work fine but all hell breaks loose on complex data. The
solution just isn't very robust. This sums it up well:
http://www.ibm.com/developerworks/java/library/j-jtp01255.html

I don't see insanity here.

Don't even get me started on ReferenceQueue generics.

It also forgets to mention that each genericized method has a
non-genericized method automatically created by the source compiler:

The output of the compiler is generics-free, of course. This is well
documented.

class Foo extends HashSet<Integer>{}
class Bar<T> extends HashMap<Integer, T>{}
class Moo<T> extends HashMap<Integer, T>
{
@Override public T put(Integer key, T value)
{
return super.put(key, value);
}
}

new Foo().add("hello"); //Compile Error

Duhhh. That's the purpose of generics.

new Bar<String>().put("hello", "there"); //Compile Error

Duhhh. That's the purpose of generics.

new Bar().put("hello", "there"); //OK... until later.

//Drumroll....
new Moo().put("hello", "there");
//ClassCastException on a bogus line number

Well, duhhh. You used a raw type, which does create a compiler warning. One
is thoroughly advised not to mix raw types and generics. That
ClassCastException is exactly what one would have gotten before generics were
added to Java.

What you illustrate here is not generics insanity but a typical programmer
error.[/QUOTE]

The last two have been problems when updating existing code in a large
project. Regardless of whether classes Moo or Bar are constructed with
generics, the Map key is clearly defined as Integer. The source
compiler added a hidden method that allows compilation of code that can
not run.

Compiler warnings are great for new code, but not so great for the
millions of lines of old code.

 

[Lew]

....
Regardless of whether classes Moo or Bar are constructed with
generics, the Map key is clearly defined as Integer. The source
compiler added a hidden method that allows compilation of code that can
not run.

It's not a "hidden" method, it's
'public Object put( Object key, Object value )',
as is always the case when you erase generics, and is heavily documented as such.

The 'Map' key is based on extending 'HashMap<Integer, T>', which erases to
'HashMap <Object, Object>', and is therefore not "clearly defined as Integer"
at run time. You call this "insanity", but it's really just plain old simple
erasure. This is the common programmer error to which I alluded upthread, and
the inevitable consequence of mixing raw and generics types. You insert a
'String' key into the map, then try to extract it to an 'Integer' target, thus
yielding the 'ClassCastException', just as documented and expected for this
scenario. Again, this is what would happen if you tried this prior to Java 5.

It makes no sense to break the rules, get the exact result that is documented
for breaking the rules, then complain that you get that result.

 

[Lew]

I couldn't find one myself. Looking at the code for
java.lang.ref.Finalizer, which extends java.lang.ref.FinalReference, is
probably the best way to figure it out.

So, once again, not a hidden *feature* but a hidden *implementation detail*.

I thought one of the tenets of O-O programming was to hide implementation details.