I came across another generic puzzle and hope that someone has some insights.

I set out to explore how the compiler treats a plain List vs. a List<?>, and in the process found something mysterious.

I need to use the collective-consciousness of the Artima community, like genetic algorithms, to come up with a set of canonical use cases for generics.

I was poking around in the Standard Java Libraries looking for examples of generic code, and came across something curious.

Up until now, whenever I've tried open-source Word clones with my books, they've collapsed to the floor, babbling and drooling.

In my posting "Mixins: Something Else You Can't Do With Java Generics?", someone suggested (incorrectly) that this was just the C++ "Curiously Recurring Template Pattern." The analog of the CRTP does work in Java, but is it good for anything?

Someone pointed out that Josh Bloch suggests using interfaces to produce the effects of mixins; this is a common pointer when justifying the lack of multiple inheritance in Java. I've translated yesterday's C++ mixin example based on this idea.

The paper "A First-Class Approach to Genericity" introduces the idea of the mixin, which seems to be quite a powerful concept, and then shows that you can't do it with Java generics. I wonder if anyone has any alternative approaches to this problem.

The Concurrency chapter is finished (hurray!), and now I re-wade into the mysteries of Java Generics. The chapter isn't looking as bad as I was remembering, but there are still some issues that I'm struggling to understand and explain.

In a thread on Heron, some issues came up that I thought were worth clarifying.

As I can see the end of Thinking in Java 4e approaching, I'm starting to get into the mode to work on the Hands-On Java CD ROM (4th edition, skipping a release number to synch with the book), which I will do in Flash to eliminate various platform problems.

I've noticed that, in descriptions of threading, the levels of abstraction are often mixed, which I believe adds to the confusion already present in understanding threading. In this short exerpt from "Thinking in Java fourth edition," I attempt to clarify the situation.

It's not uncommon to run across technical papers published in postscript. It's not clear to me why people still do this, but until yesterday I've never had the patience to figure out how to read them.

Threading has sucked down a lot of my life in the past few years. Aside from work on earlier versions of Thinking in Java, I clocked 8 months on the threading chapter in "Thinking in C++, Volume 2." I've already spent several months on the "Concurrency" Chapter in "Thinking in Java 4th edition." And now I'm back working on it again.

In my research for the "Concurrency" chapter for Thinking in Java 4e, I've read through a lot of material. This morning, I started perusing the 3rd edition of "Java Threads" by Oaks & Wong, from O'Reilly.