javadoc custom doclet regression bug in 1.9.3? (was: [ANN] Apache Ant 1.9.3 Released)

2014-01-02 Thread Earl Hood 
On Sat, Dec 28, 2013 at 11:47 PM, Antoine Levy Lambert wrote:

> The Apache Ant Team is proud to announce the 1.9.3 release of Ant.
  [snip]

I think I may have encountered a regression bug.

When trying to use a custom doclet (DocFlex/Doclet v1.6.1), I get an NPE
at the very end of the generation.  The doclet appears to have done its
job, but Ant throws an NPE at the very end.  I get no NPE in Ant 1.8.4
or Ant 1.9.2.

It will take me a little time to create a self-contained, reproducable
case, but I figure I should give a "heads-up" here in case someone on
the development team may have an immediate idea of the cause.

The following is the XML fragment from the project scripts that invokes
the javadoc target.  Following the fragment is the stack trace printed
by Ant:


  
  

  
  
  
  
  




  


  



  



The error generated by Ant 1.9.3:

BUILD FAILED
java.lang.NullPointerException
at 
org.apache.tools.ant.taskdefs.Javadoc.postProcessGeneratedJavadocs(Javadoc.java:2450)
at org.apache.tools.ant.taskdefs.Javadoc.execute(Javadoc.java:1790)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:292)
at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
at org.apache.tools.ant.Task.perform(Task.java:348)
at org.apache.tools.ant.Target.execute(Target.java:435)
at org.apache.tools.ant.Target.performTasks(Target.java:456)
at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1393)
at org.apache.tools.ant.Project.executeTarget(Project.java:1364)
at 
org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41)
at org.apache.tools.ant.Project.executeTargets(Project.java:1248)
at org.apache.tools.ant.Main.runBuild(Main.java:851)
at org.apache.tools.ant.Main.startAnt(Main.java:235)
at org.apache.tools.ant.launch.Launcher.run(Launcher.java:280)
at org.apache.tools.ant.launch.Launcher.main(Launcher.java:109)

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: javadoc custom doclet regression bug in 1.9.3?

2014-01-03 Thread Earl Hood 
On Fri, Jan 3, 2014 at 12:37 AM, Stefan Bodewig wrote:

> 
...
> So in your case destdir is null, something I didn't account for, sorry.
>
> I'll open a bugzilla issue so it is properly tracked and fix it in
> trunk.  Maybe you can set destdir to some non-null value as a
> workaround?

Just tried it, and setting destdir does avoid the NPE.  The doclet in
question does support the -d option that destdir setting maps to.

Thanks for the quick response and subsequent fix.

--ewh

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: [ant] branch master updated: add java.security.manager=allow while launching against Java 19

2022-02-07 Thread Earl Hood 
How exactly does setting the sysprop for only 18 and 19 allow folks to test
their stuff?  If Ant currently depends on the security manager to operate,
why not set the sysprop regardless, then remove in future when a
replacement API exists?

Since I work on a project that embeds Ant and uses it API, I am trying
assess what I need to do on my end to mitigate the problem. I do not use
the launcher scripts, but invoke Ant directly as an embedded service (same
JVM) or via an external JVM process (most common usage).

Regards,

--ewh

On Mon, Feb 7, 2022, 4:18 AM Jaikiran Pai  wrote:

> Hello Stefan,
>
> I was planning to send out a mail about this change later tonight. But
> good you brought this up. To give some background, the security manager
> changes starting Java 18 make it such that setting of the security
> manager at runtime now throws an exception, which effectively fails all
> builds since Ant by default sets up a security manager. After various
> experimentations and checking over with the JDK team, it appears that we
> (Ant) can't get rid of setting the security manager till the JDK team
> provides an API to prevent System.exit(...) calls. So in the meantime to
> allow users of Ant to build their projects and test for any issues
> against Java 18 (and now Java 19 EA), I decided to specifically set this
> system property only for these specific versions. Initially I had only
> done it for Java 18, hoping that a new API for System.exit(...)
> prevention would be  availbale in 19, but it isn't ready so far. So the
> launch scripts (the Linux one and the .bat for Windows one) have both
> been updated to set this system property only for Java 18 and 19. I
> expect this to be a temporary thing till the new API is available. Once
> the new API is available, I think we should just get rid of this setting
> of system property even for Java 18 and 19 (since I don't expect many to
> be using these releases once the newer versions are available).
>
> Now coming to the actual implementation of this, it took me multiple
> weekends to get the .bat version to correctly work. Mainly due to lack
> of easy access to a Windows setup plus my general lack of knowledge of
> bat scripting and some gotchas when it comes to .bat parsing and the
> "errorlevel" values. Ultimately the one I committed ant.bat now launches
> the Java command twice and expects it to dump certain property values,
> which are then used by "find" to see if the version is 18 or 19. So
> essentially, launching Ant (on Windows) now additionally triggers
> lauching of two Java process (they do exit) just to check the version.
> It's not the best way, but I couldn't find any other way to do this.
>
> As for the Linux version of the ant launch script it does a similar
> thing but in its case it just launches the Java program once and figures
> out if the version is 18 or 19.
>
> With these changes the CI builds which run Ant tests against Java 18, 19
> and previous version like Java 17 now work fine. However, like I said my
> scripting skills are minimal, so if any of these changes in these
> scripts can be done in a better way, please feel free to do so. I would
> do it myself, but it's going to take me trial and error methods to get
> it right :)
>
> -Jaikiran
>
> On 07/02/22 12:26 pm, Stefan Bodewig wrote:
> > On 2022-02-07,  wrote:
> >
> >> - if [ "$JAVA_SPEC_VERSION" = "java.specification.version=18" ]; then
> >> + if [ "$JAVA_SPEC_VERSION" = "java.specification.version=18" ] || [
> "$JAVA_SPEC_VERSION" = "java.specification.version=19" ]; then
> > Bourne shell's case may make this more
> > readable (not sure whether there is a Windows batch file equivalent)
> >
> > case $JAVA_SPEC_VERSION in
> >   java.specification.version=18 | \
> >   java.specification.version=19 )
> > ...
> > ;;
> > esac
> >
> > But I'm afraid this is not going to scale :-)
> >
> > In the long run we probably are better off by enumerating the JDKs where
> > we don't want to set the property (ten from 8 to 17, but this is a fixed
> > list that doesn't need to change with every release).
> >
> > Stefan
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> > For additional commands, e-mail: dev-h...@ant.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> For additional commands, e-mail: dev-h...@ant.apache.org
>
>

Message output level not public for Project class

2022-09-07 Thread Earl Hood 
Ant Devs,

Working on a custom task that will exec an external program. One thing I
would like to do is if ant is invoked with debugging output level, set the
debugging flag to the external program.

Unfortunately, it seems to get the current logging level is not easy, as
the level set when Ant is invoked is private with no getter method to
retrieve it.  I see the level is passed into build listeners, but those
APIs also do not expose the level.

Is there any way to retrieve the current logging level, and if not, is
reasonable to make the current level accessible via a public method in the
Project class?

Best regards,

--ewh

Re: Message output level not public for Project class

2022-10-11 Thread Earl Hood 
This is very helpful. Did not even consider using reflection. I adapted
your method into a static utility method that given a Project instance,
will return the logging level for it.

Thanks,

--ewh


On Mon, Oct 10, 2022, 11:56 PM Gilles Querret <
g.quer...@riverside-software.fr> wrote:

>
> So far I've used this workaround to retrieve the log level:
>
> https://github.com/Riverside-Software/pct/blob/d8446a002aaf2efb255d2016a16e9a71f7ad269f/src/java/com/phenix/pct/PCT.java#L593
> Usage in the Ant task:
>
> https://github.com/Riverside-Software/pct/blob/master/src/java/com/phenix/pct/PCTRun.java#L475
>
> Code was written years ago, there might be a better solution now.
>
> Gilles
>

Re: [ant] branch master updated: add java.security.manager=allow while launching against Java 19

2022-11-17 Thread Earl Hood 
Figured give an update wrt our project: The method used by Netbeans project
as cited by Jan appears to work.

I have not done full testing wrt to Ant as it appears the use of the
SecurityManager in Ant is limited in scope to invoking another Java class
in the same JVM, which we do not seem to do (nornally enable forking).
Regardless, since Ant is included with our product, I implemented the
Netbeans approach so we can set java.security.manager=allow unconditionally
regardless of JRE version.

Since I wanted to avoid creating a custom version of ant, for the one case
we invoke the 'ant' command and not org.apache.tools.ant.launch.Launcher
directly, I set the LOCALCLASSPATH env to point to a jar containing
allow.class, and set ANT_OPTS=-Djava.security.manager=allow

For the embedded scenarios, I updated our invocation scripts to set the
sysprop when JVM is invoked and ensure allow.class is in classpath.

For Ant itself, I think if the "allow" class is included in
ant-launcher.jar, the command scripts can be updated to always set the
system property, avoiding the need to invoke java twice: first time to get
version and second time to actually do the job.

--ewh

On Tue, Feb 8, 2022, 12:35 AM Jan Lahoda  wrote:

>
> FWIW, NetBeans added a SecurityManager called "allow", that uninstalls
> itself as soon as possible:
>
> https://github.com/apache/netbeans/blob/master/platform/o.n.bootstrap/src/allow.java
>
> Then -Djava.security.manager=allow works on the platforms supported by
> NetBeans - before JDK 12, "allow" is installed and quickly uninstalled, but
> setting another SecurityManager is allowed.
>
> Jan
>

Re: [ANNOUNCE] Apache Ant 1.10.14 released

2023-09-28 Thread Earl Hood 
Ant Developers,

Was it intended to keep code in ant.bat that does an initial execution of
java.exe to check specification level regarding the setting of
java.security.manager?

I see the bourne shell script has no equivalent code.

--ewh


On Mon, Aug 21, 2023, 12:51 AM Jaikiran Pai  wrote:

> The Apache Ant Team is pleased to announce the release of Apache Ant
> 1.10.14.
> ...

Re: Depedency to tools.jar

2014-06-13 Thread Earl Hood 
On Wed, Jun 11, 2014 at 9:47 PM, Antoine Levy Lambert wrote:

> your wish makes sense. You are right, only the specific ant tasks such
> as javac/javadoc/javah which use java command line tools should worry
> about tools.jar being around.
>
> Before you open a bug report, let’s see whether other Ant committers
> have opinions on this topic.

I know my opinion has no real weight on this list, but I definitely
welcome a change that suppresses the warning.

This has been a nuisance for years in a project I am involved with that
makes heavy use of Ant and having to document and explain to our users
that the warning can be ignored since our project does not use any of
the tasks that depend on tools.jar.

Regards,

--ewh

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

ZipOutputStream exception in Ant 1.9.5 and 1.9.6

2015-07-20 Thread Earl Hood 
It appears the zip problems have not been fully fixed in Ant.

I have a program that uses Ant's ZipOutputStream class, and it has had
no problems with versions of Ant 1.9.4 and earlier.  However, with Ant
1.9.5 and 1.9.6, I get the following exception:

  java.lang.ArrayIndexOutOfBoundsException
at java.lang.System.arraycopy(Native Method)
at 
org.apache.tools.zip.ZipOutputStream.createCentralFileHeader(ZipOutputStream.java:1264)
at 
org.apache.tools.zip.ZipOutputStream.createCentralFileHeader(ZipOutputStream.java:1178)
at 
org.apache.tools.zip.ZipOutputStream.writeCentralDirectoryInChunks(ZipOutputStream.java:513)
at org.apache.tools.zip.ZipOutputStream.finish(ZipOutputStream.java:498)
at org.apache.tools.zip.ZipOutputStream.close(ZipOutputStream.java:940)
at com.pbmassoc.nsiv.util.ZipDMs.zipFlattenDMs(ZipDMs.java:102)
at com.pbmassoc.nsiv.util.ZipDMs.main(ZipDMs.java:174)
...snip...


The following is the code block that uses ZipOutputStream.  There are
some application-specific calls in it, but I figure they are fairly
easy to understand what they do:

  public static void zipFlattenDMs(
  File outZip,
  File dir
  ) throws IOException {
List files = NSIVUtil.getDMFiles(dir);
ZipOutputStream out = null;
try {
  // We use apache tools (Ant) ZipOutputStream.
  out = new ZipOutputStream(outZip);
  out.setLevel(9);
  for (File f : files) {
String basename = f.getName();
if (!FileUtil.isXml(basename) ||
(!basename.startsWith(DMC_PREFIX) &&
 !basename.startsWith(DME_PREFIX))) {
  continue;
}
String dmcBase   = S1000DUtil.extractDMCBase(basename);
String entryName = dmcBase + ".xml";
ZipEntry e   = new ZipEntry(entryName);
e.setComment(basename);
e.setTime(f.lastModified());
out.putNextEntry(e);
NSIVUtil.sendFile(f, out);
out.closeEntry();
  }
} finally {
  if (out != null) {
out.close();
  }
}
  }


Exception is thrown when calling the close() method on `out' in the
finally block.

As a test, I modified the above code to use Java's version of
ZipOutputStream, and I received no errors.  The change is basically
modifying the constructor call as follows:

  out = new ZipOutputStream(new FileOutputStream(outZip));

And importing Java's classes and not Ant's (this includes using Java's
ZipEntry classs).

I may be able to live with using the Java library implementation of the
zip classes, but it does raise some concerns about the robustness of the
Ant's zip-related tasks, which we use in various Ant build files.  The
testing I have performed with our project has shown no other problems.

I am guessing the following work noted in the release notes:

 * ported some of the write-optimization of Commons Compress 1.10 to
   the ZIP package

introduced regression bugs, bugs that have not been fully flushed out,
or detected.

Any guidance appreciated,

--ewh

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: ZipOutputStream exception in Ant 1.9.5 and 1.9.6

2015-07-20 Thread Earl Hood 
On Mon, Jul 20, 2015 at 3:56 PM, I wrote:

> I have a program that uses Ant's ZipOutputStream class, and it has had
> no problems with versions of Ant 1.9.4 and earlier.  However, with Ant
> 1.9.5 and 1.9.6, I get the following exception:
>
>   java.lang.ArrayIndexOutOfBoundsException
> at java.lang.System.arraycopy(Native Method)
> at 
> org.apache.tools.zip.ZipOutputStream.createCentralFileHeader(ZipOutputStream.java:1264)
> at 
> org.apache.tools.zip.ZipOutputStream.createCentralFileHeader(ZipOutputStream.java:1178)
> at 
> org.apache.tools.zip.ZipOutputStream.writeCentralDirectoryInChunks(ZipOutputStream.java:513)
> at org.apache.tools.zip.ZipOutputStream.finish(ZipOutputStream.java:498)
> at org.apache.tools.zip.ZipOutputStream.close(ZipOutputStream.java:940)
> at com.pbmassoc.nsiv.util.ZipDMs.zipFlattenDMs(ZipDMs.java:102)
> at com.pbmassoc.nsiv.util.ZipDMs.main(ZipDMs.java:174)
> ...snip...

I believe I found the source of the problem.  The problem is in the
createCentralFileHeader() method on line 1261 of
org/apache/tools/zip/ZipOutputStream.java:

int commentStart = extraStart + commentLen;

I think it should be:

int commentStart = extraStart + extra.length;

When I made the change in the 1.9.6 source bundle and built from source,
I no longer got the error and the zip file created verifies with unzip
and 7zip.

It appears that Ant's core code never calls ZipEntry.setComment(), hence
this bug was overlooked.

Since the project I am on requires the ability to work with official
releases of Ant, I will comment out the setComment() call in the project
code; comments are not needed for our application to function.

Hopefully, the above change can be incorporated into the Ant codebase.

--ewh

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: Drop Support for Java5, Move on to Ant 1.10.0?

2016-03-06 Thread Earl Hood 
On Mar 6, 2016 4:12 AM, "Stefan Bodewig" wrote:
>
> I'm not sure whether moving to Java6 is worth the effort since it has
> been EOLed as well, even Java7 is no longer officially supported by
> Oracle, but personally I wouldn't want to require Java8 right now.

Java 1.6 extended support lasts til December 2018.  I would think any
decision on what the new base version to support should consider the
extended support schedule.

I do know of some company environments that are still on 1.6.

--ewh

Re: Ant Contrib

2017-06-04 Thread Earl Hood 
On Sun, Jun 4, 2017 at 4:47 AM, Gintautas Grigelionis wrote:

> I noticed that Ivy has Ant Contrib as a dependency. It's a project
> that has been asleep for a decade, and it shows. So I decided to
> revive it, and the result is here:
> https://github.com/twogee/ant-contrib

When you say "revive", what exactly do you plan on changing?  Are you
planning on taking ownership of the project or making a fork?

I am sure I am not the only person who is involved in a project that
makes use of ant-contrib tasks.

--ewh

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: [PR] improve filtering performance [ant]

2025-06-01 Thread Earl Hood 
Why is the initial capacity to the ArrayList constructor commented out.
IIRC, the default capacity is 10, so in your test case, you are getting hit
with a reallocation each time. What is the metrics if you do not comment
out STRINGS.length to the ArrayList ctor?

--ewh


On Sat, May 31, 2025, 9:16 AM esaulpaugh (via GitHub) 
wrote:

>
> esaulpaugh commented on PR #212:
> URL: https://github.com/apache/ant/pull/212#issuecomment-2925232549
>
>I have not faced a performance issue but I discovered this trick while
> optimizing a String parser in one of my projects. It performs better in
> microbenchmarks compared to building an `ArrayList`. I suggested it to gson
> as well: https://github.com/google/gson/pull/2734
>
>On corretto-11.0.27 aarch64:
>
>```
>Benchmark Mode  Cnt   ScoreError  Units
>Measure.arr   avgt   14  17.527 ±  0.435  ns/op
>Measure.list  avgt   14  44.013 ± 27.030  ns/op
>```
>
>On graalvm-jdk-24+36.1 (24.2.0) aarch64:
>
>```
>Benchmark Mode  Cnt   Score   Error  Units
>Measure.arr   avgt   14   9.795 ± 0.173  ns/op
>Measure.list  avgt   14  41.321 ± 3.544  ns/op
>```
>
>```java
>@State(Scope.Benchmark)
>@Fork(2)
>@BenchmarkMode(Mode.AverageTime)
>@Warmup(iterations = 7, time = 500, timeUnit = TimeUnit.MILLISECONDS)
>@Measurement(iterations = 7, time = 500, timeUnit =
> TimeUnit.MILLISECONDS)
>@OutputTimeUnit(TimeUnit.NANOSECONDS)
>public class Measure {
>
>  private static final String[] STRINGS = { null, "", "00", "\0",
> "...", null, "H", "ab", "+", "UUU", null, null, "5\t5" };
>
>  @Benchmark
>  public void list(Blackhole blackhole) {
>  ArrayList list = new ArrayList<>(/* STRINGS.length */);
>  for (String s : STRINGS) {
>  if (s != null) {
>  list.add(s);
>  }
>  }
>  blackhole.consume(list.toArray(new String[0]));
>  }
>
>  @Benchmark
>  public void arr(Blackhole blackhole) {
>  String[] arr = new String[STRINGS.length];
>  int i = 0;
>  for (String s : STRINGS) {
>  if (s != null) {
>  arr[i++] = s;
>  }
>  }
>  blackhole.consume(Arrays.copyOf(arr, i));
>  }
>}
>```
>
>It's unlikely that this change alone would make a noticeable difference
> to users, but small changes can add up eventually, in my experience.
>
>
> --
> This is an automated message from the Apache Git Service.
> To respond to the message, please log on to GitHub and use the
> URL above to go to the specific comment.
>
> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
>
> For queries about this service, please contact Infrastructure at:
> us...@infra.apache.org
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> For additional commands, e-mail: dev-h...@ant.apache.org
>
>

Support for -cp launcher option

2025-05-29 Thread Earl Hood 
Ant Devs,

I recently came across the need to use the -cp launcher option instead of
-lib as I needed to control which jars in a directory are loaded.  However,
I noticed -cp is undocumented and only realized it existed by examining the
Launcher.java source.

Question: Will the -cp option continued to be supported even though it is
undocumented?

Thanks,

--ewh