JSR-32 1.2 is about to be released soon. It contains almost all the changes we requested so far and it will be usable and correct.
There's a tendency there, which i don't like, to return iterator objects instead of abstract collection - i think it is an errornous practice in Java, since it doesn't give anything, except for making the user of the class work harder. It is a practice taking from C++ STL - where it works fine - but it isn't suitable for Java and JFC.

In the past month i didn't touch the game code, however, before that, i managed to sort-of finish the server. It is a really rich server and it supports scalability in a simple yet powerful way. It also contains a very sophisticated and flexible game objects, allowing developers to define quite a wide variaty of game sets. A "Game set" contains few configuration parameters and a database of game-objects. Game objects are: cards, spells, powers and items. Each of which has a list of properties and attribute and zero and more effects. Effects can work on a target player or a target object, selected manually, randomaly, and with limiting filters or not.
Alliences can be made between players, and they can also trade objects.
A different game-set can also mean a really different approach and thus a different suitable strategy! It also make it all interesting, since players can collect artifacts from different game-sets and use them wherever they want.
There are many cute things in the game, but im not going to go into it all.
the weak point is the UI and the game-sets. Right now, there's a text ui that is supposed to be used to test the logic etc., but it is not finished. im thinking of a JOGL based GUI. There's also no game-sets defined yet, except for few objects for test purpose.
i hope to get back to the development of it very soon.

i just started to write a game, something in the style of Magick the Gathering. It is in pure Java. My intentions are:
1. To make it open-source, easily expandable.
2. To make it simple, learning-curve-wise, but not too simple - strategy and thinking are a must.
3. To make it multi-player (small groups though)
4. To support AI players.
5. To let a player has a persistant "avatar", but yet he can be beaten by a newbie, if he's not careful enough, so one always has someone worthy live opponent (or ally) to play with.

Currently, i work on it a little on weekends, and so is my wife's brother. A little here and a little there.
It is an easy thing to write, actually.
We didn't start the GUI yet.
i haven't done any open-source project yet (beside the time i worked in IBM research labs) and im going to put it on sourceforge when we get the code base to a decent enough functionality.

Right now im doing a project that is practically a JSR-32 Java wrapper around a C implementation if SIP stack. It is not as straight forward as it may seem, because of two reasons: 1) there's a difference in the semantics between the JSR's to the existing C stack; 2) there are very tough performance requirments and JNI might hinder the possibility to make anywhere near the speed of the C stack; 3) the JSR is not well designed.
The man responsible for the JSR-32 did a good job considering the fact he has no real-world experience with SIP, but it is not good enough for demanding real-world SIP-using applications. As part of our implementation job, we are in dialog with him regarding changes that are required from his spec. He's cooperating nicely.