[fedora-java] aot-compile-rpm

[Thomas Fitzsimmons]

Hi,

On Wed, 2005-07-06 at 16:40 +0100, Gary Benson wrote:
> Over the past couple of days I've been writing a replacement for
> aot-compile and find-and-aot-compile.  They were both good when they
> were first written but the demands of Eclipse and JOnAS have exposed
> numerous shortcomings.
> 
> Attached is a copy of aot-compile-rpm which I'd like to commit into
> java-1.4.2-gcj-compat if everyone's agreeable.  It's an order of
> magnitude more complex than aot-compile and find-and-aot-compile, but
> it's advantages over them are manifold:
> 
>  IT'S MUCH MORE USABLE
>  =====================
>   Nativifying an rpm using aot-compile-rpm is a matter of
>   copy-and-paste:
> 
>     1. Remove "BuildArch: noarch"
>     2. Add "BuildRequires: java-1.4.2-gcj-compat >= 1.4.2.0-Xjpp"
>        and "Requires(post,postun)" on same.

Releng told me to separate these requires:

Requires(post):

and

Requires(postun):

because certain versions of RPM fail on the (post,postun) syntax.

>     3. Add "aot-compile-rpm" to the very end of %install.
>     4. Add "/usr/bin/rebuild-gcj-db %{_libdir}" to %post and %postun.
>     5. Add "%attr(-,root,root) %{_libdir}/gcj/%{name}" to %files.
> 
>   With aot-compile or find-and-aot-compile step 4 was much more
>   complex.  I was always uneasy about nativifying things I didn't
>   myself maintain, postgresql-jdbc for example, because I was wary of
>   dropping a bunch of fragile code on someone else.  No longer.
> 
>  IT FINDS JARS BY SIGNATURE RATHER THAN BY EXTENSION
>  ===================================================
>   find-and-aot-compile identifies jarfiles by their extension, ".jar",
>   so it misses ".war", ".ear", ".rar", and anything else the Java
>   world happens to invent.  aot-compile-rpm identifies jarfiles by
>   opening them, so it catches them no matter what they're called.
> 
>   It's already found some unexpected stuff.  Tomcat, for example, has
>   a couple of servlets that are disabled by default because they are
>   in jarfiles called ".renametojar".  aot-compile-rpm finds and
>   compiles these, so if the user renames them to enable the servlets
>   then they'll be running BC-compiled code.

Does aot-compile-rpm provide a way to exclude certain jars from native
compilation?  This is sometimes necessary to work around gcj bugs.

> 
>  IT IGNORES SUBSETTED JARFILES
>  =============================
>   Several packages contain jarfiles which are a subset of others.
>   MX4J, for example, has the APIs in mx4j-jmx.jar, the implementation
>   in mx4j-impl.jar, and both together in mx4j.jar.  aot-compile-rpm
>   recognises that compiling mx4j.jar will get every class in the other
>   two jars too, so it'll only compile mx4j.jar.  So, aot-compile-rpm
>   compiles MX4J in half the time (and generates half the bytes) that
>   find-and-aot-compile does.
> 
>  IT WORKS AROUND THE PPC GO2 LIMIT
>  =================================
>   PPC machines are limited on the size of jarfiles that can be
>   compiled in one go, affecting Eclipse and JacORB, as described
>   at https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=158308.
>   aot-compile-rpm splits large jarfiles on ppc to avoid this.
> 
> One limitation of aot-compile and find-and-aot-compile that I have not
> addressed (yet) is SMP support.  Andrew Overholt suggested generating
> a Makefile and letting make handle the complex stuff, which I think is
> an excellent idea.  Implementing something along those lines is
> something I'd like to do, but I need to get ppc64 and s390*
> bootstrapped first.

Great!  This will be excellent.

Tom