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

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

        Markus,

> > 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.
> 
> So what would be the benefit in this case? What ObjectWeb project benefits
> from native compilation (not packaging!), and what would the benefit be
> measured in if not in terms of speed or memory footprint?
> 
        AOT compilation can help Java penetrate the Microsoft-centric part
of the market. I know for sure that we have a few customers who would have
lost big opportunities without our product, because their potential clients
had Java banned in their corporate IT environments. Imagine selling your
Java-based solution to Microsoft... :) 

        The availability of the AOT option might also cause companies that
are concerned about their IP to consider Java. Java is famous for its
extremely low resistance to reverse engineering, and class file obfuscation
has a negative impact on performance (of course if it is applied to bytecode
instructions, not just to reflection information). I think you would agree
that reverse engineering of optimized native code is more expensive and
requires more engineering skills than downloading and starting JAD. 

        Please note that I am not talking about copy protection - popular
software written in C++ gets hacked within days, if not hours, after
release, but about the protection of algorithms, data in proprietary
formats, and so on. 

        If Java can provide the same level of protection as C++, it has
better chances to be chosen for implementation at certain
companies/organizations, which we again have confirmed by customer emails.

        The above may hold for an ObjectWeb-based project just as well, but
I am not sure how to "measure" this... 

        With best regards,

        Dmitry 

> > 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: markus.karg@xxxxxxxxx
> > Cc: architecture@xxxxxxxxxxxxx
> 
>  << File: message.footer >>