osmeditor2 to Java, and a common Java OSM client library (was:Re: [OSM-talk] Java and freedom)

[Nick Whitelegg]

>Petter, do you see any problems in the short term converting the applet
>into stand-alone static binary with GCJ? Making an optimised binary of
>Josm for GNU/Linux, Windows and OSX with GCJ would be even better,
>perhaps we can do that once we have Java 1.5 compatability.

This discussion has got me thinking about converting osmeditor2 to Java. I 
originally chose C++ as I had the following concerns about Java:

- performance on slower machines, as bytecode is produced rather than 
native code;
- dependence on a virtual machine;
- non-native look and feel;
- harder to communicate directly with a GPS. With a C++ solution I could 
use the existing "jeeps" library; no such library appeared to exist for 
Java.
- also, while I myself am not bothered about this issue, a number of 
people raised concerns about the requirement for non-free software in the 
form of the Sun VM.

However, with the merge of gcj/Classpath and AWT many of these problems 
appear to be resolved. Native binaries of AWT GUI applications with a GTK 
look and feel seem to be possible with the current gcj. gcj is designed to 
link with non-Java code, being part of the GNU toolset, so it should be 
possible to link the jeeps library (written in C) and the 
contour-generating code (C++) with Java code using gcj.

It also could mean that a common set of Java classes - compatible with a 
range of VMs - could be developed for communicating with OSM. osmeditor2, 
JOSM and the applet could all use those. I'm not very keen on the "one 
editor to rule them all" idea, as I think each editor fulfills a slightly 
different purpose, and I would very much like to continue to develop 
osmeditor2 as "my idea" as to what I would like out of an OSM editor. 
However, common libraries a la the "Dao" ruby class on the server-side 
would obviously be beneficial to all; and some interchanging of code 
between the applet and osmeditor2 would benefit both.

So what I will probably do (unless I get negative feedback from people, or 
do not have the time) is put osmeditor2 into feature freeze until July 
(when I will have much more free time than I do now), and then convert it 
to GCJ-compatible Java. It might also be good if everyone working on 
editors could collaborate on a common library to represent the data model 
(the Nodes, Segments, Ways etc) and server-communication.

In the meantime, I will focus my efforts on the server-side renderer and 
(hopefully) try out some AJAX stuff too.

Feedback welcomed...

Nick