Streamtokenizer

Sat May 10 11:22:00 GMT 2008

Andrew Haley wrote:
> Bryce McKinlay wrote:
>> On Sat, May 10, 2008 at 3:36 AM, Tom Tromey <tromey@redhat.com> wrote:
>>>>>>>> "OneGuy" == OneGuy <oneguyks@gmail.com> writes:
>>> OneGuy> Memory usage was even worse (55 MB with Classpath vs 35 MB with Sun's).
>>>>>> It looks like our nextToken will often create a new StringBuffer.
>>> Perhaps it would be better to make one and cache it.
>>>>>> FWIW I'd accept a clean patch to further optimize StreamTokenizer.
>>> Most likely the only reason it performs poorly is that it never popped
>>> up as a performance limiter before.
>> Double.parseDouble() could also be used, avoiding creating a Double each time.
>>>> I haven't really been following this stuff, but what is the situation
>> with merging in stuff from OpenJDK? It looks like they have a better
>> implementation here which could very easily be dropped in.
>> GNU Classpath is a GNU project, and copyright in all GNU projects
> must be assigned to the Free Software Foundation. You can combine
> code from the two projects, but we can't do that.

Sorry, I just re-read that and realized it's not clear who "you" and "we" 
refer to.
I meant: anyone can combine code from the two projects into another
project, but the FSF won't accept code for the Classpath project
without copyright assignment.
Andrew.