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

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

First off, I would suggest not to focus on the words "static compilation".
Instead, let's think of JET Pro and GCJ as of JVMs with pre-compilation
option. Both products allow you to distribute your program as class files
and have it interpreted or JIT-compiled on enduser systems, which is the
case with fully dynamic VMs, such as HotSpot, IBM JRE, etc. Of course, the
performance of your application would be worse than if you precompiled (most
of) it, but technically this problem may be addressed with install-time or
post-install compilaton, mentioned earlier in this thread.

The reality is that there is no single vendor that has the best Java VM for
all platforms. If your application is fully portable, your clients would use
HotSpot on SPARC, IBM JRE on IBM hardware, and so on. These two products
(JET and GCJ) broaden the developer's choice of VMs on popular platforms - I
think you would agree that there is nothing wrong with that. If you have a
server farm, running, say, a Java-powered e-commerce site the popularity of
which constantly grows, the use of a faster or more scalable VM would save
you $$ on hardware. Just one possible ROI model for an alternative VM,
regardless of whether it has the AOT compilation option. 

If your _particular_ application works fastest with GCJ on Linux or scales
best with JET on Windows, you just have to decide whether these benefits
outweigh the drawbacks of using ahead-of-time compilation (if there are any
in your _particular_ case.) I would not take the responsibility of making a
decision whether a particular VM should be used at all to run any
application based on the given framework, such as the ObjectWeb stack.

Dmitry

> -----Original Message-----
> From: markus.karg@xxxxxxxxx [SMTP:markus.karg@xxxxxxxxx]
> Sent: Monday, October 06, 2003 12:57 PM
> To:   architecture@xxxxxxxxxxxxx
> Subject:      Re-6: [ObjectWeb architecture] just an idea for (Java)
> native comp ilation
> 
> So back to the track the question is what to achieve. There has to be a
> real drawback before tampering with static compilation. Does ObjectWeb
> have such a problem?
> 
> Have Fun
> Markus
> 
> -------- Original Message --------
> Subject: RE: Re-4: [ObjectWeb architecture] just an idea for (Java)
> native comp ilation (02-Okt-2003 22:32)
> From:    christophe.ney@xxxxxxxxxxxxx
> To:      markus.karg@xxxxxxxxx
> 
> >
> > I understand, but then it comes to performance comparison of
> > vendors JVMs.
> >
> > > -----Original Message-----
> > > From: Madl Alfred [mailto:A.Madl@xxxxxxxxxxx]
> > > Sent: Thursday, October 02, 2003 9:46 PM
> > > To: architecture@xxxxxxxxxxxxx
> > > Subject: WG: Re-4: [ObjectWeb architecture] just an idea for (Java)
> > > native comp ilation
> > >
> > >
> > > Hi !
> > >
> > > The deployment aspect is ONE important aspect. We also had
> > > ENORMOUS performance improvements compared to JDK 1.3.1 and
> > > could NOT use JDK 1.4.x for some JDK incompatibility reasons :-)
> > >
> > > Greetings.
> > >
> > > ALfred
> > >
> > > -----Ursprüngliche Nachricht-----
> > > Von: Christophe Ney [mailto:christophe.ney@xxxxxxxxxxxxx]
> > > Gesendet: Donnerstag, 02. Oktober 2003 21:40
> > > An: Madl Alfred; markus.karg@xxxxxxxxx
> > > Cc: architecture@xxxxxxxxxxxxx
> > > Betreff: RE: Re-4: [ObjectWeb architecture] just an idea for
> > > (Java) native comp ilation
> > >
> > >
> > >
> > > Interesting... it seems that key differentiator for native
> > > compilation would mainly be the deployment aspect.
> > >
> > > Obviously the ability to shortcut part of the deployment
> > > process at each  startup is a plus if startup time is
> > > important (Eclipse
> > > case) but the same results could be achieved with persistence of
> > > compiled code.
> > >
> > > Now, I understand that Sun does not like static compilers very much
> > > since it could devitate the WORE concept. At the same time, J2EE
> > > applications require deployment, so native compilation of EAR
> > > applications would be ok if performed at deployment time I guess.
> > >
> > > Thanks,
> > > Christophe
> > >
> > >
> > > > -----Original Message-----
> > > > From: Madl Alfred [mailto:A.Madl@xxxxxxxxxxx]
> > > > Sent: Thursday, October 02, 2003 8:36 PM
> > > > To: markus.karg@xxxxxxxxx
> > > > Cc: architecture@xxxxxxxxxxxxx
> > > > Subject: AW: Re-4: [ObjectWeb architecture] just an idea for (Java)
> > > > native comp ilation
> > > >
> > > >
> > > > Hi Markus !
> > > >
> > > > Of course there is always the right time to wait for something. The
> > > > current release of JET 3.11 (this is the one that we are using for
> > > > Enhydra 5.1) is also not the latest version, because it
> > > contains some
> > > > things we needed for Enhydra and that has not been ported
> > > to JET 3.15
> > > > yet. So the comparison should be fair. Or we wait for JDK
> > > 1.5 AND JET
> > > > 3.5 ? So the essence is: this comparison is not a one time
> > > > effort. It has to be done again and again... And we should do
> > > > it NOW AND AGAIN IN THE FUTURE with available final versions,
> > > > or never ?!
> > > >
> > > > Regarding the portability issue:
> > > >
> > > > There are many, many reasons why you MUST support certain OSes. You
> > > > have to test on it, provide configurations for it, etc. Java is NOT
> > > > fully portable.. There are so many plattform specific
> > > issues (Memory
> > > > limits, OS bugs, JDK bugs,...). Portability is just a
> > > buzzword if it
> > > > is not tested and simply does not work the way it is
> > > expected. Same is
> > > > true for JDBC by the way...lots of issues there...
> > > >
> > > > Regarding the timepoint of compilation: This is an issue that is
> > > > depending on your situation. Of course an install-time compilation
> > > > would almost always be best. Should we use DOT-NET for that
> > > reason and
> > > > forget Java ? :-)))
> > > >
> > > > Regarding choice of VMs: In our situation (building real world
> > > > projects for paying real world customers) I DO WANT to limit the
> > > > admins choice. In no way should an admin be able to change the
> > > > JDK...but this is again situation dependent.
> > > >
> > > > So what does this mean for us in Objectweb ?
> > > >
> > > > Just an example: Enhydra Server...
> > > >
> > > > It was a big success in the past because it was easy to use and
> > > > supported Windows AND Linux with plattform specific setups,
> > > doing nice
> > > > things like installing Icons on the desktop, etc. Also Jonas has a
> > > > Windows setup !
> > > >
> > > > From our experience and as a result from many discussion I
> > > > had: Good plattform specific packaging is a MUST for Open
> > > > source projects and for middleware especially. So if we do
> > > > plattform specific packaging, why not plattform specific
> > > > compilation in that package ?
> > > >
> > > > I do NOT say that native compilation is a perfect solution for
> > > > everything or should be done for every project. But it CAN
> > > have a lot
> > > > of value depending on the situation. And the value is not only
> > > > performance.
> > > >
> > > > Greetings.
> > > >
> > > > Alfred
> > > >
> > > >
> > > > -----Ursprüngliche Nachricht-----
> > > > Von: markus.karg@xxxxxxxxx [mailto:markus.karg@xxxxxxxxx]
> > > > Gesendet: Donnerstag, 02. Oktober 2003 15:42
> > > > An: architecture@xxxxxxxxxxxxx
> > > > Betreff: Re-4: [ObjectWeb architecture] just an idea for
> > > > (Java) native comp ilation
> > > >
> > > >
> > > > Hi Alfred,
> > > >
> > > > thanks for your valueable input. There are some more ideas
> > > about that
> > > > I want to tell (see below).
> > > >
> > > > > Please be carefull with the Enhydra 5.0/JET scenarios on
> > > > forge. These
> > > > > have been early versions  done with early versions of JET
> > > > 3.x. Since
> > > > > these days there have been a lot of optimizations which
> > > are NOT yet
> > > > > released on forge. We will try to publish these results
> > > > (Enhydra 5.1
> > > > > JET) during the next days or so...These results should be
> > > used and
> > > > > compared.
> > > >
> > > > We should not compare before Sun 1.5 is beta-released since
> > > they have
> > > > performance and memory footprint enhancements in that release as a
> > > > main feature. I think other VM vendors will follow so we
> > > should wait
> > > > for the next VM generation to compare. The 1.4 generation
> > > is one and a
> > > > half year old. So when comparing NOW, we need to compare
> > > 1.4.2_01 with
> > > > the latest patch of a one and a half year old architecture of JET
> > > > to be fair - what doesn't make sense.
> > > >
> > > > > I still wonder why the discussion is only about
> > > > performance. There are
> > > > > lot of other goodies when using JET (on Windows as we do). The
> > > > > solution is " packaged", so no need for JDK install anymore, a
> > > > > customer can not "damage" your installation, JET supports native
> > > > > Windows services with all the Windows management of
> > > > starting/stopping
> > > > > services, DLL's can be called from C/C++ without additional
> > > > stuff, ...
> > > > > Just my 2 cents.
> > > >
> > > > If you package for a specific Host-OS, you need to support that
> > > > Host-OS. Can you support every Host-OS? E. g. our company cannot
> > > > support OS/400 or MacOSX, so we keep away from platform specific
> > > > packaging.
> > > >
> > > > Second, if you package with JET, the user has no choice of
> > > VM vendor
> > > > and version. This weakens the local admin's position.
> > > >
> > > > Actually what your are doing then is not delivering a Java Platform
> > > > based application, but a Windows application written in the source
> > > > language of Java. That weakens the Java Platform and the Write Once
> > > > Run Anywhere idea and supports the Microsoft world.
> > > >
> > > > One strong idea behind Java is that the byte code runs on every
> > > > platform, without change. So if you do static compilation,
> > > you should
> > > > do it on the client's local machine, not on the deployer's machine.
> > > >
> > > > This leads to a third class of compilation:
> > > Install-Time-Compilation.
> > > > Maybe the best choice: The app is delivered as JAR, just as
> > > Java Spec
> > > > wants it, but it is statically compiled to match the local host's
> > > > optimal machine code. Also, when it is getting started, it
> > > starts as a
> > > > specific EXE. Maybe the best cut?
> > > >
> > > > >
> > > > > Alfred Madl
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
> > To: A.Madl@xxxxxxxxxxx
> >     architecture@xxxxxxxxxxxxx
> 
>  << File: message.footer >>