Re: FastCGI with JDK1.1.1 -- patches

Sonya Rikhtverchik (rikhtver@OpenMarket.com)
Thu, 14 Aug 1997 10:13:07 -0400

Message-Id: <199708141413.KAA05976@u4-138.openmarket.com>
To: fastcgi-developers@OpenMarket.com
Subject: Re: FastCGI with JDK1.1.1 -- patches 
Date: Thu, 14 Aug 1997 10:13:07 -0400
From: Sonya Rikhtverchik <rikhtver@OpenMarket.com>

Date: Thu, 14 Aug 1997 09:23:04 +1000 (EST)
From: Martin Pool <mbp@pharos.com.au>
To: Steve Harris <harris@OpenMarket.com>
cc: Sonya Rikhtverchik <rikhtver@OpenMarket.com>,
        fastcgi-developers@OpenMarket.com
Subject: Re: FastCGI with JDK1.1.1 -- patches 
In-Reply-To: <199708121741.NAA02824@squaw-valley.openmarket.com>
Message-Id: <Pine.LNX.3.95.970814090519.3677N-100000@buffalo.pharos.com.au>
Penguin: RHL4.2 i586/166Mhz 96MB 5GB 17in Trinitron
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Tue, 12 Aug 1997, Steve Harris wrote:

> This is correct. That one simple change will do the trick, and
> everything else should be unaffected. There might be a way to have one
> codde version that works for 1.0 and 1.1. Read the Java version out of
> System.properties and conditionalize redirect vs. assignment based on
> the result. 

That won't quite work.  The incompatibility is trapped occurs at compile
time: the 1.0 version won't compile under 1.1 because you can't assign to
System.out, and the 1.1 version won't compile under 1.0 because there is
no such method as System.setOut().  Since Java doesn't have a preprocessor
I think everything in the source file has to be compatible with the
current libraries even if it's unreachable. 

Actually, a solution is to build two tiny classes, say Redirector1_0 and
Redirector1_1.  Each implements the appropriate code and is compiled with
the appropriate JDK, and you call one or the other at runtime depending on
which system you're using.  I think that will work.

Martin Pool <m.pool@pharos.com.au>
Pharos Business Solutions
(I'm not on the list -- please CC me on replies)


------- End of Forwarded Message