You would probably do more harm than good. The hotspot JIT can get
confused by premature optimization and you might get slower code, not
faster. I fact, Sun removed certain "optimizations" from the code
generation of the compiler to allow the JIT to work better.

But if you want to try: http://asm.objectweb.org/

Whatever that should be. Java is (by the usual definitions), a
statically typed language. You might need a miracle to turn it into a
dynamic typed language.

/Thomas

I suspect you'd be better of working directly with bytecode for everything.
There are a number of byte code libraries available -- ASM and BCEL are the
best known.  There are also some higher-level libraries which may help in one
way or another.  This page lists several (none of which I can vouch for in any
way):

   http://java-source.net/open-source/bytecode-libraries

Working at bytecode level gives you only a little better chance to to implement
"soft typed" languages -- the JVM bytecode is a statically typed language
itself (checked by the verifier) and while working at that level does at least
allow you to call methods which the Java compiler wouldn't (if it didn't know
in advance that they were going to exist at runtime), it doesn't provide help
in recovering from situations where the method turns out not to exist after
all.  At least, not if you want to do anything more elaborate than throwing an
exception.

However, this might interest you, if you haven't seen it already:

   http://blogs.sun.com/roller/page/gbracha?entry=invokedynamic

I have no idea at all how likely it is to come to fruition.

   -- chris

I'd stay with them, then, rather than trying to make Java
do something it wasn't designed for.

I find that Java supports considerable freedom of expression
for significantly complex programs, and "adequate" optimisation
(courtesy of JIT) in tight processing loops.

I have used 'C' and assembler for performance (at one time
in a world leading piece of software, which was primarily
judged on performance), but hav been using Java for
the last few years without too many pangs of loss.

  BugBear

Thanks for the links, they where very usefull (the ASM one was perfect

Nice idea! So, i'll return (yes!) to my old gcc, lex and yacc and write
an interface that will build all the necessary files and supervise the
"make" process.
The problem now is parsing the compilers error messages but it will be
fine :)

I've always admired the auto changing code, using a JIT seems to be the
right answer but inline assembly has its charms too.

Adiaux
Samir

Or even jump directly to them with a bit of JNI magic.

But in neither case is the inserted code really being executed inline -- you
don't know what the surrounding code is going to be JITed into, so you can't
really do anything that you couldn't do with a normal function call (native or
not).

   -- chris