Re-2: [ObjectWeb architecture] just an idea for (Java) native comp ilation

[<markus.karg@xxxxxxxxx>]

Dmitry,

always a pleasure to discuss with you. :-)

> > 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++.

Yes, sure Java isn't cheap. Many people hype Java in a wrong way. They think 
everything is free and easy in Java. Actually it is not and really I do not 
know WHY so much people think it is. Doing good programs in Java is hard, but 
not harder than in other languages/APIs.

But also I heard the same in the other direction years ago when my boss told 
me that everyone he asked said Java is slow and complex to do...

Maybe management people should just not talk about technical things? ;-)

>       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.

Yes we all are Java professionals. Actually I didn't say we will not try out 
your products but only that we have no need to try it out NOW. ;-)

> > >   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.

If we find the first problem with our software on their platform we will let 
them know. :-)

> > > > 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.

Hm... I just believe you. Have no time to check this, also we are not doing 
embedded controlling. That was just an argument someone told in this thread 
for benefitting of AOT.

>       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.)

..or using a Java speaking Microcontroller if there will be a GOOD one... ;-)

Have Fun
Markus