[josm-dev] Difference between JOSM and JOSM-NG

[Gervase Markham]

Frederik Ramm wrote:
> Hi,
> 
> Gervase Markham wrote:
>> By its very nature, it's impossible to tell how many more 
> 
> .. or less ..
> 
>> contributors
>> there would be, and how much better 
> 
> .. or worse ..

I think it's unlikely that moving code more towards standard Java-isms
and industry best practice would discourage developers from working on
it. I know you find this hard to accept :-) but best practice is best
practice because a large proportion of Java programmers over time have
discovered that it's the best thing to do for readability,
maintainability, etc., not because some arbitrary cabal is handing down
random decisions from on high.

Take accessor methods, for example. Without them it's hard or impossible
to use any of the Structural design patterns (Adapter, Bridge,
Composite, Decorator, Facade, Flyweight and Proxy) because they require
intercepting and controlling access to data. All of these patterns are
used in extending a class to do something it couldn't otherwise do. When
debugging, you can't easily find all the ocurrences where a particular
class variable is modified, or add in debugging code to log the value
every time it changes, or put a breakpoint on accesses. When
maintaining, you can't easily see in what circumstances the variable is
used (particularly if you have multiple variables of the same name which
are members of different classes) and you can't add constraints e.g. to
keep the variable's value in sync with another one, or prevent it being
set to certain forbidden values. If working on performance, because the
class used for internal storage is exposed to callers, you can't e.g.
replace a linked list with a hash for efficiency reasons, or decide to
lazily compute the value from other values.

This and other considerations mean that any book you read on Java best
practice (or any object-oriented language, for that matter) will
recommend that you make your variables private and use accessor methods.

Now here's the important point. You might say "OK, so if someone did
want to replace a linked list with a hash, they could implement accessor
methods in the relevant places at that point." But that changes the task
from a contained and testable performance optimisation in a single class
to a tree-wide change, which will also break 3rd party plugins who used
the "interface" of the public member variable. It's also harder to know
if the change is safe, because you have to read and understand the code
around every access to the variable to see if it's doing anything funny.
You have a whole bunch of extra stuff to test, and have to deal with the
breakage fallout. Multiply that up for each change of this sort you want
to make, and you can see why people don't start down that rocky road.
The "stop energy" barrier gets too great.

You're right, I can't magically produce more developers if you agreed to
let people refactor the code to match best practice better. But I can
give you some reasons why the average Java programmer will find diving
into the current JOSM codebase an unappealing prospect.

> But with JOSM-NG sitting around untouched by anyone but Petr himself,
> and this for the best part of a year, the argument that a properly
> designed JOSM would attract more programmers rings hollow. What JOSM
> currently needs most is a few people who share the responsibility, who
> make JOSM "their" project and who are willing to do more than submit the
> occasional patch. It seems to me that JOSM-NG, despite its clean
> architecture and technical superiority which I don't doubt for a second,
> has not managed to find these people either.

One reason perhaps is that open source projects are successful in
attracting developers when they already work (albeit imperfectly) for a
task. JOSM-NG is not yet even a basic OSM editor, because (as I
understand it) it can't return changes to the server.

Gerv