[kaffe] KeyEvent -> JDK 1.4 patch (And longer explanation;)

[Jukka Santala]

On Mon, 7 Oct 2002, Dalibor Topic wrote:
> That means we'd have to operate on bytecode level.
> There are many toolkits for such projects. I believe
> that's preferable to writing a java parser and doing a
> source-to-source translation on all java library
> source code.

Admittedly the preprocessor approach does have its disadvantages. However,
how do you do conditional specification on bytecode level, especially with
optimization? I guess you could just specify that optimization always
happens after the conditional selection. I still remain somewhat
suspicious; this toolkit would likely need to be able to generate
alternative code etc. and certainly preprocessors for source-code are much
more common/available than bytecode managers.

I'm not sure what you mean by "java parser", there's no need for a
preprocessor to parse Java itself (Think C pre-processor;), just simple
preprocessor directives.

Overall how it is done doesn't matter to me so much, I'd just like to see
it done, I understand some people may prefer C styel pre-processing
because that's what they're familiar, others probably would be totally
opposed to it just ebcause it's C and not Java. In fact, it should be
possible to use a standard C pre-processor to parse basic preprocessor
directvies for Java, altough preferably it should be as well integrated
with the compiler/tools as possible.

Note that for tet pre-processor style solution its still somewhat possible
to use an XML database to specify what segments are used in each profile
instead of specifying every profile related to a given segment in the
source-code. I'm also personally partial to the straight & simple
"wysiwyg" approach in this, without needing to compile, run a processor
and then disassemble/whatever to determine if the combination of the XML
rules and source is what you want. (Admittedly there are cases where
preprocessing directives in source-code aren't as clear-cut either, but by
far it tends to be clearer in intent and interpetation).

But, well, if we get an usable XML-database based bytecode post-processing
tool that is intuitive and easy to use, I won't complain, but neither do I
volunteer to build one ;) As for text pre-processing, we could use Cpp,
but I'd much rather have something that looks Java-like, is designed for
it and preferably constructs usable programs even without preprocessor.

 -Jukka Santala