| 1 | <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
|
|---|
| 2 | <HTML>
|
|---|
| 3 | <HEAD>
|
|---|
| 4 | <META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=windows-1252">
|
|---|
| 5 | <TITLE>Welcome to Apache Ant 1.6</TITLE>
|
|---|
| 6 | </HEAD>
|
|---|
| 7 | <BODY LANG="en-US" BGCOLOR="#ffffff" DIR="LTR">
|
|---|
| 8 | <H1>Welcome to Apache Ant 1.6</H1>
|
|---|
| 9 | <P><BR><BR>
|
|---|
| 10 | </P>
|
|---|
| 11 | <H2>Your life just got better.
|
|---|
| 12 | </H2>
|
|---|
| 13 | <P>Not in big ways. Your social life isn't going to be helped, though
|
|---|
| 14 | with any luck you may now have more time for one. Nor is it going to
|
|---|
| 15 | take less time to write your Java code -although we note that running
|
|---|
| 16 | <A HREF="http://xdoclet.sf.net/" TARGET="other">XDoclet</A> under Ant
|
|---|
| 17 | lets you avoid writing so much code. Nor is a new release of Ant
|
|---|
| 18 | likely to provide a fundamental kick-start to the currently somewhat
|
|---|
| 19 | subdued technology and software industries.
|
|---|
| 20 | </P>
|
|---|
| 21 | <P>No, Ant1.6 will not fundamentally change your life. But if you do
|
|---|
| 22 | have to get software out on time -"roughly what you asked for,
|
|---|
| 23 | roughly when you asked", then Ant1.6 provides lots of little
|
|---|
| 24 | improvements over the existing version.
|
|---|
| 25 | </P>
|
|---|
| 26 | <P>Before we look at those details, lets look at the world of The
|
|---|
| 27 | Automated Build.</P>
|
|---|
| 28 | <P>Firstly, we'd like to thank everyone for all those awards that
|
|---|
| 29 | have been flowing in. The JavaWorld Editors' Choice Award for "Most
|
|---|
| 30 | Useful Java Community-Developed Technology", The Java
|
|---|
| 31 | Developer's Journal "Editors Choice Award", and Java Pro
|
|---|
| 32 | Reader's Choice award for "Most Valuable Java Deployment
|
|---|
| 33 | Technology." Wow. That's a lot of awards. Aardman Animations
|
|---|
| 34 | keep all their Wallace and Gromit -related oscars in a cabinet in
|
|---|
| 35 | their tea room. If the Apache organization had a tea room, those Ant
|
|---|
| 36 | awards would be forcing all the other (excellent) Apache products to
|
|---|
| 37 | fight hard for their cabinet space.
|
|---|
| 38 | </P>
|
|---|
| 39 | <P>All those awards come for a reason: everyone, at least everyone
|
|---|
| 40 | working on any project of moderate complexity, needs to control their
|
|---|
| 41 | build process. Ant is one of the best ways to do it in Java, and,
|
|---|
| 42 | over the past four years, it has moved from a tool used simply to
|
|---|
| 43 | build Tomcat cross-platform, to a tool used across many open source
|
|---|
| 44 | projects, and now to a tool used by almost all Java projects. Indeed,
|
|---|
| 45 | pretty much the only competitor in the Java space is a sibling
|
|---|
| 46 | project under the Apache banner, <A HREF="http://maven.apache.org/" TARGET="other">Maven</A>.
|
|---|
| 47 | One of the obvious signs of Ant's success is that all the popular
|
|---|
| 48 | IDEs, from the Open Source -Emacs JDE, Eclipse, NetBeans and jEdit -
|
|---|
| 49 | to the commercial: IntelliJ IDEA, Borland JBuilder- all ship with
|
|---|
| 50 | built in Ant support. This lets you use your favourite IDE for what
|
|---|
| 51 | it is good at: editing text, creating Java source, refactoring
|
|---|
| 52 | existing code, debugging and the like, and you can turn to Ant for
|
|---|
| 53 | co-ordinating the build-test-deploy/deliver process. That Ant based
|
|---|
| 54 | process can be triggered from keystrokes in the IDE, command line
|
|---|
| 55 | invocations for those so inclined, and in automated scheduled builds
|
|---|
| 56 | so the machines can keep an eye on the engineers. Another sign is how
|
|---|
| 57 | Ant is helping the Java aisle of bookstores fight back against
|
|---|
| 58 | attempts by books about Macromedia Flash to take over all the space
|
|---|
| 59 | -there are now seven or eight books on the subject, with more on the
|
|---|
| 60 | way. Germany and Korea have their own native language books too,
|
|---|
| 61 | which shows how global the tool is -in use and in development terms.
|
|---|
| 62 | </P>
|
|---|
| 63 | <P>The other metric of success is the pre-announcement hints from our
|
|---|
| 64 | distant software colleagues in Redmond, Microsoft, of a new build
|
|---|
| 65 | tool, "MSBuild", which "might be the single most
|
|---|
| 66 | important feature innovation in our pipeline", according to one
|
|---|
| 67 | MS developer. That is surely the greatest metric of success: XML
|
|---|
| 68 | based build tools are now viewed as so essential to the modern build
|
|---|
| 69 | process, that Microsoft has to come up with a competitor to Ant to
|
|---|
| 70 | win Java developers over to .NET. Let's hope they discover we like
|
|---|
| 71 | ubiquitous JUnit testing too, and refactoring IDEs that create and
|
|---|
| 72 | run the tests for us.
|
|---|
| 73 | </P>
|
|---|
| 74 | <P>Success comes at a price, of course. One price is all those
|
|---|
| 75 | support calls. We try and stay on top of the bug reports, but one
|
|---|
| 76 | thing we cannot do is fix inconsistencies or things that seem like
|
|---|
| 77 | defects if they stand a significant chance of breaking existing
|
|---|
| 78 | builds. Its sad, but there are lots of little minor faults with Ant
|
|---|
| 79 | that we don't dare fix because, well, things might break. For
|
|---|
| 80 | example, why don't if= and unless= clauses also support
|
|---|
| 81 | <code>if="${property}"</code> clauses? Alternatively, why isn't it an
|
|---|
| 82 | error to use a property that isn't defined. Everyone that has ever
|
|---|
| 83 | seen directories called ${build.dir} popping up the source tree will
|
|---|
| 84 | understand why that behaviour is not always what you want. Well, we
|
|---|
| 85 | could fix these things, but we won't, because backwards compatibility
|
|---|
| 86 | is sacred.
|
|---|
| 87 | </P>
|
|---|
| 88 | <P>That is the other price of success: all those users who have
|
|---|
| 89 | existing build files they want to work. And all those IDEs that host
|
|---|
| 90 | Ant, and who want an easy upgrade to a new version. This means we
|
|---|
| 91 | have lost a lot of the flexibility we used to have in the early days
|
|---|
| 92 | of the project, when different versions of Ant could have completely
|
|---|
| 93 | different property evaluation algorithms and nobody would bat an
|
|---|
| 94 | eyelid. Now, even the most obscure bug fix ends up generating 'you
|
|---|
| 95 | broke my build complaints'.
|
|---|
| 96 | </P>
|
|---|
| 97 | <P>This explains why there will not be the 'incompatible upgrade'
|
|---|
| 98 | version of Ant, Ant2.0, that has long been discussed on our web site.
|
|---|
| 99 | </P>
|
|---|
| 100 | <H2>Where is Ant2.0?</H2>
|
|---|
| 101 | <P>For years we have been discussing Ant2.0, the complete rewrite
|
|---|
| 102 | version that would be cleaner and faster, and slightly incompatible
|
|---|
| 103 | with Ant1.x. It would be the opportunity to take the lessons from the
|
|---|
| 104 | 1.x line, and support them cleanly. We even got as far as having
|
|---|
| 105 | multiple implementations of new Ant engines in the CVS repository,
|
|---|
| 106 | especially Mutant and Myrmidion. But we always seemed to have a hard
|
|---|
| 107 | time making progress -everyone was too busy using and firefighting
|
|---|
| 108 | Ant1.x that nobody got time to work on the 2.x codebase. Which is a
|
|---|
| 109 | shame, as all the proposals had interesting ideas.</P>
|
|---|
| 110 | <P>After Ant1.5 shipped, the future of Ant effectively resolved into
|
|---|
| 111 | one of evolution rather than revolution. There will be no Ant2.0 with
|
|---|
| 112 | a complete new engine underneath. There will be no need to run XSL
|
|---|
| 113 | transforms over existing build files to move them to the Ant2.0
|
|---|
| 114 | world. Instead Ant1.x is getting better underneath the build file
|
|---|
| 115 | -improving its internal design while retaining five-nines backwards
|
|---|
| 116 | compatibility with existing build files.
|
|---|
| 117 | </P>
|
|---|
| 118 | <P>And that is what we have been up to.</P>
|
|---|
| 119 | <P>Under the hood, Ant1.6 contains some of the most major reworkings
|
|---|
| 120 | of the core Ant system yet seen. We haven't finished yet, and are
|
|---|
| 121 | holding back some of the more visible developments so we can see what
|
|---|
| 122 | works before their release in a product forces us to maintain them.
|
|---|
| 123 | But the underlying parts of Ant are now set up for the next stage in
|
|---|
| 124 | development.
|
|---|
| 125 | </P>
|
|---|
| 126 | <P>Whether we call the next version of Ant 1.7 or 2.0 is something we
|
|---|
| 127 | have yet to decide. Maybe we should call it 3.0 just to surprise
|
|---|
| 128 | people.</P>
|
|---|
| 129 | <H2>What has changed</H2>
|
|---|
| 130 | <P>Look at the <A HREF="WHATSNEW" TARGET="other">WHATSNEW</A>
|
|---|
| 131 | document to get a full list of changes. Here are some of the core
|
|---|
| 132 | conceptual differences.</P>
|
|---|
| 133 | <H3>No more Java1.1</H3>
|
|---|
| 134 | <P>We got fed up of jumping through reflection hoops to do everything
|
|---|
| 135 | from weak references to setting file timestamps. After consultation
|
|---|
| 136 | with the Ant user mail list, Ant1.6 only runs on Java1.2 or later. It
|
|---|
| 137 | can still cross compile to Java1.1 if that is what you have to do. We
|
|---|
| 138 | haven't completely purged all 1.1 references in the docs, or 1.1
|
|---|
| 139 | support from the source, but that will come over time.</P>
|
|---|
| 140 | <H3>New classloader use.</H3>
|
|---|
| 141 | <P>This is going to make people nervous. If there is one thing Java
|
|---|
| 142 | developers have learned over time, only the very naive, the very
|
|---|
| 143 | brave, or the very competent do things with classloaders. We will let
|
|---|
| 144 | the Ant users decide what category to put us in, but before everyone
|
|---|
| 145 | panics, Costin, of Tomcat fame, did a lot of the work here. You don't
|
|---|
| 146 | write application servers without understanding classloaders inside
|
|---|
| 147 | and out.
|
|---|
| 148 | </P>
|
|---|
| 149 | <P>The impact of these changes will trickle out over Ant versions. In
|
|---|
| 150 | 1.6, the key features are
|
|---|
| 151 | </P>
|
|---|
| 152 | <OL>
|
|---|
| 153 | <LI><P>We have got rid of the bit in the batch file/shell script
|
|---|
| 154 | that built up a really big classpath environment variable from
|
|---|
| 155 | everything in ANT_HOME/lib. Now that is done in a launcher class
|
|---|
| 156 | that does the work then calls tools.ant.Main as before.</P>
|
|---|
| 157 | <LI><P>You can add new library directories to that classloader with
|
|---|
| 158 | the -lib option on the command line. This option is interpreted by
|
|---|
| 159 | the launcher class, so will not work with IDEs and other apps that
|
|---|
| 160 | use the inner entry point.</P>
|
|---|
| 161 | <LI><P>We have broken up optional.jar into many-many jar files, such
|
|---|
| 162 | as ant-commons-logging.jar, ant-xalan2.jar, etc etc, and a
|
|---|
| 163 | nodeps.jar for optional stuff without any dependencies. This creates
|
|---|
| 164 | a lot of jar files.</P>
|
|---|
| 165 | <LI><P>You can now <taskdef> existing tasks -like <junit>-
|
|---|
| 166 | by including the specific ant jar <I>and</I> the dependent libraries
|
|---|
| 167 | (i.e. junit.jar) in the declaration. This solves the problem of
|
|---|
| 168 | ANT_HOME/lib needing to contain every jar possibly needed by every
|
|---|
| 169 | user/project. You still have to declare the tasks one by one,
|
|---|
| 170 | something we will fix in Ant1.7</P>
|
|---|
| 171 | </OL>
|
|---|
| 172 | <H3>Adapters</H3>
|
|---|
| 173 | <P>These are Java classes that <I>adapt</I>> arbitrary Java
|
|---|
| 174 | classes into ant tasks or types. There has always been some of this
|
|---|
| 175 | stuff inside Ant, but now you can <taskdef> a task by naming
|
|---|
| 176 | not just the implementation class, but the adapter class. An adapter
|
|---|
| 177 | is essentially a meta task implementation -something that can be used
|
|---|
| 178 | to create new tasks dynamically. Which, when you consider that the
|
|---|
| 179 | core of Ant is fundamentally an XML to java mapping system and a
|
|---|
| 180 | simple workflow engine, may let you do very unusual things with Ant.
|
|---|
| 181 | </P>
|
|---|
| 182 | <H3>Antlib: Ant libraries</H3>
|
|---|
| 183 | <P>This is something we will expand in future. Till now you could
|
|---|
| 184 | declare tasks and types with <taskdef> and <typedef>. If
|
|---|
| 185 | they were in a jar, you could write a properties file and name the
|
|---|
| 186 | resource path of the file in the jar. If you wanted to have both
|
|---|
| 187 | tasks and types, you had name a shared classloader. If you wanted to
|
|---|
| 188 | add more things -such as conditions or mappers, you were out of luck.</P>
|
|---|
| 189 | <P>Antlibs are Ant Libraries, JAR files containing the code to extend
|
|---|
| 190 | Ant, and an XML description file to describe how Ant is extended.
|
|---|
| 191 | Before anyone panics at 'yet another XML descriptor syntax' to learn:
|
|---|
| 192 | you may already know the syntax. We call it "Ant build files".
|
|---|
| 193 | Actually it is a subset: it can only contain those task declarations
|
|---|
| 194 | that are derived from org.apache.tools.ant.taskdefs.AntlibDefinition.
|
|---|
| 195 | That includes <taskdef> and <typedef>, and <I>any other
|
|---|
| 196 | task you choose to derive. </I>We are experimenting with scripting
|
|---|
| 197 | and some kind of task predefinition declarations in antlibs. With the
|
|---|
| 198 | latter, you will be able to write a predefined task -such as a
|
|---|
| 199 | <javac> derivative with the compiler options set, and then use
|
|---|
| 200 | it any of your build files. This is all too experimental to get into
|
|---|
| 201 | Ant1.6 -expect it in the successor. For now, start using antlibs and
|
|---|
| 202 | use the <taskdef> task to load them into your projects.</P>
|
|---|
| 203 | <H3>XML Namespace aware</H3>
|
|---|
| 204 | <P>Ant finally adopts XML namespaces. This is to address build file
|
|---|
| 205 | scalability; antlibs can be imported into their own namespaces, and
|
|---|
| 206 | so you can avoid namespace clashes with other libraries. If you do
|
|---|
| 207 | not know what namespaces are, do not worry -they are not compulsory.</P>
|
|---|
| 208 |
|
|---|
| 209 | <h3>All tasks can go in at the toplevel</h3>
|
|---|
| 210 | <p>
|
|---|
| 211 |
|
|---|
| 212 | Prior to Ant1.6, only three tasks were allowed outside
|
|---|
| 213 | targets : <taskdef>,<typedef> and <property>.
|
|---|
| 214 | Ant 1.6 puts an end to this distinction; anything can go in at the top
|
|---|
| 215 | level. This is partly because there were many more tasks that merited the
|
|---|
| 216 | option based on the original rationale of "global initialization tasks":
|
|---|
| 217 | <import> and <antlib> were the new additions, but existing
|
|---|
| 218 | tasks like <condition>, <available>, <xmlproperties>
|
|---|
| 219 | and <loadproperties> had equal rights.
|
|---|
| 220 | </p>
|
|---|
| 221 | <p>
|
|---|
| 222 | Rather that expand the set slightly, now all tasks are allowed outside
|
|---|
| 223 | targets. This gives external tasks the same rights as built in code,
|
|---|
| 224 | eliminates sporadic bug reports, and annoying error messages. It gives
|
|---|
| 225 | users the ability to write build files without any targets at all; the
|
|---|
| 226 | top-level declarations are processed in sequence.
|
|---|
| 227 | </p>
|
|---|
| 228 |
|
|---|
| 229 | On a style note, we strongly advocate using this feature carefully. It
|
|---|
| 230 | is best if zero-side-effect, initialization-only tasks get put into the
|
|---|
| 231 | top level. Remember also that all top level statements are processed in
|
|---|
| 232 | order, before any targets are executed. Even tasks at the end of the
|
|---|
| 233 | file will get executed before targets declared above them.
|
|---|
| 234 |
|
|---|
| 235 | <H2>New Tasks</H2>
|
|---|
| 236 | <P>As usual, the task base is growing and expanding. These days the
|
|---|
| 237 | ant core is resisting adopting many of the highly worthy donations of
|
|---|
| 238 | tasks from people, because they make maintenance and firefighting
|
|---|
| 239 | worse. Our current stance is that except in special circumstances,
|
|---|
| 240 | Ant tasks to support third party open source projects, should live
|
|---|
| 241 | with the projects themselves. This keeps them in sync with the
|
|---|
| 242 | libraries they integrate with, avoids GPL/Apache licensing issues,
|
|---|
| 243 | and reduces the Ant team's support workload, letting them focus on
|
|---|
| 244 | the core. The antlib mechanism is intended to make it easier for
|
|---|
| 245 | people to load tasks from libraries for this very reason.</P>
|
|---|
| 246 | <P>That said, we are pleased to introduce many new tasks. Of
|
|---|
| 247 | particular interest may be the SSH tasks, which let one deploy code
|
|---|
| 248 | to remote servers securely. Now you really can do live updates with
|
|---|
| 249 | Ant -if the operations team will let you. The other one that is quite
|
|---|
| 250 | interesting is <subant>. This is an extension of the <ant>
|
|---|
| 251 | task, to take an entire fileset of directories and run their build
|
|---|
| 252 | files. This is incredibly useful in very large projects. This does
|
|---|
| 253 | not mean that we are advocating the many-build-file development
|
|---|
| 254 | pattern, but in a sufficiently complex project it happens anyway.
|
|---|
| 255 | <subant> keeps things manageable.</P>
|
|---|
| 256 | <H2>What else</H2>
|
|---|
| 257 | <P>So, what is new in Ant1.6? Lots of stuff. You will have to look at
|
|---|
| 258 | the <A HREF="WHATSNEW">whatsnew</A> file to see, but here are some
|
|---|
| 259 | key points.
|
|---|
| 260 | </P>
|
|---|
| 261 | <OL>
|
|---|
| 262 | <LI><P STYLE="margin-bottom: 0in">Bug fixes. We know, some things
|
|---|
| 263 | were broken in 1.5. In ant1.6 we have moved the bugs, fixing the
|
|---|
| 264 | ones we could, and no doubt adding different ones. Hopefully the
|
|---|
| 265 | total bug count has decreased.
|
|---|
| 266 | </P>
|
|---|
| 267 | <LI><P STYLE="margin-bottom: 0in">New platforms: Open VMS and HP's
|
|---|
| 268 | NonStop Kernel (Tandem) OS. OpenVMS is very different from the rest;
|
|---|
| 269 | Read the <exec> task documentation carefully.
|
|---|
| 270 | </P>
|
|---|
| 271 | <LI><P STYLE="margin-bottom: 0in">Spawning. <java> and <exec>
|
|---|
| 272 | started applications can outlive Ant if you set spawn=true. Note
|
|---|
| 273 | that the moment you do so, Ant cannot bind to their input or output,
|
|---|
| 274 | for obvious reasons.
|
|---|
| 275 | </P>
|
|---|
| 276 | <LI><P>Synchronisation with Java versions (heh, thought by moving
|
|---|
| 277 | javah's entry point that you could hide from us? Think again).</P>
|
|---|
| 278 | <LI><P>Synchronization with third party libraries. Of special note:
|
|---|
| 279 | we have moved to the Apache commons-net.jar, the successor to
|
|---|
| 280 | NetComponents for telnet and FTP as well as Apache BSF, the
|
|---|
| 281 | successor to IBM BSF, for script.</P>
|
|---|
| 282 | </OL>
|
|---|
| 283 | <P>There are many more enhancements, so we hope you will find your
|
|---|
| 284 | build projects easier. We have, as usual, jumped through hoops to
|
|---|
| 285 | keep existing builds working. If your build file stops working, and
|
|---|
| 286 | it isn't something listed on the 'changes that may break your build'
|
|---|
| 287 | part of the WHATSNEW file, or something we know about on bugzilla,
|
|---|
| 288 | please don't hesitate to file a new bug report, preferably one with a
|
|---|
| 289 | replicable test and a patch to fix the problem. Please, please,
|
|---|
| 290 | please, do a search on bugzilla first. You do not want to be the
|
|---|
| 291 | seventy-third person to complain that Ant1.6 doesn't do something
|
|---|
| 292 | that it should.
|
|---|
| 293 | </P>
|
|---|
| 294 | <P>Thanks,
|
|---|
| 295 | </P>
|
|---|
| 296 | <P>The Ant development team.
|
|---|
| 297 | </P>
|
|---|
| 298 | <H3>Acknowledgements</H3>
|
|---|
| 299 | <UL>
|
|---|
| 300 | <LI><P>Many thanks for Antoine to being the build manager for this
|
|---|
| 301 | release!
|
|---|
| 302 | </P>
|
|---|
| 303 | <LI><P>Thank you to everyone who supplies the components we use in
|
|---|
| 304 | Ant, particularly JUnit, commons-logging, log4J, bcel, ORO, Xerces, and Xalan.
|
|---|
| 305 | </P>
|
|---|
| 306 | <LI><P>Everyone who has supplied bug reports, especially those with
|
|---|
| 307 | patches and tests.</P>
|
|---|
| 308 | <LI><P>IDE projects who incorporate Ant into their products. Not
|
|---|
| 309 | only does this help Ant's success, you find lots of interesting
|
|---|
| 310 | integration defects. Special mention to the Eclipse team for fixing
|
|---|
| 311 | our memory leaks :)</P>
|
|---|
| 312 | </UL>
|
|---|
| 313 | <H3>Call to Action</H3>
|
|---|
| 314 |
|
|---|
| 315 | <P>
|
|---|
| 316 |
|
|---|
| 317 | It is an interesting time for Java. .NET is a serious challenger, and
|
|---|
| 318 | will get better. A core strength of Java over .NET is its community. It
|
|---|
| 319 | is the community that gave the world leading edge development tools and
|
|---|
| 320 | other core components: Ant, JUnit, XDoclet, hsqldb, Hibernate, Struts,
|
|---|
| 321 | etc. These things weren't created by JCP committees, or built according
|
|---|
| 322 | to the strategic vision of a Fortune 100 company. They were written by
|
|---|
| 323 | Java developers, for Java developers, usually to meet their own tactical
|
|---|
| 324 | goals.
|
|---|
| 325 |
|
|---|
| 326 | </P>
|
|---|
| 327 |
|
|---|
| 328 | <P>If Java is to survive -and we think it ought to- everyone who can
|
|---|
| 329 | needs to become active members of that community. It could be helping
|
|---|
| 330 | with Ant, but it could just as easily be helping with any other open
|
|---|
| 331 | source Java project, be hosted by Apache, FSF, Sourceforge or someone
|
|---|
| 332 | else, be it server-side, client-side or mobile-side. It could be an
|
|---|
| 333 | existing project, or it could be your own idea as to how things could
|
|---|
| 334 | be better. The key is: things will only be better if you put in the
|
|---|
| 335 | time to make it so.
|
|---|
| 336 | </P>
|
|---|
| 337 | <H3>Call to Inaction</H3>
|
|---|
| 338 | <P>A special message to whoever it is in charge of commands in
|
|---|
| 339 | tools.jar: stop moving your entry points! In Ant1.5 we had to deal
|
|---|
| 340 | with the 'classic' javac entry point going away in Java1.4.0,
|
|---|
| 341 | seemingly coming back later. In Java 1.4.2, the javah entry point
|
|---|
| 342 | moved. The traditional command line invocation mechanism has been
|
|---|
| 343 | replaced by hosted invocation -Ant, Maven, IDEs, etc, and moving
|
|---|
| 344 | entry points around breaks these host applications. Even if we get a
|
|---|
| 345 | bug fix out in Ant a few weeks after the Java release, it takes
|
|---|
| 346 | months for this to trickle down to end users, especially via IDEs and
|
|---|
| 347 | other distributions. For example, Sun's own Java Web Services
|
|---|
| 348 | Developer Pack ships with Ant1.5.1, and so cannot run <javah>
|
|---|
| 349 | on a 1.4.2 installation.
|
|---|
| 350 | </P>
|
|---|
| 351 | </BODY>
|
|---|
| 352 | </HTML> |
|---|
