Starting out on Android

Oohhh, it's been a while since I've posted. I spent some time working on haskell-ide-engine, but then I got Haskell fatigue and decided to look at Android instead. A change is as good as a rest!

Coming from the Java world, it's not difficult to get into Android. I followed the guide on the Google site to get the basics. At first I got a bit afraid of the unholy mix of Gradle build scripts, visual layout editor, XML files and Java code, but you get over it. The IDE has some nice touches and it's good to get useful autocompletion in resources like ids and strings. I liked the warning about SDK level APIs and missing resources once I started translated my app into French.

But I have to say, when I was working on EclipseFP I often ran into IDEA fanatics that swore that IDEA was miles ahead of Eclipse. Android Studio famously moved from Eclipse to IDEA, and frankly, I don't see what the hype is about. Yes, Eclipse has some annoying bugs and idiosyncrasies. But Android Studio, at least with the default settings, as I haven't spent much time customizing it, is not such a wonderful IDE. It's slow to start up, the view layout is sometimes confusing, the font is too fine or small in places (I must be getting old, but sometimes I couldn't see that a semi colon was in fact a colon) and the warning/error markers in the gutter are way too small and nearly invisible, to the point that sometimes the build fails and I can't see where in the source is the error! Maybe there's a special "grumpy old man with failing eye sight" setting to make things bigger.

Since I believe that you learn by doing, I've developed my first app, and I'm in the process of publishing it to the App Store (so I can claim I'm a published Android developer in my CV, wink). Apart from the fact that you need to supply an icon in 2 million different sizes, which is challenging for somebody with my artistic abilities, it's a straightforward process. My app is an uninteresting workout log app (to record how much weight you supposedly lift at the gym) that's purely local (no social features, so you can't boast online about the weights you may have lifted), but hey, it's a start. The code is of course on Github.

I've also wrote a basic game using the framework presented here, and the nice asset from Kenney (see note about artistic abilities above). Nothing fancy, just a rabbit hopping over holes and getting carrots for points, but just seeing my little game running on my family's phones and tablets is nice! It's on Github too.

A Reddit clone (very basic) using Local Storage and no server side storage

Some weeks ago there was a bit of a tussle over at Reddit, with subreddits going private in protest, talk of censorship, etc. This was interesting to see, from a distance. It got me thinking about trying to replicate Reddit, a site where people can share stuff and have discussions, but without having the server control all the data. So I've developed a very basic Reddit clone, where you can post links and stories and comment on them. You can also upvote stories and comments, and downvote what you upvoted (cancel your upvote). But there's a catch: the site has no database. Things are kept in memory, and on the users machine, via the HTML 5 LocalStorage. That's all!

Everytime you upload or upvote something, it gets saved to your LocalStorage for the site. Once something gets downvoted to zero, it disappear. When you go to the site, whatever is in your LocalStorage gets uploaded and upvoted again. So stories can come and go as users connect and disconnect, and only the most popular stories will always be visible on the site (since at least one connected user needs to have uploaded or upvoted a story for it to be visible).

Of course, there is still a server, that could decide to censor stories, modify text, but at least you can always check that what you have on YOUR machine is the data you wanted. you can always copy that data elsewhere easily for safe keeping (browser developer tools let you inspect your LocalStorage content).

All in all, this was probably only an excuse for me to play with Javascript and Java (I did the server side in Java, since it was both easy to build and deploy) and Heroku. I've deployed the app at https://fivemegs.herokuapp.com  and the source code can be found at https://github.com/JPMoresmau/5megs. Any feedback welcome!

Heads-up: EclipseFP moving to Java 1.6

Up to now EclipseFP kept Java 1.5 compatibility. Java 6 does not bring that much in terms of API so I was happy to keep it that way. However, I moved a few months back to Eclipse Indigo and since then I've had problem generating the plugin code. I have the feeling that exporting plugins compiled with a 1.6 JDK in 1.5 compatibility mode didn't work well (ending up in errors like "class java.lang.Object could not be resolved", which is scary enough in Java). So I bit the bullet and changed the compatibility level on all plugins. They do now require 1.6.
This change will come in EclipseFP 2.2.4 which I think will be released pretty soon (next week maybe) with a few minor enhancements. So if you were still stuck with Java 1.5, get ready to move... I suppose it will not affect many people anyway, but I'd rather warn in advance to avoid nasty surprises...

GUI Testing using OCR: project Sikuli

I had a great idea this morning... and then realized that there was an open source project already doing it.
I thought: instead of using specific testing frameworks for each UI technology I have (a tool for the web, a tool for SWT UIs, etc) what about a tool that could recognize the text on screen and click or type in the proper places. The same technology for everything type of UI, and something that doesn't rely on pixel perfect positioning to work! Turns out (surprise!) I'm not the first one that had the idea, and looking around I stumbled on Project Sikuli. This looks great: it uses images to find "interesting" parts of your UI and there's also support for text recognition. So potentially you could say "click on the button that says 'Submit'"! It integrates with Java code so you can easily have JUnit tests using it.
Unfortunately, for my own purposes I couldn't get very far easily because of lack of support for transparent images (or, more precisely, it takes into account transparent areas for images, so it doesn't recognize an image if the background changes, which happens if your desktop theme changes, if you use the same icon in different contexts in your UI, etc). But it still looks like a promising tool!

Haskell + FFI + Java + SWT: crazy, maybe, but working!

A few years ago I noted that being able to mix Haskell code and a Java GUI might be a good idea, since Java UIs have matured enormously, and Haskell UI library are still struggling to gain wide adoption, a recent thread on cafe being proof. SWT bindings were mentioned, so I had a look at both the Java and the C SWT code, for windows. Two immediate things sprang to view:
1. The SWT C library is using JNI, duh. It relies on JNI for some operations so you can't just use the SWT.dll in your haskell code that easily
2. The SWT C bindings are very low level, and there is a wealth of Java code on top of that to provide a lot ow glue and boilerplate code for all kind of widgets, and it would be long and painful to rewrite it all in Haskell.

My Java to Haskell code converter only being a dream at the moment (one day...), the next reasonable (ahem) option was then obvious: start a few blown JVM from Haskell and use it to drive SWT classes.
I'm a Java expert, I can say, and my Haskell is slowly coming on, but the glue in between has to be C, so it wasn't a smooth ride, but I finally got it working! So what's happening is this:
- The Haskell applications starts as they all do, in a main :: IO() function
- Haskell invokes some C code that starts a new JVM, passing it a classpath. The C code acts then as a facade hiding some of the intricacies of accessing the JVM
- Haskell uses the foreign C functions to create ands manipulate the SWT Java objects
- I even got callbacks working, meaning you can register a Haskell listener on a SWT button, and hence have Haskell code calculate the results of that button click.

And I have proof! Here's a simple SWT Shell with one button:

When you click the button:

And the handler for the button click is written in Haskell (I have a MVar called count for the number of times the user clicked):

do
    modifyMVar count (\c->do
        let nc=c+1
        let s=if nc==1 then "once." else ((show nc)++ " times.")
        text3<-toJString ("Clicked "++s)
        voidMethod button "setText" "(Ljava/lang/String;)V" [JObj text3]
        return(nc,())
        )

You can see here the invocation of the setText method of the SWT Button, which for the moment requires knowing the exact JNI signature, and the translation from Haskell strings to Java strings.

Of course, there is still loads to do. I probably need to automatically generate bindings to the Java objects to simplify greatly their manipulation, wrap stateful operations in a monad, etc. But this may open a new way for Haskell GUI. Or it may just be a crazy idea that has already taught me a lot about FFI and JNI...

Releasing my code on the unsuspecting public (EclipseFP)

Today I've released a new version of EclipseFP (Haskell support in Eclipse). There are quite a few changes in it, and there are even some changes in the Scion library that I've made and that Nominolo integrated. So people can give it a try if they want: get the current Scion source code, build/install it, and get the 1.108 version of EclipseFP.
Hopefully that's another step for me in getting more proficient in Haskell: interacting with other Haskell hackers, learning from them and their code, and releasing code that may actually been of use to somebody (or annoy them no end if it doesn't work) instead of only a little game as before. And of course working on an Haskell IDE, even in Java, gets me to learn new things about the language, the options for Cabal or GHC, etc...
Anyway, I hope I'll get some feedback on the new EclipseFP, and that we can move that thing forward!

Haskell development in Eclipse

I have started contributing to the eclipsefp project. For those who don't know, it's a Eclipse-based environment for developing in Haskell.
EclipseFP has had a troubled history so far. Leif started the project and developed an impressive set of features. He then pursued the Cohatoe project to be able to write Eclipse plugins inm Haskell, in a effort to avoid rewriting in Java all kind of things that already existed in Haskell. And then this summer Thomas started integrating with Scion, which is a Haskell library that communicates with JSON data over simple sockets with non Haskell clients. Scion offers method to load Cabal projects, type check files, etc... That work is not finished, but Leif and Thomas have done such a great job that it's easy enough now to finish the missing bits here and there.
This is perfect for me: part of the work is in Java and Eclipse, which is a lot of what I do in my day job, so I can bring a lot of experience there. Scion is a small enough library that need to be extended to provide me with all I want, so I can do little enhancements in Haskell and slowly build on features. And, last but not least, I need to learn the GHC API (which is what Scion uses to parse, check and compile files), to find what I need for.
This will only enhance my knowledge of Haskell, and I hope that I'll be able to make something useful to provide Haskell hackers with another IDE to develop in.
For those interested, the github repositories where my current work can be found are:

git://github.com/JPMoresmau/scion.git
git://github.com/JPMoresmau/eclipsefp.git

Me and my compiler

Pfiuu, long time no post, between my day time work, playing with Haskell and Lispy things (cool sutff like Clojure) and my extra-programming activities (yes, yes)...
I was just thinking about dynamically vs statically typed languages, since there is a lot of discussion about that on the web these days. For example, this article talks about refactoring in both static and dynamic languages. Well, I'm not a huge fan of all the refactoring utilities Eclipse give me, but there's one feature I use a lot: you know, when I change something, like the return type or the arguments of a method, my IDE helpfully adds little red crosses on all the source files that won't compile any more. So then I go through them and adapt the code.
Of course in a dynamically typed language I wouldn't get that, but since everybody has 100% code path coverage in their unit tests, it's just deferring the red cross marking a bit lower than the chain, right? Well, at work it takes 30 minutes to build our whole software from SVN (and only a few seconds to rebuild one individual module from inside Eclipse), and several hours to unit test everything (and have we got 100% test coverage?), so... Methinks I'll stick with something that can check that my types are coherent for me when I work on big projects...

Haskell syntax is not Java syntax; good or bad?

In this blog, the author expresses the opinion that an important part of a language popularity: Java was successful because it looked familiar to C++ developers, and similarly new languages should use Java syntax. This struck a chord: after all, I have started writing a pure functional language using Java syntax. I thought that having a similar syntax would help grasping the language better. But now I wonder. Not only do C++ and Java share a similar syntax, they also share some concepts (objects, etc...). If a language is intrinsically different (like a pure functional language with monads, say), then having a different syntax tells you straight away: warning! This is different, so not only you must learn a new syntax, but you must also learn a new way of programming.
So maybe having Haskell using a totally different syntax is A Good Thing. And it gives me a nice excuse to stop trying to create my own little language that looks a bit like Java but doesn't act like Java and concentrate on writing Haskell code.

Java and higher order generics

Funny coincidence: yesterday in work I was trying to find a way to express something simple enough in Java: I want a method map that takes a generic collection and return a collection of the same type (that is, passing a List should return a List, passing a Set should return a Set) with a different generic type. In Java you can have:

public <T1,T2> Collection<T2> map(Collection<T1> c,Mapper<T1,T2>

Where Mapper is an interface defining the method T2 map(T1 o);
There is no way I think in Java to express that if you pass a subclass of collection you get the same subclass back.

I tried things like <T1,T2,C extends Collection,C1 extends C<T1>,C2 extends C<T2> and other crazy things that my compiler didn't appreciate.


You have to duplicate methods, and that's what we've done in work:

public <T1,T2> List<T2> map(List<T1> c,Mapper<T1,T2>
public <T1,T2> Set<T2> map(Set<T1> c,Mapper<T1,T2>

And of course a colleague needed a Vector because he was using an old library still using Vectors...
And then today I found that blog post, that point to that PDF document. Apparently you can do this kind of things in Scala and Haskell... Do I need to convince my company to move to Scala?

Structure of a functional Java, er, method

A method in FLOJ (remember, the functional Java based language I'm toying with) has a simple structure:
- a method definition 100% similar to a normal Java method: visibility generic return-type type parameters.
There are no exceptions, of course, since exceptions are things Best Done in Monads, once I've figured out
out I'll implement monads.
- a series of assignments of the form x=e where x is a variable name, and e an expression
- a return expression

For example:

public static String[] testMap(){
   a=["toto","titi"];
   a.map(String.toUpperCase);
}

Since the return expression is always the last expression, there is no need for a return keyword, but it's accepted by the parser. In the exemple above, the method returns the list of String TOTO and TITI.
Note also that the assignments do not allow nor require the type definition of the left hand side of the assignment. The type is inferred from the
return type of the right hand side expression (in the exemple above, a is a list of String). It's not as powerful as the full blown Haskell type inference but at least it saves some typing.

Of course, the generated Java code will add a sneaky final keyword to all the assignments, to enforce the fact that there's no variables in a functional language.

All in all, that structure makes the code easy to read and to understand: the sequence of calculations and the final expression yielding the method result.

I don't think my FLOJ language will ever be a full blown industrial-strength language, but I know that by implementing my own functional language I will learn a lot
more about functional languages than by just using one. Just implementing method pointers, type inference, combinator parsers and such, I understand more the why and how of Haskell.

A simple functional structure in Java

I have progressed a little bit in creating a functional language on top of Java, code name FLOJ (Functional Language On Java (-:). For the moment I'm only working on single files (I have a working parser), on the simple language constructs.
It's really interesting, because looking at very simple things make you think in depth about some issues that you may not really consider in Java proper. For example, this is the definition of a very simple structure:

package fr.moresmau.jp.floj.samples;

public class Simple(String data,int port){

}

So you can see that the package system is Java's and class definition are very similar. There are no constructor, so. Since null are not allowed (nulls are a huge source of bugs, I'll provide a Maybe object or something like that later),
the structure must have all its data filled in. If you want different operations to be done, you just create static functions that take parameters and create what you need, no need for several constructors. So the list of fields is entered straight after the name of the class.
Simple is a structure with a string and an int. It's easy enough to generate the constructor in Java:

package fr.moresmau.jp.floj.samples;

public class Simple{
 public final String data;
 
 public final int port;
 
 public Simple(final String _data, final int _port){
  if(_data==null){throw new NullPointerException("_data");}
  this.data=_data;
  this.port=_port;
 }
... 

The fields are immutable of course, so we don't bother with a getXXX() method, we just expose the field.
And you can then add setters that return a new object :

... public Simple setData(final String _data){
  if(_data==null){throw new NullPointerException("_data");}
  if (_data.equals(data)){return this;}
  return new fr.moresmau.jp.floj.samples.Simple(_data,port);
 }
 
 public Simple setPort(final int _port){
  if (_port==port){return this;}
  return new fr.moresmau.jp.floj.samples.Simple(data,_port);
 }
...

Note the null handling is not ideal, left for later. Note also we avoid superfluous creations if the data will not change.

So far, so good.

Then I decided to implement equals, so that equals is based on the data and not pointer equality:

...
 public boolean equals(final java.lang.Object o){
  if (this==o){return true;}
  if (o instanceof fr.moresmau.jp.floj.samples.Simple){
   fr.moresmau.jp.floj.samples.Simple co=(fr.moresmau.jp.floj.samples.Simple)o;
   if (!this.data.equals(co.data)){return false;}
   if (this.port!=co.port){return false;}
   return true;
  }
  return false;
 }
...

And with this of course the problem of overloaded equals method raises its head. If I want to allow subclasses to add more fields, my equals method won't work for subclasses.
If I check the exact class name in equals, subclasses that only add/overload methods will not be equals to superclasses.
So what can I do? I haven't decided. I could forbid subclasses to define more data fields (that's I think what you have in Haskell: you inherit functions from your type classes but no data).
I could also make the equals method final and not generate it for subclasses, but equality would then ignore the additional fields.
Another option would be to check the class name in that equals method and generate the proper equals method for all subclasses, but that may cause problems if we then extends the FLOJ class by a Java Class (which will be possible since we generate Java code).
But maybe it should be so, that a class is never equals to its subclasses? Returning equals between two instances that have the same data but different behavior (one instance has an overloaded method) is probably an error in the OO world...

Anyway, creating your own language is fun, I'm learning a lot and maybe I'll even end up with something usable!! I'll keep you posted on my progress.

Generator (with yield) in Java

For some reason I was thinking about generators and the yield function (as found in Python). All this functional talk about infinite lists and such I suppose... So I had a go at implementing one in Java, which tied in nicely with my current reflexions about a java-based functional language and the need to provide concurrency out of the box. And another occasion to dabble with wait and notify in Java! After I've written it I found a similar looking implementation (but without the standard Iterator/Iterable interface support) and something on Google code that use bytecode intrumentation (why oh why). But still I like mine, that you can find here (and the unit test is here).
Basically the work is done in another thread and we call wait() when we do a yield. We conform to the Iterator and the Iterable interfaces, and we provide a stop method to actually stop the thread (say for infinite generators). Otherwise if the generator has not finished the thread goes on waiting forever. I've thought about trying to stop the thread when the generator is not used, but I don't know if it even possible with things like SoftReferences (The thread having a pointer to its runnable...).

My own Java-based functional language

I've been toying for a while with the idea of creating my own Java based functional language, if only to be able to see first hand the challenges in creating a functional language. The language I envision has the following characteristics:
- syntax close to Java: contrary to JHaskell or CAL, I want something that looks like Java, not something totally different
- Java type system: use the normal Java OO type system: classes with at most one superclass, interfaces. Maybe I'll run into issues but for the moment...
- pure functional and monadic: what I love in Haskell is the clear delimitation between what's purely functional and what's subject to side effects (IO, etc...). I'd like to have that in my language. I know about Scala, but Scala lets you mix functional and imperative code, I want something pure (and I don't like to add new very un-Java like keywords like def)!
- Java integration: there is no point of being implemented in Java if we can't reuse the wealth of Java code and libraries out there. Probably I'll need a way to distinguish somehow functional Java code (like the String methods) and not functional code, and wrap access to non functional code in a monad.

Now that's an ambitious program!! I've started some parsing and conversion to Java source files (hey, if Java can do some of the type checking for me...), but it's going to be a long road...
Of course, if such a language already exists, I'd be delighted to hear about it!

Parser Combinator in Java

Pffuii, I'm quite busy these days, hence the posting frequency has dropped. I'm in the process of playing with a functional Java based language (more on that in later posts, hopefully) and I decided to have a go at a little parser combinator in Java.
The end result works (I can parse things like Java class declaration) and looks a lot like parsec, but there is a lot of Java cruft that I'd like to remove, things that are hidden with the wonderful magic (I don't understand it well enough to call it otherwise) of Haskell monads.
For example:

try {
Character c=new Try(new Letter()).parse(input);
...
} catch (JCParseException jpe){
...


This code tries to match a letter in the input at its current position (the input variable) and does not consume any input if it fails. I don't like having to explicitly tell the combinator to parse the input, and I don't like using exceptions to indicate a parsing failure. Now, anybody has any great ideas?

Poor man's JavaFX Script is, er... Javascript

Sun has release its own RIA framework called Java FX. It provide JavaFX Script, which is a language based on Java whose goal is to develop quickly graphical applications with the power of Java. Is it touted as competition to Flex that I have mentioned before. It is safe to say that it hasn't been received with a great deal of enthusiasm. The fact is, I don't want to learn another language again to do my Web 2.0 application. And I do believe that Fielding has a point when he reflects that applets break visibility and raise the barrier of entry for web developers. Also, I'm usually all in favor of static typing and compilation, but for GUIs I'm not too sure. When you want to tweak your borders or your layouts you probably happy enough with a quick cycle of change code/refresh page. So why don't we use Javascript and Java Applets together instead of inventing yet another technology?
Ok, it's time you get over your irrational distrust of Javascript. A multi paradigm (object, functional) language available for free in every browser!! And no, I don't suggest we go on using the HTML DOM or things like that. That's why we need applets.
Applets? I must be mad! Applets have not worked on the web. But what I suggest is not to develop one applet for each RIA application, but only develop one Applet that everybody could use, much like a plugin, that would bridge the gap between the JavaScript world and the Java/Swing world. If it has been done, please let me know. As for me, I've put together a prototype in an hour that works fine:

1. The JavaScript code constructs an object tree that represents the GUI.
   
2. The object tree is serialized to JSON and passed on to the applet
3. The applet deserializes the JSON and constructs a Swing GUI by translating the object tree
4. The object tree can contain handlers that are the names of Javascript functions
5. The applet calls the javascript functions on Swing events
6. The JavaScript event handlers update the GUI tree and notify the applet with the changes.

A very simple example:

<html>
<head><title>JSApplet</title>

<script language="Javascript">

var helloButton={type:"button","id":"helloButton","text":"hello","action":onClickHello}
var frame={"contents":
 [
  helloButton
 ]
 };


function onClickHello(){
 helloButton.text=helloButton.text.toUpperCase();
 updateJS([helloButton])
}

function startJS(){
 var msg=document.getElementById("JSApplet").setContent(toJSON(frame));
 if (msg){
  alert(msg);
 }
}

function updateJS(objs){
 var msg=document.getElementById("JSApplet").updateContent(toJSON(objs));
 if (msg){
  alert(msg);
 }
}


toJSON=function(arg) {
    
    switch (typeof arg) {
    case 'object':
        if (arg) {
            if (arg.constructor == Array) {
                var o = '';
                for (var i = 0; i < arg.length; ++i) {
                    var v = toJSON(arg[i]);
                    if (o) {
                        o += ',';
                    }
                    if (v != null) {
                        o += v;
                    } else {
                        o += 'null,';
                    }
                }
                return '[' + o + ']';
            } else if (typeof arg.toString != 'undefined') {
                var o = '';
                for (var i in arg) {
                    var v = toJSON(arg[i]);
                    if (v != null) {
                        if (o) {
                            o += ',';
                        }
                        o += toJSON(i) + ':' + v;
                    }
                }
                return '{' + o + '}';
            } else {
                return;
            }
        }
        return 'null';
    case 'unknown':
    case 'undefined':
    case 'function':
     return arg.name;
    case 'string':
        return '"' + arg.replace(/(["\\])/g, '\\$1') + '"';
    default:
        return String(arg);
    }
}

</script>
</head>
<body onload="startJS();">
<applet id="JSApplet" alt="JSApplet" code="fr/moresmau/jp/jsapplet/JSApplet.class" codebase="bin" mayscript="mayscript" height="100" width="100"></applet>



</body>
</html>

This web page creates a simple "Hello" button that when clicked changed its text to upperCase(). It demonstrate the two ways communication between the Javascript code and the applet (note how the function is serialized in JSON just with its name, that's the only thing we need). So the Javascript can deal with a model that is a slightly abstracted Swing model (no more hair pulling between different browsers). I stress again, the applet is a generic applet that deals with the link between the JSON objects and the Swing layer. Of course the applet could offer other services: simple API to call back the server (AJAX from the applet), etc...
Then the applet could be packaged with a cut down version of the JRE (only the classes really needed) as a plugin to do rich Swing application from JavaScript...
And voilà! A scriptable RIA platform!

Haskell code, Java UI

It's been while since I've posted anything, mainly because work crises and holidays have kept me busy or away from my keyboard. I'm still playing with Haskell and user interfaces, I've now developed the same Maze game in HGL, Flex with a Haskell web back end, and WXHaskell. I've looked at trying to implement some declarative syntax that would simplify WXHaskell code but haven't gone very far, I think I'm trying to run in Haskell before I can walk straight!
Anyway, I was looking at Business Objects' Quark framework based on the CAL language. You can find more details here, but basically CAL is a Haskell-inspired impure functional language implemented in Java, that can use Java classes and methods. The impurity comes from not using monads to access Java, if I understand well, which means that you can declare pure functional methods that in fact access Java objects, that can do all kind of stateful voodoo under the covers. While I'm not sure this is really A Good Thing, having Haskell and Java intertwined brings some interesting ideas in the realm of Haskell UIs. Swing and Java are now mature, reasonably fast and cross platform. If I can get my pure Haskell code to talk to a Java GUI, I could get quite happy indeed...

Dynamic class behaviour in Java

In a previous post, I was using annotations to generate method pointers in Java. The functions objects were generated in a separate class file. However, if you suppose that a modern IDE would be able to generate all that code for you when you create a method, you could have the function object in the same class file as the method code itself. Since Java allows you to have a field and a method with the same name, everything works fine.
In that previous post the function object referenced the actual method in the original class file. What if we did the opposite, that is to say, the actual code is in the function object, and the method merely delegates? Here is a trivial example:

public class StringHelperDynamic {

    public String toUpper(String a){
        return toUpper.run(a);
    }
   
    public Function1 toUpper = new         Function1 (this){
            public java.lang.String run(java.lang.String a) {
                return a.toUpperCase();
            }
        };
   
}

Here, we have a toUpper method that takes a String and return a String, and a toUpper function object that we can pass around, perform currying on, etc... the interesting twist of this architecture is that the toUpper field can be final or not. If not, we can then change it at runtime, and hence change the behaviour of the class at runtime, while still calling the same methods. Who needs a dynamic scripting language (-: ? To the silly example:

StringHelperDynamic me=new StringHelperDynamic();
me.toUpper=new Function1(me){
    public java.lang.String run(java.lang.String a) {
        return a.toLowerCase();
    }
};

assertEquals("hello",me.toUpper("HELLO"));

OK, breaking the contract of the method is NOT what this is about, but you get the gist of it. The code for the Function1 class can be found here.

VList in Java

Two days ago I was reading this article about LISP like lists implemented in Java,
which reminded me I had written an implementation of a VList in Java. It can be found
here, along with a unit test.I make no garantee this is the best or fastest implementation possible!

It implements: get(n), first (head in Haskell), rest() (tail in Haskell), size(), iterator() and map(Mapper), where Mapper is the mapping interface I mentioned earlier.

It's using Java Generics of course. Am I right in thinking there is no way with Java generics to get rid of the compilation warnings and of the necessity of passing the Class object in the code that creates a new array of the generic type?

Java properties with no language changes (oh no!)

There's been a lot of discussions on the web about Java and the support for bean properties. People would like to have a mechanism that relies less on java bean conventions (reflection on method names, find getters and setters) and more on explicit language constructs. The goal is to simplify bean and property handling, have stronger type checks, be able to reference the property and not its values, etc... Most proposals involve additions to the Java syntax. I don't want to add to the confusion, but I just played around with what we have now in Java 5.
What we could have is instead of defining classes directly with fields in them, we could have them reference Property objects instead. Property objects carry the type information and the value itself. An inheritance hierarchy can provide for read-only, write-only and read-write hierarchy. Using public final fields we can have an access syntax that is not the same as the current getter and setter methods, but pretty close.
Example:

public class PersonBean {
    public final IFullProperty name=new NonNullProperty();
   
    public final IReadProperty id;
   
    public final IFullProperty email=new FullProperty(){
        @Override
        public void set(String value) {
            if (value.indexOf('@')==-1){
                throw new IllegalArgumentException("email does not contain @");
            }
            super.set(value);
        }
    };
   
    public PersonBean(int id,String name){
        this.name.set(name);
        this.id=new ReadOnlyProperty(id);
    }
}

Of course, the generic madness means the type information has to be typed twice, but when generics syntax is cleaned up it'd be a lot more readable. This bean says that it has a changeable name property, a String that cannot be null. It has an id integer property that cannot be changed. Finally it has an email property that has ad hoc constraint checking. The Property interfaces and its sub interfaces define a get() and a set() method so accessing the fields becomes:

bean.getName() -> bean.name.get()
bean.setName(name) -> bean.name.set(name)

The property change listener can be attached to the property object so that the bean doesn't have to have any line of code related to listeners. Everything can be done via static methods:

static void addPropertyChangeListener(Object bean,PropertyChangeListener pcl);

to add a listener on all properties

static void addPropertyChangeListener(Object bean,PropertyChangeListener pcl,IProperty p);

to add a listener on a specific property. Note that since we're taking a property object, and not a property name for example we cannot register a listener on a non existing property. The property does not have a back link to its bean (to avoid disgracious constructors with this), so we need to have both the bean and the propert.
Example:
addPropertyChangeListener(bean,listener,bean.email)

If anybody's interested, all the code with unit tests is available here.