Bug 33882 - Apt task with fork="false" and factory tag
Summary: Apt task with fork="false" and factory tag
Alias: None
Product: Ant
Classification: Unclassified
Component: Core (show other bugs)
Version: 1.7.0
Hardware: PC Linux
: P2 normal (vote)
Target Milestone: 1.7.0
Assignee: Ant Notifications List
Keywords: PatchAvailable
Depends on:
Reported: 2005-03-07 21:08 UTC by Dave Smith
Modified: 2009-08-18 07:06 UTC (History)
3 users (show)

Test case for failure (16.83 KB, application/zip)
2005-03-28 05:22 UTC, Rog
Forcing fork on apt task (2.89 KB, patch)
2005-04-17 02:22 UTC, Rog
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Dave Smith 2005-03-07 21:08:43 UTC
When the apt task is invoked with forked="false" and a factory attribute set,
the factory class is not found even though it is defined in the classpath. If
fork is set to true it works fine. I am guessing that apt is looking at the ant
classpath not the target classpath.
Comment 1 Matt Benson 2005-03-07 21:17:31 UTC
Without knowing much about this particular task, this sounds like typical Ant
compilation-related-task behavior to me.
Comment 2 Steve Loughran 2005-03-09 23:59:01 UTC
Have you tried <factoryclasspath>
Comment 3 Dave Smith 2005-03-10 05:13:25 UTC
Fisrtly it is (In reply to comment #1)
> Without knowing much about this particular task, this sounds like typical Ant
> compilation-related-task behavior to me.

If this is not fixable then the fork option should not be available and it
should always fork.
Comment 4 Dave Smith 2005-03-10 05:15:12 UTC
(In reply to comment #2)
> Have you tried <factoryclasspath>

Firstly it is factoryPathRef so ..

<path id="factory.path">
    <fileset dir="../ejb3/dest/">
      <include name="ejbFactory.jar"/>
 <apt fork="no" srcdir="." destdir="build"
      <include name="com/theappman/followup/**"/>

Output ..
 [apt] An exception has occurred in apt (1.5.0_01). Please file a bug at the
Java Deve loper Connection (http://java.sun.com/webapps/bugreport)  after
checking the Bug Parade for  duplicates. Include your program and the following
diagnostic in your report.  Thank you.
      [apt] java.lang.NoClassDefFoundError:
      [apt]     at java.lang.ClassLoader.defineClass1(Native Method)
      [apt]     at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
      [apt]     at
      [apt]     at java.net.URLClassLoader.defineClass(URLClassLoader.java:260)
      [apt]     at java.net.URLClassLoader.access$100(URLClassLoader.java:56)
      [apt]     at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
      [apt]     at java.security.AccessController.doPrivileged(Native Method)
      [apt]     at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
      [apt]     at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
      [apt]     at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
      [apt]     at com.sun.tools.apt.comp.Apt.main(Apt.java:287)
      [apt]     at
      [apt]     at com.sun.tools.apt.main.Main.compile(Main.java:1075)
      [apt]     at com.sun.tools.apt.main.Main.compile(Main.java:938)
      [apt]     at com.sun.tools.apt.Main.processing(Main.java:95)
      [apt]     at com.sun.tools.apt.Main.process(Main.java:43)
      [apt]     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
      [apt]     at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav a:39)
      [apt]     at
      [apt]     at java.lang.reflect.Method.invoke(Method.java:585)
      [apt]     at
      [apt]     at org.apache.tools.ant.taskdefs.Javac.compile(Javac.java:932)
      [apt]     at org.apache.tools.ant.taskdefs.Javac.execute(Javac.java:758)
      [apt]     at org.apache.tools.ant.taskdefs.Apt.execute(Apt.java:261)
      [apt]     at
      [apt]     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
      [apt]     at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav a:39)
      [apt]     at
      [apt]     at java.lang.reflect.Method.invoke(Method.java:585)
      [apt]     at
org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:1 04)
      [apt]     at org.apache.tools.ant.Task.perform(Task.java:365)
      [apt]     at org.apache.tools.ant.Target.execute(Target.java:341)
      [apt]     at org.apache.tools.ant.Target.performTasks(Target.java:369)
      [apt]     at
      [apt]     at org.apache.tools.ant.Project.executeTarget(Project.java:1176)
      [apt]     at
org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecut or.java:37)
      [apt]     at org.apache.tools.ant.Project.executeTargets(Project.java:1059)
      [apt]     at org.apache.tools.ant.Main.runBuild(Main.java:668)
      [apt]     at org.apache.tools.ant.Main.startAnt(Main.java:187)
      [apt]     at org.apache.tools.ant.launch.Launcher.run(Launcher.java:245)
      [apt]     at org.apache.tools.ant.launch.Launcher.main(Launcher.java:66)

Comment 5 Steve Loughran 2005-03-10 11:17:36 UTC

1. There is a <factorypath> element that is working in our tests; I havent added
a test for factorypath yet. 

2. We have done dynamic processor loading in our tests, so the basics work.
Either it is something to do with extra jar files, or some other reason, but we
are clearly not there yet.

3. the classpath is an inherited attribute. It gets used when forking, but
clearly not when not forking.

To be honest, it may be simpler if we just fork every time. The tool is
sluggish, so the startup hit is minimal, and it does reduce a variable from
every single bugrep

Comment 6 Steve Loughran 2005-03-10 11:19:23 UTC
I should add that this looks like a problem too

      [apt] java.lang.NoClassDefFoundError:

as if tools.jar is not being found, from another class in the jar itself. 
Comment 7 Rog 2005-03-28 05:22:46 UTC
Created attachment 14576 [details]
Test case for failure

Hi folks,

Apparently apt only works in non-forked mode if tools.jar is in the system
classpath.  I had to edit bin/ant in order to manually put it in the -classpath
VM option.

When I ran it without tools.jar in the system classpath, I got this:

java.lang.NoClassDefFoundError: com/sun/mirror/apt/AnnotationProcessorFactory

If I added tools.jar to the classpath passed to the apt task from within the
build file, I got this:

java.lang.ClassCastException: apt.extractintf.ExtractInterfaceProcessorFactory

(Which is about my test processor factory.)

Things work when running in forked mode, but large filesets (1000 classes)
cause Runtime.exec to fail.  So, if you decide to always fork, I guess you'll
have to generate a temp file with the sources to be processed and pass it
through "@files" to apt.

I'm attaching my test case to help in diagnostics.  I'm only sending 4 classes,
if you want the other 996 (which I doubt) tell me :-)

On a side note, I ran this with ant 1.6 and the apt-related classes compiled
from CVS HEAD.	The ant-apt.jar is in the attachment.  I tried 1.7alpha from
20050324, but it didn't work due to a wrong method name ("compile" instead of

Since this bug (#33853) has been fixed since 2005-03-07, and the buildlog.txt
from the nightlies area says that the build failed, I presume that what's being
served as 20050324 is in fact a very older build :-(
Comment 8 Rog 2005-03-28 05:37:44 UTC
I forgot to tell my environment: Windows 2000, jdk1.5.0_01, cygwin (running ant
or ant.bat didn't make any difference, so I don't think this is cygwin-related).
Comment 9 Steve Loughran 2005-03-30 15:19:10 UTC
Seems to me that eliminating the fork=false option before it gets used is the
simplest. The hit in start time is noise given how slow apt is, and the savings
in stability worthwhile.

thanks for the heads-up on command line size; going via a temp file and @files
would seem the best approach there too. Patches welcome :)
Comment 10 Rog 2005-04-17 02:22:18 UTC
Created attachment 14736 [details]
Forcing fork on apt task

Patches welcome, patch sent :-) Sorry for the delay.  This patch affects the
following files.

- Ignores fork attribute, always use AptExternalCompilerAdapter


- Fixes call to executeExternalCompile() to prevent command line size overflow

Please don't remove AptCompilerAdapter yet.  I filed a bug report in
java.sun.com bug database, let's see what they say.  I think that apt is
creating a class loader to load annotation factories, but is not giving it a
parent, that would explain why tools.jar must be on system classloader.  If
they fix it, we may restore non-forked execution.
Comment 11 Steve Loughran 2005-04-18 11:43:20 UTC
Thanks for the patch; I'll commit this when I get a chance. Nice to see that
you've encountered (and fixed) a problem w/ command line length too.

I think we'll have to flag this task in the docs as potentially unstable;
primarily because its a new thing from Sun that is still fairly raw, and they
will inevitably change things
Comment 12 Peter Reilly 2007-11-02 06:56:49 UTC
*** Bug 43782 has been marked as a duplicate of this bug. ***
Comment 13 Stefan Bodewig 2009-08-18 07:06:16 UTC
the patch turned into svn revision 348762 and svn revision 278229 both of which went into Ant 1.7.0