[josm-dev] Jumbo Patch

[Gervase Markham]

Frederik Ramm wrote:
> Hi,
> 
>> I have reached situations like this many times. My gut feeling is
>> that the JOSM core needs to be redesigned. Conceptually, in the
>> greater scheme of things, what JOSM does is not that complex and it
>> should be possible to come up with a highly optimized, extensible
>> core that does everything needed. If this where to go ahead, then it
>> would make sense to design this with OO principles in mind to make
>> it maintainable. If a new plugin or piece of code needs to hook into
>> something in the core in a non-standard way, then we add the
>> appropriate hooks into the core to allow this to happen.
> 
> This sounds like it would not make a lot of sense to keep anything of
> the existing code. It's more like saying "ok, JOSM was a good
> prototype and we have learnt some things about usability, now let's do
> it properly".

That would be going too far in the opposite direction. The benefits of a 
rewrite take a very long time to show up. You have to do an enormous 
amount of work to get back to where you were. The correct approach is to 
refactor - perhaps using SVN branches, to avoid too much turmoil in the 
main codebase which may have to be updated for e.g. a new API change and 
an interim release made.

A good example is the code for Bugzilla. Five years ago it was terrible. 
One guy started a rewrite, which fizzled; the rest of the team started 
cleaning up and refactoring, a process which continues today. It's now a 
lot better. The lessons to be learnt from the Mozilla rendering engine 
rewrite are, let's just say, disputed :-) But it's certainly true that 
they lost a lot of market share at the time by doing it, because they 
couldn't release a product for 3 or 4 years.

Automated refactoring support for Java in IDEs like Eclipse may well 
make the process for JOSM a lot more pleasant and fast. And JOSM is a 
lot smaller than either Bugzilla or Mozilla :-)

> On the other hand, if we re-write anyway, then we might just ditch
> Java altogether and do it in C++, or maybe simply use Merkaator as a
> start (don't know how well it is designed on the inside but it is a
> fast C++ app that compiles easily on Win, Mac and Linux which is
> probably enough for us). If people are really concerned about memory
> usage and such (as in "you can't keep a list of ways with every node
> as even the empty list will consume 80 bytes") there's just no beating
> good old C++.

I don't know anything about Merkaator. But I don't think that Java and 
good performance are necessarily mutually exclusive :-) We just need to 
be careful.

Gerv