Toward truly portable apps

[Roedy Green]

Java tries to run under any OS, yet still has the problem in that it
is hosted on an OS that is not in the least interested in portability

Even if your program runs, everything else, e.g. scripts, installers,
hooks to look and feels, databases etc. have to be ported and
customised, especially installers.

Think about what would be needed for a truly WORA program where the
creators could safely pay absolutely no attention whatsoever to
platform individualities. The distributable runs on anything
supporting Java without any mods.

What would you need?

1. a Java based scripting language, or a way of doing scripts in Java
programs Batik-style, and a set of method calls to a script library,
and compiling just before use, like the old Burroughs WFL.

2. an installer that handled everything with platform-independent
specs. It might generate many different download bundles, but the
would be managed automatically in such a way the end user does not
need to figure out which version to download. That is the installer's
problem. It sniffs about on the customer's machine and downloads what
it needs, perhaps from many different sources. (Linux like, it manages
dependencies. You don't have to bundle everything in one atomic
bundle.)

3. A simulated file system, or augmentation of the base file system
with guaranteed meta information about each file, e.g.
mime types, dates, owners, permissions, hooks to appropriate
viewer/editors. Indication of who might be interested in this file.
Files, e.g. binary caches, would not show up on selectable file
listings for a word processor operator. Strict rules on which
programs may examine/modify which files, encryption, backup info,
icon for file type, for particular file, info on how active this file
is (useful to a defragger or human optimiser, or SSD cache manager).
The point is the information would HAVE to be there. A program cannot
fail just because some feature is not supported in some obscure
program. It's behaviour vis as vis case sensitivity would have no
wiggle room. It would support background copying, where a program
submits the source target, which is then logically treated as
complete, but just actually goes into a background copy queue for
efficient copy that optimises buffer size based on RAM availability.
see http://mindprod.com/jgloss/copy.html for other cleverness.

4. Ditto for JDBC. Nail that sucker down. No opting out of supporting
the core features or implementing them in some quirky way.
The spec should be as specific as the manual is now for any particular
product.

5. An app needs to be able to specify its character set of interest
and have any fonts not capable of printing it disappearing from
potential selection. There need to be a set of default fonts that
handle every printable Unicode glyph. When the OS knows the chars
that will be used, they could substitute more streamlined fonts
without anyone being the wiser. Please don't could printing the
not-available glyph as support, the way Java does now.

Applets and Java Web Start were a major leap in this direction, be we
really should not stop until Java apps appear to the end user just
like native ones.
--
Roedy Green Canadian Mind Products
http://mindprod.com
I can't come to bed just yet. Somebody is wrong on the Internet.