You want to develop J2ME applications with a Mac OS X operating system ?
This is not as easy going as one might think:

SUN unfortunately provides the “Java Wireless Toolkit” not for OSX (for whatever reason) and their emulator therefore does not work. I think there would be more potential J2ME developers under OSX, but this is actually their (bad) decision. Furthermore, they provide their latest stuff only for Windows :( The only way to get it going on a Linux system is using the old WTK2.2 – nice uh ?

However, there was light at the end of the tunnel:
The mpowerplayer SDK is an emulator (and more…) which is supposed to work on an Apple computers. Well, it does, but there is another catch: No support of the JSR75 fileconnection API so far.

Now and finally one very nice guy implemented the specification and provides a CLDC.jar for mpowerplayer which now allows file input/output !!! This is great news. Thanks for all the effort again! You can see the discussion and also a link for the download of the file here (I think you have to be logged in to view it).

Now and finally my MiniPauker stuff can be developed on my Mac. Nice – very nice indeed.

If you use J2ME-Polish and want to migrate your stuff to OS X, there is one more thing you have to change in your ANT build task:
the preverification of the code is not working with the WTK (the Linux version) – modify your build section and point it to the MPowerplayer subdirectory osx:

 *snip* build preverify="/Applications/mpp-sdk/osx/preverify/preverify" *snip*

Enjoy your Midlet development!

OK – I have just started using Generics more often and run into small issues as everyone does I guess. Generics are not the same as C++ templates, that’s one of the first things you one has to learn. Generics are a compile time thing, so runtime critical stuff makes one mad … and is sometimes anoying.

Generics are processed at compile time:

So, what happens here ? Any clue? Sure, it doesn’t work and the compiler complains: “cannot select from a type variable: name = T.class.getName();”. The compiler doesn’t know anything about “T” – OK (Information about generic types is ignored at runtime).

As we’ve seen, the compiler won’t be able to tell what “T” is all about, unless the programmer is forced to tell the compiler about it (a workaround):
[code lang="java"]
public class Generics2 {

private final String name;

public Generics2(Class clazz) {
name = clazz.getName();
}
}
[/code]

2nd Problem:
The next thing I ran into was the problem that generic types and static stuff doesn’t really fit together, well, sort of obvious. I was looking for a way to write a generic Cache class which simply holds some data of a specific type T in one instance of a Map (This shouldn’t be a discussion about Singletons and whether they are a good or bad thing).

So, ever tried something like this:
[code lang="java"]
public class Cache {

private static Map> instances = new HashMap>();

private Cache() { }

public static Cache getInstance() { ...
[/code]
It’s not the getInstance method – the static member is something the compiler dislikes: “non-static class T cannot be referenced from a static context”.

So I was a bit pale here, but found a solution, which seems a bit hacky and dirty to me, but I guess there is no better or cleaner way. Please let me know if you are aware of one :) Here we go:
[code lang="java"]
public class Cache {

private static Map, Object> cacheInstances =
new HashMap, Object>();

private Map cachePerInstance = new HashMap();

private Cache() { }

public static synchronized Cache getInstance(Class clazz) {
Cache instance = (Cache)cacheInstances.get(clazz);

if (instance != null) {
return instance;
}

instance = new Cache();
cacheInstances.put(clazz, instance);
return instance;
}

public void put(final String key, final T value) {
cachePerInstance.put(key, value);
}

public T getValue(String key) {
return cachePerInstance.get(key);
}
[/code]