🚀 go-pugleaf

Hey there everybody !

Despite the high trafic in comp.lang.java, the kind of question I'm
gonna ask seems to have disappeared. I hope that means a lof of
people have made their experiences and want to share their
conclusions.

We have a Macintosh application for a specialized engineering domain
that we use in our school department for teaching and research. We
could also sell it to real-world people, except that most of them
have real-world computers. In other words, this is just another
multiplatform-wannabe story. (PC and Mac)

Since we still add features, we want to keep as much code in common
as possible for both platforms. The old-fashioned (but reasonable)
solution is to use a (more or less multiplatform) API framework. The
new solution is, guess what... java.

I've met a lot of people who are really enthusiastic about us doing
it in java, but mainly because it hasn't been done a lot before. :-/
The networking force of java is not an important argument yet,
although it could be nicely applied. (For example, the program is
routinely used for Computer-Assisted Learning, and remote CAL is an
issue)

So, before we trash some C++ framework solution in favour of java, I
would like to hear good reasons of doing so or not.

More precisely, given the application description that I will give
next, I would like to know whether java for this task (porting Mac
software to PC):

- is appropriate. 
- is worth the effort. (compared to the C++ framework solution)


I think answer to point 2 should be Yes, because the code is in
(slightly object) Pascal, and a major rewrite in C++ was planned
anyway.

For the appropriateness question, I will try to give both relvant
information to answer it and tentatives of (not really well
informed) answers when I have one. Since most people in my place
including myself are positive about java, I would be mainly grateful
for *pessimistic* answers and *horror stories* from people who
dreamt of a java project with similar characteristics and had to
move back to some "well-understood" technology. (the reason why I
cross-posted)


OK, here is my feature/argument list:



F. The program is 20-50k lines long (depending on how much we
initially port). 
A. Current java compilers aren't really fast 
OTOH, current java environments are already nicer than C++
environments ?

F. It has some relatively intensive computations. 
A. Native
compilers are on the way.

F. API too limited bec. common denominator. 
A. It is a specialized application, for people who don't know all
the MacOS features anyway.

F. API/IO too limited bec. security, even in "total trust mode"
A. ?


F. It has a MacDraw-like module, that must scroll and redraw a
dynamic content (but not animated). It's not a .gif download. The
scrolling speed MUST remain reasonable. We need to be able to do
pixel-level games. 
A. I've heard of a CAD project and of a MacDraw-like project 
in this newsgroup. How are these people feeling ?
I must also admit that I've seen CAD tools presented as the
archetype of what java cannot do at all (currently).


F. Internationalization. 
A. ? I guess relative paths to some
:swiss-german// directory would do the game. ? (If you make the
effort to not store strings in code of course)


F. Runtime memory requirements, are (much) higher and total mem is
limited by the runtime environment's  memory partition rather than
total available RAM. 
A. ?


F. The application reads and writes 3 kinds of files, with at least
one window per file. 
A. ?

F. There are interactions between the "documents". For example, new
documents of one kind are based on documents of another kind. 
A. ?


F. Java, its IDEs, its AWT, its available class libraries  will be
appropriate for this task, but not now. 
A. When ?


A last one, that I don't really need for this project:

F. Drag-and-Drop is nice. 
A. I think I've heard it's possible. How
will that interact with the java + OpenDoc wish of some people ??



That's it. Thanks for reading up to this point. If you have answers
or other issues you think we should consider, that would be nice if
you type now.


--Michel    <mailto:tourn@it.dgm.epfl.ch>