http://nagoya.apache.org/bugzilla/show_bug.cgi?id=1284
*** shadow/1284 Tue Apr 10 06:15:44 2001
--- shadow/1284.tmp.25519 Tue Apr 10 06:15:45 2001
***************
*** 0 ****
--- 1,36 ----
+ +============================================================================+
+ | JarSigner runs out-of memory |
+ +----------------------------------------------------------------------------+
+ | Bug #: 1284 Product: Ant |
+ | Status: NEW Version: 1.3 |
+ | Resolution: Platform: PC |
+ | Severity: Major OS/Version: |
+ | Priority: Medium Component: Optional Tasks |
+ +----------------------------------------------------------------------------+
+ | Assigned To: [EMAIL PROTECTED] |
+ | Reported By: [EMAIL PROTECTED]
|
+ | CC list: Cc: |
+ +----------------------------------------------------------------------------+
+ | URL: |
+ +============================================================================+
+ | DESCRIPTION |
+ At least on Win32-platforms the JarSigner might run out of memory, if it is
+ performed for large archives. The reason for that is that SignJar.java uses
the
+ command:
+
+ cmd.setExecutable("jarsigner");
+
+ to perform that task. This causes Win32 to run JARSIGNER.EXE to sign the
+ specified task. So far so good, but JARSIGNER.EXE starts it's own JVM to run
+ sun.security.tools.JarSigner! This separate VM defines own limitations for
+ maximum memory-usage, which defaults to approximately 64MB of RAM for common
+ enviroments.
+ Possible fixes/workarounds:
+
+ 1) Starting a new JVM explititly (specifiying -Xms and -Xmx attributes, where
-
+ Xmx should specify a value below available physical RAM). Example:
+ JAVA.EXE -Xms48m -Xmx240m ... sun.security.tools.JarSigner ...
+
+ 2) Launching the JarSigner within the same JVM as ANT is running in. This
task
+ could be performed by using the (as far as I see undocumented) command:
+ new sun.security.tools.JarSigner().run(String args[]);
