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

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

> Dmitry,
> 
> thank you for that explanation. So this means, the more complex the
> application is, the larger the EXE gets. Maybe beyond the original size of
> the APP, since you need to pack the APIs into the EXE.
> 
        Yes. More precisely, this is true if you use global optimizations,
which, as I mentioned earlier in this thread, is only possible for
closed-world applications. In a general case, you compile the API classes
into a set of DLLs (core classes, RMI, SQL, AWT, Swing, XML, etc.) after
installing Excelsior JET, then compile your app and then use JetPackII to
determine which of those DLLs has to be packaged along with your
application's EXE for deployment. This has the potential advantage of code
sharing - if you have several EXEs packaged together, it may make sense to
not use global optimizations so that the API DLLs are shared. You can also
compile third-party components and APIs into DLLs. For instance, these SWT
demos share SWT.DLL:

        http://www.excelsior-usa.com/download/jet/swtdemo-exe-setup.exe

        With best regards,

        Dmitry

> -------- Original Message --------
> Subject: RE: [ObjectWeb architecture] just an idea for (Java)  native comp
> ilation (07-Okt-2003 9:27)
> From:    dleskov@xxxxxxxxxxxxxxxxx
> To:      markus.karg@xxxxxxxxx
> 
> > > >         There are a few other issues when native compilation can
> make a
> > > > difference, such as the download size of a self-contained package.
> Have
> > > a
> > > > look at http://www.excelsior-usa.com/jetbenchsize.html - download
> sizes
> > > > start from as little as 0.34 MB ("Hello, world" JetPerfected against
> JRE
> > > > 1.3.1 and zipped.) 
> > > 
> > > from your experience, does that factor scale linear with application
> size
> > > or is that difference in "Hello World" bound to some static offset? I
> > > mean, maybe with large applications that offset will not be the
> problem as
> > > its influence will shrink compared to the influence of the linear code
> > > size.
> > > 
> >     First of all, the size factor depends not exclusively on the
> > application's size but on which subest of the platform APIs it uses. The
> > Java 2 API classes reference each other in a spaghetti fashion, and the
> > situation becomes worse with each J2SE release. On JRE 1.4.2, even the
> > minimal "Hello, world" sample involves 696 (!) classes from rt.jar, of 
> > which
> > 248 are actually loaded - just run "java -verbose hello". The global
> > optimizer of course removes unused methods, inserts stubs instead of 
> > classes
> > that are imported but never instantiated, and so on, otherwise the 
> > resulting
> > EXE would have been much larger.
> > 
> >     Then, the classes that constitute the Swing and AWT APIs are very
> > tightly coupled, and there are many of them. As a result, an executable
> for
> > even the smallest GUI app would have a size of several megabytes,
> whereas a
> > large non-GUI program concentrated on something like XML transformation
> may
> > compile to a smaller executable. The use of SWT also helps in that
> regard.
> > 
> >     We also have the internationalization issue. If you need your
> > compiled application to support all locales and encodings supported by
> the
> > respective JRE, you have to include all the locale classes and all
> classes
> > from charsets.jar, some of which, such as Japanese or /Chinese/Korean
> > contain very large tables 
> > 
> >     To summarize (and to answer your question), the factor scales linear
> > if we define "application size" as "the total size of application's
> classes
> > plus all required classes from the JRE". So the global optimization 
> > benefits
> > for a large application are likely to be limited to performance.
> > 
> > 
> > 
> > To: markus.karg@xxxxxxxxx
> >     architecture@xxxxxxxxxxxxx
> 
>  << File: message.footer >>