logic involved

The JVM Serialisers project provides a very extensive comparison of dozens of different JVM serializers out there. Tested tools include several JSON libs, different XML related libs, Scala, protobuf, protostuf, msgpack and many more.
I didn’t know protostuff before – it seems to be really amazing!

(via tutego)

Apple won’t provide further updates to Java, but OpenJDK for Mac OS X is advancing rapidly.
Thankfully, TheServerSide.com provides an extensive list of OpenJDK/OS X related links:

For more information about the Mac OS X Port project, please check out these resources:
Project home: <http://openjdk.java.net/projects/macosx-port>
Project wiki & getting started instructions: <http://wikis.sun.com/display/OpenJDK/Mac+OS+X+Port>
Project status: <http://wikis.sun.com/display/OpenJDK/Mac+OS+X+Port+Project+Status>
Mailing list: <http://mail.openjdk.java.net/mailman/listinfo/macosx-port-dev>
Source repository: <http://hg.openjdk.java.net/macosx-port/macosx-port>

You are looking for binaries? Then head over to the opendjk-osx-build project on Google Code (via).

• New Java desktop UI toolkit:
  Amino brings some nice features
• Authentication != Authorization (and more):
  Diaspora has a long way to go, but there are lots of things you can learn. Things like what you should never, ever do, that is.
• Java obfuscation:
  the Android developers recommend ProGuard. It’s actually a very nice utility, but I don’t feel comfortable to apply a complicated technique to already complicated applications.
• One Time Passwords, remote logout:
  Facebook adds new security features, and some questions are crossing my mind:
  why not add add OPIE-like features, with One Time Password Lists and/or two-factor authentication (with something you know and something you have)? We got lots of smartphones out there, just use them…?
  re “remote logout”: why not just invalidate existing web sessions on the next login of the user? Can Facebook make a difference between web and API (e.g. widget, apps) sessions?

Usually the string resources in your Android application are being referred to by a unique ID. But sometimes you will want to recover a string by its key, e. g. when you build the key of the string at the run time of your application (“Battery_Health_2″ or “Battery_Health_3″). You can do that like this:

private String getStringResourceByName(String aString)
{
  String packageName = "com.coliena.myapp";
  int resId = getResources().getIdentifier(aString, "string", packageName);
  return getString(resId);
}

Check this link if you need to recover an image resource by its name.
More information about string resources is available in the Android Developer Documentation.

Apple apparently set Java 6b14 (64 bit) as default in Snow Leopard, both in 32 and 64 bit Kernel environments.
They dumped Java 1.4 and Java 5, but you can switch to Java 6 (32 bit).