Magic fields in Enum

A little experiment:

public class Scratch { private static enum Fred { A; public void setOrdinal(final int ordinal) { try { final Field field = getClass().getDeclaredField("ordinal"); field.setAccessible(true); field.set(this, new Integer(ordinal)); } catch (IllegalAccessException e) { throw new Error(e); } catch (NoSuchFieldException e) { throw new Error(e); } } } public static void main(final String[] args) { final Fred fred = Fred.A; System.out.println(fred.getClass()); final Field[] fields = fred.getClass().getDeclaredFields(); for (int i = 0; i < fields.length; i++) { System.out.println(fields[i]); } System.out.println(fred.ordinal()); System.out.println(fred); fred.setOrdinal(3); System.out.println(fred); System.out.println(fred.ordinal()); } }

The result?

class Scratch$Fred public static final Scratch$Fred Scratch$Fred.A private static final Scratch$Fred[] Scratch$Fred.$VALUES 0 A Exception in thread "main" java.lang.Error: java.lang.NoSuchFieldException: ordinal at Scratch$Fred.setOrdinal(Scratch.java:29) at Scratch.main(Scratch.java:47) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at com.intellij.rt.execution.application.AppMain.main(AppMain.java:78) Caused by: java.lang.NoSuchFieldException: ordinal at java.lang.Class.getDeclaredField(Unknown Source) at Scratch$Fred.setOrdinal(Scratch.java:20) ... 6 more

So the fields in java.lang.Enum are not real but are synthesized by the JVM. Too bad. I wanted to write a runtime-extensible enum, but it looks like I am out of luck.

Also, it looks like there is no reasonable way to do this and support switch. Either I have to do something like:

switch (fred) { case A: doA(); break; default: if (fred.ordinal() == 3) do3(); else dieDieDie(); }

Or it gets really messy:

private static final int ZERO = 0; private static final int THREE = 3; public static enum Fred { A(ZERO) } public static void play(final Fred fred) { switch (fred.ordinal()) { case ZERO: doA(); break; case THREE: do3(); break; default: dieDieDie(); } }

Not nice at all.

The C++ Source

The C++ Source is a new, online C++ journal. More is better (usually).

A page about call/cc

An excellent page on call/cc. If I spent all my time reading about Java I'd quit programming and go back to writing classical music.

Audit history with Hibernate

Christian Bauer at Hibernate posts a very interesting technique for object auditing with Hiberate in combination with database triggers. How useful is this?

Interruptible queries with Java

ONJava.com has a nice article with clean examples of several techniques, Interruptible Database Queries. The clean code includes:

public synchronized ResultSet executeQuery(Statement statement, String query) throws SQLException, InterruptedException { // Set query parameters synchronized (params) { params.statement = statement; params.query = query; params.pending = true; params.notify(); } synchronized (results) { try { // Wait for the query to complete while (!results.serviced) results.wait(); if (results.exception != null) throw results.exception; } catch (InterruptedException e) { cancel(); throw e; } finally { results.serviced = false; } return results.rs; } }

Read the whole article for the worker thread, cancel() and how to put it all together.

APIs

Norman Walsh has an intelligent, interesting post on APIs (in spite of the lame title).

Cellular automata and music from IBM

Big Blue is so much cooler now than when I was a kid. For starters, there's the whole Linux shop a few miles from me here in Austin. And there's stuff like this, Cellular automata and music, a fascinating article featuring the Automatous Monk.

And see the beautiful presentation, Things Computer Science Tells Us About Philosophy. Too bad the darn thing is some sort of PowerPoint presentation!

First-class threads in C++

A library package to provice threads in C++ as first-class objects. From the introduction:

The main goal of RT++ however is to provide a programming interface which is considerably higher-level than that of comparable packages. RT++ considers threads as an abstract datatype with a functional interface i.e. threads communicate only via arguments (which are provided when the thread is defined) and results (which are delivered when the thread has terminated). Threads can be used like objects of any other type i.e. they can be stored in data structures, passed as thread arguments, and returned as thread results. Functional programming languages are called higher-order if they treat functions as first-order objects; we call RT++ higher-order because it treats threads in this way.

And:

RT++ provides a thread/memory management system where programmers need not care about these low-level issues. Thread resources are implicitly allocated as late as possible and implicitly freed as early as possible regardless whether or how often the thread result is retrieved. Threads are subject to garbage collection and automatically reclaimed when not referenced any more. RT++ also provides type constructors for arrays, lists, and general pointer structures whose objects can be passed by reference among threads and that are subject to automatic garbage collection. A high-level notion of non-determinism is supported via thread bags which retrieve their result in the order in which they become available and thus allow to write more abstract (and sometimes more efficient) parallel programs.

This is one reason I prefer C++ to Java for some of my programming — choice. Try replacing java.lang.Thread.

See your garbage, smell your garbage

Moazam Raja points out an interesting tool for watching garbage collection in a running program in his post, Visualizing Garbage Collection. What a pretty picture:

Excellent C++ refresher

Once, Weakly is an excellent C++ refresher blog by Stephen Dewhurst. The only minus is that the posts are PDF files! Still, it is worth the nuisance.

More on delegation

Of course the word I was searching for yesterday was delegation. But there are three flavors of implementation inheritance given:

public interface Bob { void dodeedo(); }

Your basic class inheritance

public class Fred extends BobImpl { }

Typical delegation

public class Fred implements Bob { private Bob bob = new BobImpl(); public void dobeedo() { bob.dobeedo(); } }

Returning the interface

public class Fred { private Bob bob = new BobImpl(); public Bob bob() { return bob; } }

Only in C++ is the first very flexible by using a template parameter to vary the implementing base class. Most code I see does the second, but this falls down when you provide several interfaces, especially when they are poorly designed to fit together such as List and Map. The third is the most flexible and resembles interface discovery. One could code it that way:

public class Fred { private Bob bob = new BobImpl(); public Object discover(Class itf) { if (itf.isAssignableFrom(Bob.class)) return bob; else return null; // alternatively throw something like ClassCastException } }

But that is way overkill most of the time.