W3C home > Mailing lists > Public > www-jigsaw@w3.org > July to August 2001

Re: Updating Jigsaw to Java 2...

From: David Li <david@digitalsesame.com>
Date: Tue, 10 Jul 2001 12:44:16 +0800
Message-ID: <3B4A8820.6060203@digitalsesame.com>
To: Yves Lafon <ylafon@w3.org>
CC: www-jigsaw@w3.org
>>2. Servlet API. Jigsaw implements probably 2.0 API where
>>HttpSessionContext.java is still valid. This class is deprecated in 2.1
>>and will be removed in the future.
> The plan is to move to 2.2API at some point (and to do war files).

Would it make sense to adapt Tomcat as the Servlet container instead of 
doing another Servlet implementation?

>>3. Use of java.io.StringBufferInputStream and several deprecated String
>>API. These API has effect on incorrect handling of non-ASCII characters.
>>It may affect the international use.
>>  I am in Taiwan where primary languages is Traditional Chinese. Having
>>a system correctly implement I18N is important for us.
> Some of them shouldn't be replaced for performance purposes, unless things
> have changed with recent jdk :)

Do you have a benchmark program so this can be verified?

>>4. Deprecated Date functions.
>>I'd like to know what would be the minimum requirement of Java to run
>>Jigsaw in the future version. We will update Jigsaw accordingly.
> At some point there was a Date Thread to use less cpu to compute date,
> very useful for the logger (the main bottleneck)

It may be possible to use single DateFormat to handing the log output. 
This would cut down the unnecessary new object.

As for date computing speed, is there a bench mark program to verify the 

On the topic of performance, there is a good NBIO package (Non-blocking 
I/O) from Berlekey which increase the network performance. However, it's 
a native library. Would it make sense to use it with Jigsaw, at least as 
a optional components?

David Li
Received on Tuesday, 10 July 2001 00:38:32 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:25:37 UTC