Ian Rogers wrote:
please give your comments on the attached patch. It tries to reduce the
size of char[] for strings used to hold numbers. It changes Float/Double
equals to use bit based comparisons rather than division. It increases
the use of valueOf methods. It adds a cache of values from
Hi,
Andrew John Hughes schrieb:
I'd second that. Are there clear performance benefits to justify
creating 256 objects ahead of time?
Not only does that introduce an overhead in initialising the Long
class, but it also results in increased
memory usage for all applications.
I'd also
2008/6/3 Robert Schuster [EMAIL PROTECTED]:
Hi Tom,
I am less sure about adding java-specific file name parsing to the
generic command-line parser code. That code is not supposed to be
specific to java tooling (at least frysk uses it, fwiw).
I will implement the @file handling
Hi Tom,
I am less sure about adding java-specific file name parsing to the
generic command-line parser code. That code is not supposed to be
specific to java tooling (at least frysk uses it, fwiw).
I will implement the @file handling ClasspathToolParser now. That way
only our Classpath tools
Andrew Haley wrote:
Ian Rogers wrote:
please give your comments on the attached patch. It tries to reduce the
size of char[] for strings used to hold numbers. It changes Float/Double
equals to use bit based comparisons rather than division. It increases
the use of valueOf methods. It adds a
Hi,
the following patch adds @file support to gjavah and gjar by enhancing
ClasspathToolParser with a few methods and making both tools use those.
The other tools are not affected by this change nor does this modify the
core getopt functionality (except that I made the 'programName' field
2008/6/3 Robert Schuster [EMAIL PROTECTED]:
Hi,
the attached does something very dumb: It makes a copy of an existing
class. Still I need it because otherwise a resulting binary is either
not runnable with classpath or with openjdk's class library.
A better patch would possibly refactor all
