Thus spake george973:
Hmmm. It all depends on which part of a multi-platform project you work
on. We always estimated that 90% would be platform independent and 10%
platform dependent but the effort would be 50-50 for both parts. We were
writing in objective-C so had ported the GNU compiler to each platform
(so avoiding problems where system X’s compiler optimises your code to
not working).
The basic problem is that nothing worth doing ports easy and anything
that ports easily is trivial.
The platform-dependent problems I’ve encountered in Java fall into two
categories: Some are due to the nature of the different platforms, some
are due to the JDK. I don’t believe we can eliminate the ones in the
first category, but the ones in the second category are unique to Java,
so we could avoid them by moving to any other language.
Don’t forget the Java implementation on any system stands on the image
i/o libraries for that system. The implementors of Java didn’t re-invent
the wheel. Any code you write will need to sit on the same libraries and
hit the same bugs possibly.
Actually, the implementers of Java did reinvent the wheel with
ImageIO. I know this because I’ve spent a significant amount of time
looking at the ImageIO PNG loader in particular to determine exactly how
it’s broken. This would not be a problem with libpng. Because virtually
everything else which loads PNGs depends on it, it has received intense
scrutiny over the years to make sure it works. When bugs are found, they
get fixed promptly. (Similarly for libjpeg, libgif, librsvg.) I don’t
have a collection of PNGs on which libpng barfs. I do have such a
collection for ImageIO.
Don’t forget the major testing headache. Now you can assume that Vassal
will run on 90% of machines which can install JRE but if you write in
C++ you’ll have to build it and test it on all possible environments
including old versions of MacOS and Windows and Linux.
Right now we have a problem which so far as I can tell, only occurs on
64-bit Windows 7. We’ve seen plenty of problems specific to old versions
of MacOS in the past. I don’t see that we can predict which OS-JRE
combinations will work now. This is not a win for Java.
You know it works on whatever you’ve built it on. Don’t forget most
users are not at the leading edge of Windows, Linux or MaxOS and their
machines have old libraries which may have old bugs. You’ll not be able
to carry your new libraries around with you as they may not work on
older software and/or installing them on older systems may break other
programs on the machine. Not to mention 64-bit and 32-bit version of the
libraries.
Except for Linux packages built for particular distribution versions
(where we can specify which lib versions we require), I intend that we
will ship our own copies of the libraries on which we depend. We won’t
be interfering with libraries already on the machine because we’ll be
bringing our own.
If you don’t want to wait for a bug to be fixed join openJDK and fix the
bugs there. They’ll get into mainstream Java and openJDK is porting to
Mac so you’ll have 1.6 on the Mac plus bug fixes.
Some of the bugs I’ve encountered have had patches in Sun’s bug tracker
since before OpenJDK existed, yet they are still not fixed. I’m quite
willing to contribute bug fixes to projects I use, but the JDK looks
like a bottomless pit to me. There’s a limit to the amount of effort
that I’m willing to invest in something that is not my project. Using
dependencies which already work is a more efficient use of our time
than fixing the JDK is. The fact that we’re having this discussion about
image loading bugs—bugs which you would expect to have widespread
impact—tells me that hardly anybody else uses Java the way we do.
- You’re underestimating just how much faster C++ is than Java when
working with images. The majority of the computation that VASSAL does
involves images. The C++ that I wrote for our V4 demo does everything
essentially instantanously; working with the same images in Java is
agonizingly slow.
I would hope so!! But if just speed was the goal would it be better to
go for Java Native classes for the bits that need speeding up
No, it wouldn’t, for reasons I’ll give below.
Don’t forget that no one writes a post on the forum to say his JRE
installation worked perfectly! You’ll get a very distorted view if you
take the forum posts to represent the general experience. There are
thousands using Vassal who’ve had little or no problem.
My point is that this shouldn’t happen at all. It’s a point of failure
introduced by Java, and a particularly difficult one to troubleshoot.
Do our users care if they are in a code ghetto? They just want their
modules to work. As they do now for the most part. The number of bug
reports is minimal compared to the number of games played on Vassal.
The impact on users isn’t direct, but it’s real. Less and less attention
goes in to Java on the desktop, so as time goes on, the user experience
will degrade relative to native apps. Java bugs have a real affect on our
users, not just on us developers.
The number of bug reports is always going to be small in comparison with
the number of occurances of bugs. The fact that we have bugs with 50+
reports tells me we have serious problems.
Hmm, to be a little cynical but perhaps realistics, I suspect someone
will be saying the same about your new design in five years time. A
design is only clean if you’ve thought everything out beforehand and
never extend it. In reality any program grows by accretion after its
initial release as users request thing never thought of which don’t
quite fit the design or do things with your product which the designers
never imagined - and with scripts the module developers will be able to
really go to town. Consider what has been done with traits which never
crossed anyone’s mind.
I don’t agree. When VASSAL was started, there wasn’t anything like it
out there. We have a much better idea of what’s needed now than at the
beginning. It might be the case that in the future, we’ll realize that
some of the design decisions in V4 were bad—but they won’t be the same
bad design decisions we’re saddled with now, and because I believe we’ve
learned from working on VASSAL to this point, I don’t believe they’ll
be worse. Moreover, it’s not just bad design decisions which I want to
correct, but also some pervasive bugs which we can be sure not to
reintroduce.
But I do agree with the major rewrite, just not with abandoning the Java
platform to do it.
Looking at the code even just quickly shows that it wasn’t written to be
multi-threaded and the layout of the packages etc is all wrong. So a
major rewrite is called for but this does not mean leaping into
something totally different.
A rewrite in Java only solves the problems in the codebase which are
not caused by Java itself. Rewriting in Java won’t solve the any of
the JDK bugs we suffer from. Rewriting in Java won’t let us get rid
of the 20k+ lines of code I’ve written in order to make it possible
to handle large images (none of which is necessary in C++). Rewriting
in Java won’t let us make the Module Manager and Player run in the
same process. Rewriting in Java won’t let us compile for something like
an iPad. Rewriting in Java won’t change the fact that Java frees the
programmer from doing memory management by forcing the user to fiddle
with heap settings. Rewriting in Java won’t add type punning for
arrays to the language, the lack of which forces us to do things like
make second copies of very large images when we need the data as a
byte array instead of as an int array.
I suspect the users would just like the new version to load existing
modules and save files without them having to re download new modules
(assuming you convert all those on the web site).
We could convert them on the site, but I was intending to provide a
converter that works from within V4 also.
I think you are making yourselves a lot of work going to C++ and I don’t
think you’ll reap as many benefits as you think especially for
portability.
The fact that we have a C++ demo which already works as a virtual
tabletop in under 2500 lines of code tells me that we won’t suffer from
the problems which have consumed our development time when working in
Java, and that we’ll end up with something far more maintainable.
I’m not claiming that portability will be easier than with Java, I just
doubt that it will be any harder. And it would have to be a lot harder
to eat up all of the other advantages I see.
–
J.
)