RE: [ObjectWeb architecture] just an idea for (Java) native comp ilation

["Leskov, Dmitry" <dleskov@xxxxxxxxxxxxxxxxx>]

> >     Well, I meant the apps that are designed to run on the server and
> > use thin clients. Do you mean your product is a fat client or do you
> deploy
> > the server part to end-user systems as well so that it could be used in
> > off-line mode?
> 
> What we are doing here is both. We have companies that run our software
> locally (laptop, client plus server). Others run in on their own server,
> with fat clients. Others run it remote, with app server in some country,
> thin clients via internet in another counts. We have more than thousand
> companies. Every has different hard and software, different needs. We
> provide one and the same solution without any change. WORA works, at least
> for us. Our application is written for (server) J2EE 1.3 plus (client)
> J2SE 1.4. We e.g. have deployments with Server beeing Linux Blackdown 1.3
> VM, clients beeing Sun 1.4.2.
> 
        I would say you make WORA work for you. It does not come free or
cheap actually, although, of course, it takes much less efforts than if you
were using, say, C++.

        You seem to be enjoying working in a team of real Java professionals
then! It's a pity you are ruling out static compilation - your application
suite could have been an excellent stress test for our product.

> >     In any case, you have to choose the right VM(s) for your particular
> > applications, performance requirements, deployment scenarios, etc. If a
> VM
> > with AOT compromises the aspect that is most important for you, surely
> do
> > not use that VM. 
> 
> Actually this is not what we experienced with our thousand company
> customers (ten thousand users). We let the customer decide. Only thing we
> decide is the platform and version, e.g. J2EE 1.3 or J2SE 1.4, but not
> which vendor or product.
> 
        Well, at least you have to inform them about any bugs in particular
implementations that prevent correct operation of your software.

> > > 2) Servers more and more are running on embedded controllers. Memory
> is
> > > scarce there.
> > > 
> >     That's a good point, however their CPU power is limited as well, and
> > together these also restrict the quality of JIT-compiled code. So it
> might
> > make sense to profile the app and precompile those 10-20% of code that
> eat
> > 80-90% of CPU time, being it application classes or the ROMized J2ME
> API. 
> 
> Well, actually we are not driving such an environment (embedded). It was
> just a case I heard of. But instead of AOT I would look for a special
> embedded VM (I heard of such before) and try using that. Again, we are an
> ISV and need to be able to support WORA. If an end user choses AOT, it can
> use that I think.
> 
        Oh, embedded VMs have been coming with AOT compilers for quite some
time:

        http://www.newmonics.com/perc/info.shtml
        http://www.kadasystems.com/resources/development_tools.jsp
        http://www.esmertec.com/products/white_papers.shtm

        Just search for "AOT" or "ahead" on the above pages.

        Having background in compiler engineering and embedded systems, I
can reassure you that many code optimizations require too many resources and
thus cannot be implemented in an embedded VM running on a device with low
CPU speed and memory size without compromising performance and availability
of memory to the applications. So you have a choice between interpreted
bytecode, low-quality JITted native code, and AOTed native code (or some
combination of these as I suggested above.)

        With best regards,

        Dmitry