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

[Petr Nejedly]

Dirk Stöcker napsal(a):
> On Mon, 11 Aug 2008, Frederik Ramm wrote:
> 
>> Gerv also hinted at the fact that JOSM is written in a way that is
>> somewhat untypical for Java, and whenever a newcomer to JOSM programming
>> said "this is all bullshit let's refactor it wholesale" I told them to
>> please find another project to refactor wholesale. I always thought that
>> the peculiar way in which JOSM is done has a lot going for it and makes
>> it easy to work with the code.

When we're at it, I'm not sure the way josm is written makes it any easier
to work with the code. Using accessors is the standard way every java programmer
understands and the code clutter is not much of an argument.
Moreover, josm uses unusual L10N way (I must admit that for a reason this time,
though not a strong one) and unusual (and harder for anybody writing DataSet
modification actions, easier to break) undo system.

I would put it this way: josm-ng currently is mostly an experimental platform*
trying whatever is posible to do regarding memory usage, editing/rendering speed,
and currently rendering accuracy (my current, uncommited code has a provision for
defining rendering of relations and can even render holes in multipolygons,
not taking about different rendering available for different zoom levels,
all this real-time up to the dataset of size of germany.osm).

Some of my ideas can be backported to JOSM directly ("Storage" class, which is
a kind of HashMap with much smaller footprint), some with much more effort,
"thanks" to the way josm is written (keeping a bbox of ways, having all the
primitives stored in a QTree - the QTree approach needs the position writes to be
intercepted, public fields is a big no-no for this).

*) Well there are only about two unimplemented things preventing josm-ng
to be used as a real editor - server I/O (reader part is there, of course)
and tagging UI.

> BTW: I never would suggest or accept "major" changes. Every major change 
> can be cut in pieces and introduced as smaller changes. This means you 
> always have a stable working software compared to a large refactoring 
> period. You have to write some intermediary code, but that also means half 
> finished reworks (when the author no longer has time or interest) are 
> better than nothing :-)

Well, I can write a List implementation that would notify me about all the
content changes, so I can keep the Way's bbox consistent even w/o disabling
direct access to the Way.nodes field (and thus preventing patching next to
every josm source file for this step just to start optimizations), but for
other things (again thanks to the josm "openness"), such a large change
might still be the very minimal prerequisite :-(

When thinking of it now, I don't think starting josm-ng was a bad idea.
It allowed me to prototype my ideas quickly and some of the ideas can
still be taken from josm-ng and ported to josm.

I'd like to write a summary wiki page, but haven't had much time for it yet.
(writing documentation is much harder for us, programmers, than writing code ;-))
I'll try as soon as I return from vacation.
It might at least remove confusion and maybe help somebody porting useful things
from -ng or the other way around ;-)

-- 
Petr "Nenik" Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org
355/113 -- Not the famous irrational number PI, but an incredible simulation!