Matt RaibleMatt Raible is a Java Champion and Developer Advocate at Okta. developer.okta.com

The JHipster Mini-Book The JHipster Mini-Book is a guide to getting started with hip technologies today: Angular, Bootstrap, and Spring Boot. All of these frameworks are wrapped up in an easy-to-use project called JHipster.

This book shows you how to build an app with JHipster, and guides you through the plethora of tools, techniques and options you can use. Furthermore, it explains the UI and API building blocks so you understand the underpinnings of your great application.

For book updates, follow @jhipster-book on Twitter.

10+ YEARS


Over 10 years ago, I wrote my first blog post. Since then, I've authored books, had kids, traveled the world, found Trish and blogged about it all.

JAR Hell with XFire 1.2.6

I discovered something somewhat disturbing last week. As part of AppFuse 2.0 M5, we added "xfire-all" as a dependency so web services could be supported out-of-the-box. What I didn't know is that xfire-all has transitive dependencies to 40 other libraries, which total 13.4 MB in size. Yikes!

Does XFire take the cake for the most bloated library you can use or are we just including too much (xfire-all vs. fine-grained dependencies)? I tried changing to the recommended Maven configuration and there's still 28 JARs added by XFire.

The WEB-INF/lib directory of a basic Struts 2 + Spring + Hibernate AppFuse application is already 19.2 MB to start. Adding XFire for web services increases the size to 29.2 MB. While disk space may be cheap, some users have noticed "mvn jetty:run" is much slower with XFire (presumably from the JAR processing that happens at startup). Is there an uber XFire JAR we can use instead?

Posted in Java at Jun 04 2007, 12:28:21 PM MDT 11 Comments
Comments:

Hi Matt:

Here is the eclipse .userlibraries file for the xfire stack we use (jaxb implementation):

<?xml version="1.0" encoding="UTF-8"?>
<eclipse-userlibraries version="2">
<library name="XFIRE-JAXB" systemlibrary="false">
<archive path="/usr/java/xfire-distribution-1.2.6/xfire-1.2.6/lib/xfire-jsr181-api-1.0-M1.jar"/>
<archive path="/usr/java/xfire-distribution-1.2.6/xfire-1.2.6/lib/jaxb-api-2.0.jar"/>
<archive path="/usr/java/xfire-distribution-1.2.6/xfire-1.2.6/lib/jaxb-impl-2.0.1.jar"/>
<archive path="/usr/java/xfire-distribution-1.2.6/xfire-1.2.6/lib/jaxb-xjc-2.0.1.jar"/>
<archive path="/usr/java/xfire-distribution-1.2.6/xfire-1.2.6/lib/jaxen-1.1-beta-9.jar"/>
<archive path="/usr/java/xfire-distribution-1.2.6/xfire-1.2.6/lib/jdom-1.0.jar"/>
<archive path="/usr/java/xfire-distribution-1.2.6/xfire-1.2.6/lib/stax-api-1.0.1.jar"/>
<archive path="/usr/java/xfire-distribution-1.2.6/xfire-1.2.6/lib/wsdl4j-1.6.1.jar"/>
<archive path="/usr/java/xfire-distribution-1.2.6/xfire-1.2.6/lib/wstx-asl-3.2.0.jar"/>
<archive path="/usr/java/xfire-distribution-1.2.6/xfire-1.2.6/lib/xbean-spring-2.8.jar"/>
<archive javadoc="file://usr/java/xfire-distribution-1.2.6/xfire-1.2.6/api/" path="/usr/java/xfire-distribution-1.2.6/xfire-1.2.6/xfire-all-1.2.6.jar"/>
</library>
</eclipse-userlibraries>

Here is their dependency page, also: http://xfire.codehaus.org/Dependency+Guide.

Cheers,
jt

Posted by jt on June 04, 2007 at 01:48 PM MDT #

Instead of cutting down the number of jars, wouldn't it be better if there's a JAR-stripper to cut down the library code and only include the classes that are used by the client.

Posted by Mark Hatham on June 04, 2007 at 02:19 PM MDT #

xfire-all isn't meant to be added as a dependency to your maven pom. XFire-all is a maven project which builds an aggregate jar. Because of the way the assembly plugin works, this means that ALL the dependencies are included - included the individual xfire modules which are already included in xfire-al!! You're much better off just including certain modules as needed (i.e. spring, java5, jaxb, etc - you probably only need a subset of them). :-)

Posted by Dan Diephouse on June 04, 2007 at 05:20 PM MDT #

Regarding a "JAR-stripper" program, I've used those in the past, but they really don't work with today's applications that load classes dynamically, since there is no way the stripper program could know what is really necessary.

Posted by Don Brown on June 04, 2007 at 06:33 PM MDT #

FWIW, org.codehaus.xfire:xfire-java5:1.2.6 and org.codehaus.xfire:xfire-spring:1.2.6. That's all I needed to get JSR181 annotation driven + Spring integration working.

Posted by Tim O'Brien on June 04, 2007 at 09:21 PM MDT #

Dan and Tim - thanks for the tips. I've reduced the JARs from 40 to 21 by just using xfire-java5 and xfire-spring. This uses XmlBeans by default, which may be the more performant option anyway.

Are there more JARs I can eliminate for an optimized Java 5 + Tomcat setup? Do I need commons-attributes-api-2.1.jar, xercesImpl-2.6.2.jar, xfire-aegis-1.2.6.jar, xmlParserAPIs-2.6.2.jar and XmlSchema-1.1.jar?

Posted by Matt Raible on June 05, 2007 at 07:27 AM MDT #

I almost always exclude xercesImpl, xmlParser etc. from my wars. Assuming everyone sticks to the the javax.xml APIs you should be able to get away with the ones bundled in the JVM.

Another constant irritation for me with Maven/dependencies is when different projects depend on essentially the same API but where it has a different groupId/artifactId. I usually try and figure out which jars are really the same and eliminate the spurious ones.
I've had this problem with cglib, commons-logging, stax parsers, jaxb libraries etc. etc.

Posted by Tim Morrow on June 05, 2007 at 03:05 PM MDT #

Thanks for your suggestions Tim. I've added the following exclusions to my pom.xml and it doesn't seem to cause any ill-effects.

<dependency>
    <groupId>org.codehaus.xfire</groupId>
    <artifactId>xfire-java5</artifactId>
    <version>${xfire.version}</version>
    <exclusions>
        <exclusion>
            <groupId>commons-attributes</groupId>
            <artifactId>commons-attributes-api</artifactId>
        </exclusion>
        <exclusion>
            <groupId>jaxen</groupId>
            <artifactId>jaxen</artifactId>
        </exclusion>
        <exclusion>
            <groupId>xerces</groupId>
            <artifactId>xmlParserAPIs</artifactId>
        </exclusion>
        <exclusion>
            <groupId>xerces</groupId>
            <artifactId>xercesImpl</artifactId>
        </exclusion>
        <exclusion>
            <groupId>org.apache.ws.commons</groupId>
            <artifactId>XmlSchema</artifactId>
        </exclusion>
    </exclusions>
</dependency>

Now XFire only adds 15 JARs to my resulting WAR and increases the size by 4 MB. Most of the size increase seems to be caused by xbean-2.2.0.jar, which is a whopping 2.5 MB. I find it funny that a library to make Spring's XML simpler is almost as big as spring.jar. ;-)

If any of the libraries I'm excluding are needed for some reason, please let me know.

Posted by Matt Raible on June 06, 2007 at 12:22 PM MDT #

Matt, making Spring configurations easier is only one part of XBean. The project is acutally aiming to provide a pluggable server infrastructure.

I have to admit, that I've only used the spring config stuff either... :-)

Posted by Stefan Kleineikenscheidt on June 07, 2007 at 03:23 AM MDT #

What about Spring OSGi??

Posted by Stein Kåre Skytteren on June 09, 2007 at 01:36 AM MDT #

Which 15 did you put in? .V (i am using xfire for json w/ T5+yui ;o )

Posted by vic on June 10, 2007 at 07:43 PM MDT #

Post a Comment:
  • HTML Syntax: Allowed