You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by Mark Womack <wo...@adobe.com> on 2005/08/15 18:28:31 UTC
[VOTE] Release log4j 1.2.12rc3
I move that we release log4j 1.2.12rc3 as the official release of v1.2.12.
We have addressed a number of annoying bugs, we have added the TRACE level.
The rc candidates have been made available to the user base via email
announcements. No new issues have been reported.
If we accept 1.2.12rc3 as the final, then I take the rc3 cvs tag, modify the
build number to 1.2.12, tag as v1.2.12 and build the final version that the
LS PMC can then vote to release.
I am +1.
-Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [VOTE] Release log4j 1.2.12rc3
Posted by Yoav Shapira <yo...@MIT.EDU>.
Yuppdy doo, +1.
Yoav
Quoting Mark Womack <wo...@adobe.com>:
> I move that we release log4j 1.2.12rc3 as the official release of v1.2.12.
> We have addressed a number of annoying bugs, we have added the TRACE level.
> The rc candidates have been made available to the user base via email
> announcements. No new issues have been reported.
>
> If we accept 1.2.12rc3 as the final, then I take the rc3 cvs tag, modify the
> build number to 1.2.12, tag as v1.2.12 and build the final version that the
> LS PMC can then vote to release.
>
> I am +1.
>
> -Mark
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: log4j 1.3 minimum JDK (was Re: [VOTE] Release log4j 1.2.12rc3)
Posted by Paul Smith <ps...@aconex.com>.
oh and here's my (obvious) +1 on JDK 1.3
On 16/08/2005, at 12:33 PM, Jacob Kjome wrote:
> At 08:31 PM 8/15/2005 -0500, you wrote:
> >
> >On Aug 15, 2005, at 8:23 PM, Paul Smith wrote:
> >
> >> This does beg the question that one of the original design goals of
> >> log4j 1.3 was that it's minimum requirement would be JDK 1.2. Are
> >> we still all in favour of that? I would like to think that JDK 1.3
> >> would be an acceptable minimum in this day and age?
> >
> >I think we need to break that off into another thread to not confuse
> >the issue. I could be persuaded. We'd also should specify whether
> >we target J2ME or some other subset.
> >
>
> +1 for JDK1.3 as a minimum for Log4j-1.3. BTW, does SLF4J run
> under JDK1.2? If so, Log4j wouldn't need to really think about
> dealing with J2ME. Imagine a jar as large as Log4j being used for
> J2ME! I think that's what Log4j Mini was for, but that hasn't been
> updated in ages. If J2ME developers were to code to the SLF4J
> interfaces, then they could use any implementation. For their code
> running in a big appserver, they could use Log4j. For their code
> running in J2ME, they could use either the SLF4j simple logger or
> some other implementation designed with J2ME in mind. I don't
> think J2ME should be much of a concern for Log4j other than making
> sure we implement the SLF4J interfaces (hopefully the api will
> stabilize at some point in the near future... aren't we glad we
> didn't vote Log4j-1.2.10 as a stable release? I am!).
>
>
> Jake
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: log4j 1.3 minimum JDK (was Re: [VOTE] Release log4j
1.2.12rc3)
Posted by Jacob Kjome <ho...@visi.com>.
At 08:31 PM 8/15/2005 -0500, you wrote:
>
>On Aug 15, 2005, at 8:23 PM, Paul Smith wrote:
>
>> This does beg the question that one of the original design goals of
>> log4j 1.3 was that it's minimum requirement would be JDK 1.2. Are
>> we still all in favour of that? I would like to think that JDK 1.3
>> would be an acceptable minimum in this day and age?
>
>I think we need to break that off into another thread to not confuse
>the issue. I could be persuaded. We'd also should specify whether
>we target J2ME or some other subset.
>
+1 for JDK1.3 as a minimum for Log4j-1.3. BTW, does SLF4J run under
JDK1.2? If so, Log4j wouldn't need to really think about dealing with
J2ME. Imagine a jar as large as Log4j being used for J2ME! I think that's
what Log4j Mini was for, but that hasn't been updated in ages. If J2ME
developers were to code to the SLF4J interfaces, then they could use any
implementation. For their code running in a big appserver, they could use
Log4j. For their code running in J2ME, they could use either the SLF4j
simple logger or some other implementation designed with J2ME in mind. I
don't think J2ME should be much of a concern for Log4j other than making
sure we implement the SLF4J interfaces (hopefully the api will stabilize at
some point in the near future... aren't we glad we didn't vote Log4j-1.2.10
as a stable release? I am!).
Jake
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: log4j 1.3 minimum JDK (was Re: [VOTE] Release log4j 1.2.12rc3)
Posted by Mark Womack <mw...@apache.org>.
-1 I think that moving to require 1.2 was enough of a jump. If we start to
restrict the JDK's we support to only the more recent, then the usefulness
of log4j will be diluted, imo.
-Mark
----- Original Message -----
From: "Curt Arnold" <ca...@apache.org>
To: "Log4J Developers List" <lo...@logging.apache.org>
Sent: Monday, August 15, 2005 6:31 PM
Subject: log4j 1.3 minimum JDK (was Re: [VOTE] Release log4j 1.2.12rc3)
>
> On Aug 15, 2005, at 8:23 PM, Paul Smith wrote:
>
>> This does beg the question that one of the original design goals of
>> log4j 1.3 was that it's minimum requirement would be JDK 1.2. Are we
>> still all in favour of that? I would like to think that JDK 1.3 would
>> be an acceptable minimum in this day and age?
>
> I think we need to break that off into another thread to not confuse the
> issue. I could be persuaded. We'd also should specify whether we target
> J2ME or some other subset.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: log4j 1.3 minimum JDK (was Re: [VOTE] Release log4j 1.2.12rc3)
Posted by Paul Smith <ps...@aconex.com>.
amen, they've probably got bigger issues than log4j.
On 16/08/2005, at 3:41 PM, Yoav Shapira wrote:
> Hola,
> +1 on JDK 1.3. It's more than five years old now. If someone hasn't
> updated their JVM in 5 years, they're not going to update log4j
> from 1.2...
>
> Yoav Shapira
> System Design and Management Fellow
> MIT Sloan School of Management
> Cambridge, MA USA
> yoavs@computer.org / www.yoavshapira.com
>
>
>> -----Original Message-----
>> From: Curt Arnold [mailto:carnold@apache.org]
>> Sent: Monday, August 15, 2005 9:32 PM
>> To: Log4J Developers List
>> Subject: log4j 1.3 minimum JDK (was Re: [VOTE] Release log4j
>> 1.2.12rc3)
>>
>>
>> On Aug 15, 2005, at 8:23 PM, Paul Smith wrote:
>>
>>
>>> This does beg the question that one of the original design goals of
>>> log4j 1.3 was that it's minimum requirement would be JDK 1.2. Are
>>> we still all in favour of that? I would like to think that JDK 1.3
>>> would be an acceptable minimum in this day and age?
>>>
>>
>> I think we need to break that off into another thread to not confuse
>> the issue. I could be persuaded. We'd also should specify whether
>> we target J2ME or some other subset.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>
>
>
> <yo...@computer.org.vcf>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
RE: log4j 1.3 minimum JDK (was Re: [VOTE] Release log4j 1.2.12rc3)
Posted by Jacob Kjome <ho...@visi.com>.
Quoting Ceki Gülcü <ce...@qos.ch>:
>
> As far as log4j 1.2.x is concerned, I believe that JDK 1.2
> compatibility was real. I can attest that for all log4j versions prior
> to 1.2.9, the log4j core was verified to compile under JDK 1.2. The
> same holds true for log4j 1.3beta.
>
Then we should verify that and figure out what changed to make it so annoyingly
difficult to build source later than 1.2.9. BTW, what JDK have the releases
been made under? I'd hasten to bet not JDK1.2 (without taking the time to
verify). It's been relatively recently that we set target and source
attributes in the build. Yes, the source may have been compatible with JDK1.2,
but have the official releases actually been compatible? Something to test, I
guess.
In any case, my main point is that if it is going to be so difficult to provide
releases compatible with JDK1.2, maybe Log4j-1.3 is the time to break to
JDK1.3. It's not just a developer's whim or convenience, but the ability to
assure users the JDK that is supported. Whether Log4j-1.2.xx compile under
JDK1.2 after extraordinary wrangling to get it to work is beside the point. If
our official releases don't work under JDK1.2 (how could they if they were
compiled in a later JDK and didn't provide source and target attributes?) and
it is too difficult to figure out how to get the build to work under JDK1.2 for
the average user trying to build it for JDK1.2, then it's very difficult for us
to claim JDK1.2 support. Maybe we have it, but that's kind of a guess rather
than a 100% assured fact. Stating JDK1.3 support for Log4j-1.3 makes our lives
easier and assures users because we can say with 100% certainty that it will
work. And then the sky's the limit for JDK support in 2.0, of course.
Jake
> At 08:26 PM 8/16/2005, you wrote:
> >Quoting Mark Womack <wo...@adobe.com>:
> >
> > > But is there some specific reason why we want to upgrade and be
> compatible
> > > with only >= JDK 1.3? Is there some core class we really need to use in
> > > order to make log4j better? If not, then I don't see a compelling
> > reason to
> > > self-limit ourselves to >= JDK 1.3. We are a logging framework, it just
> > > makes more sense to be as compatible as we can be, imo. It is one of the
> > > pluses for log4j vs jdk 1.4 logging.
> > >
> >
> >We still don't know if our current 1.2.xx releases are truly compatible with
> >JDK1.2 according to Curt's investigations, but we can all compile and test
> >under JDK1.3 quite easily. The idea is nice, but even our promise of
> backward
> >compatiblity for the 1.2 branch up to now is turning out to be a possible
> >farce. Suggested workarounds by Curt suggest is is not easy to provide this
> >support. Like others have said, if people haven't upgraded the JVM from
> >1.2.xx, they certainly aren't of the mind to upgrade Log4j or anything else.
> >JDK1.5 is out and 1.6 is in development. It's time to put JDK1.2 to rest
> >which
> >will allow us to make promises we can stand by!
> >
> >
> >Jake
>
> --
> Ceki Gülcü
>
> The complete log4j manual: http://www.qos.ch/log4j/
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
RE: log4j 1.3 minimum JDK (was Re: [VOTE] Release log4j 1.2.12rc3)
Posted by Mark Womack <wo...@adobe.com>.
Hey Ceki,
Do you remember the version of the jdk you used to build v1.2.9? When we
had talked about this before I seem to remember you saying JDK 1.3, but
maybe that was for the v1.3-alpha builds?
-Mark
> -----Original Message-----
> From: Ceki Gülcü [mailto:ceki@qos.ch]
> Sent: Tuesday, August 16, 2005 11:38 AM
> To: Log4J Developers List
> Subject: RE: log4j 1.3 minimum JDK (was Re: [VOTE] Release log4j
> 1.2.12rc3)
>
>
> As far as log4j 1.2.x is concerned, I believe that JDK 1.2
> compatibility was real. I can attest that for all log4j versions prior
> to 1.2.9, the log4j core was verified to compile under JDK 1.2. The
> same holds true for log4j 1.3beta.
>
> At 08:26 PM 8/16/2005, you wrote:
> >Quoting Mark Womack <wo...@adobe.com>:
> >
> > > But is there some specific reason why we want to upgrade and be
> compatible
> > > with only >= JDK 1.3? Is there some core class we really need to use
> in
> > > order to make log4j better? If not, then I don't see a compelling
> > reason to
> > > self-limit ourselves to >= JDK 1.3. We are a logging framework, it
> just
> > > makes more sense to be as compatible as we can be, imo. It is one of
> the
> > > pluses for log4j vs jdk 1.4 logging.
> > >
> >
> >We still don't know if our current 1.2.xx releases are truly compatible
> with
> >JDK1.2 according to Curt's investigations, but we can all compile and
> test
> >under JDK1.3 quite easily. The idea is nice, but even our promise of
> backward
> >compatiblity for the 1.2 branch up to now is turning out to be a possible
> >farce. Suggested workarounds by Curt suggest is is not easy to provide
> this
> >support. Like others have said, if people haven't upgraded the JVM from
> >1.2.xx, they certainly aren't of the mind to upgrade Log4j or anything
> else.
> >JDK1.5 is out and 1.6 is in development. It's time to put JDK1.2 to rest
> >which
> >will allow us to make promises we can stand by!
> >
> >
> >Jake
>
> --
> Ceki Gülcü
>
> The complete log4j manual: http://www.qos.ch/log4j/
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
RE: log4j 1.3 minimum JDK (was Re: [VOTE] Release log4j 1.2.12rc3)
Posted by Mark Womack <wo...@adobe.com>.
So, as a baseline I guess we should try v1.2.9 and see if we get these
warning messages with jdk 1.1.
-Mark
> -----Original Message-----
> From: Ceki Gülcü [mailto:ceki@qos.ch]
> Sent: Tuesday, August 16, 2005 11:38 AM
> To: Log4J Developers List
> Subject: RE: log4j 1.3 minimum JDK (was Re: [VOTE] Release log4j
> 1.2.12rc3)
>
>
> As far as log4j 1.2.x is concerned, I believe that JDK 1.2
> compatibility was real. I can attest that for all log4j versions prior
> to 1.2.9, the log4j core was verified to compile under JDK 1.2. The
> same holds true for log4j 1.3beta.
>
> At 08:26 PM 8/16/2005, you wrote:
> >Quoting Mark Womack <wo...@adobe.com>:
> >
> > > But is there some specific reason why we want to upgrade and be
> compatible
> > > with only >= JDK 1.3? Is there some core class we really need to use
> in
> > > order to make log4j better? If not, then I don't see a compelling
> > reason to
> > > self-limit ourselves to >= JDK 1.3. We are a logging framework, it
> just
> > > makes more sense to be as compatible as we can be, imo. It is one of
> the
> > > pluses for log4j vs jdk 1.4 logging.
> > >
> >
> >We still don't know if our current 1.2.xx releases are truly compatible
> with
> >JDK1.2 according to Curt's investigations, but we can all compile and
> test
> >under JDK1.3 quite easily. The idea is nice, but even our promise of
> backward
> >compatiblity for the 1.2 branch up to now is turning out to be a possible
> >farce. Suggested workarounds by Curt suggest is is not easy to provide
> this
> >support. Like others have said, if people haven't upgraded the JVM from
> >1.2.xx, they certainly aren't of the mind to upgrade Log4j or anything
> else.
> >JDK1.5 is out and 1.6 is in development. It's time to put JDK1.2 to rest
> >which
> >will allow us to make promises we can stand by!
> >
> >
> >Jake
>
> --
> Ceki Gülcü
>
> The complete log4j manual: http://www.qos.ch/log4j/
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
RE: log4j 1.3 minimum JDK (was Re: [VOTE] Release log4j
1.2.12rc3)
Posted by Ceki Gülcü <ce...@qos.ch>.
As far as log4j 1.2.x is concerned, I believe that JDK 1.2
compatibility was real. I can attest that for all log4j versions prior
to 1.2.9, the log4j core was verified to compile under JDK 1.2. The
same holds true for log4j 1.3beta.
At 08:26 PM 8/16/2005, you wrote:
>Quoting Mark Womack <wo...@adobe.com>:
>
> > But is there some specific reason why we want to upgrade and be compatible
> > with only >= JDK 1.3? Is there some core class we really need to use in
> > order to make log4j better? If not, then I don't see a compelling
> reason to
> > self-limit ourselves to >= JDK 1.3. We are a logging framework, it just
> > makes more sense to be as compatible as we can be, imo. It is one of the
> > pluses for log4j vs jdk 1.4 logging.
> >
>
>We still don't know if our current 1.2.xx releases are truly compatible with
>JDK1.2 according to Curt's investigations, but we can all compile and test
>under JDK1.3 quite easily. The idea is nice, but even our promise of backward
>compatiblity for the 1.2 branch up to now is turning out to be a possible
>farce. Suggested workarounds by Curt suggest is is not easy to provide this
>support. Like others have said, if people haven't upgraded the JVM from
>1.2.xx, they certainly aren't of the mind to upgrade Log4j or anything else.
>JDK1.5 is out and 1.6 is in development. It's time to put JDK1.2 to rest
>which
>will allow us to make promises we can stand by!
>
>
>Jake
--
Ceki Gülcü
The complete log4j manual: http://www.qos.ch/log4j/
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: log4j 1.3 minimum JDK (was Re: [VOTE] Release log4j 1.2.12rc3)
Posted by Curt Arnold <ca...@apache.org>.
On Aug 17, 2005, at 3:45 AM, Endre Stølsvik wrote:
> So, set source=1.2, target=1.2 and bootclasspath=/usr/java/jdk1.2/
> rt.jar,
> and the code will compile according to 1.2 rules, compile to 1.2
> classfiles, and be compiled against 1.2 runtime libraries. It will
> thus
> run on 1.2 JREs!
That is almost what we are doing at the moment (except target=1.1 and
on a Windows platform). The problem is that it doesn't work in
practice with the javac's in later Sun JDK's running on JRE 1.1 or
1.2. The bytecode produced is loadable but something distinctive
trips up the JIT's in those JRE's. Ant also tries to do the right
thing but its distributed jars will load on earlier JREs but will
misbehave when running.
We've had good intentions to run on JRE 1.1 or 1.2, but haven't been
testing on those platforms and have been catch unaware by a compiler
bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
RE: log4j 1.3 minimum JDK (was Re: [VOTE] Release log4j 1.2.12rc3)
Posted by Mark Womack <wo...@adobe.com>.
Endre,
Thanks for the info. Curt has already made some changes in this area, so
I'll see what I can build upon tonight.
-Mark
> -----Original Message-----
> From: Endre Stølsvik [mailto:Endre@Stolsvik.com]
> Sent: Wednesday, August 17, 2005 1:45 AM
> To: Log4J Developers List; womack@adobe.com
> Subject: RE: log4j 1.3 minimum JDK (was Re: [VOTE] Release log4j
> 1.2.12rc3)
>
> On Tue, 16 Aug 2005, Mark Womack wrote:
>
> | We can make it so that log4j is compatible with 1.2 and happy when it
> runs.
> | Just compile using jdk 1.2 instead of jdk 1.3 or 1.4. I think the
> messages
> | we are seeing are related to compiling the release lib with 1.4 instead
> of
> | 1.2 (or 1.1 in the case of 1.2.12). And they are non-fatal warnings,
> not
> | errors. I have to imagine that compiling with jdk 1.2 (or 1.1) will
> | generate compatible byte code for that jdk. And it appears that Ant
> will
> | support compiling with different jdk's while itself runs in jdk 1.4.
>
> I do it every day. That is, running ant and the compile on jdk 1.5, and
> then running the code on 1.3 (not 1.2, because we haven't targetted that
> for the product in question). If you don't set the "target" flag (which
> was necessary from 1.4 or something?), the 1.3 jvm says "no way, these are
> too new class files". But with the target-stuff it works. The "classic"
> flag is out, isn't it?!
>
> You also have to set "bootclasspath" to a jdk 1.2 rt.jar to use those
> java.-classes, and thus get errors if you use 1.3+ features of the jdk.
>
> So, set source=1.2, target=1.2 and bootclasspath=/usr/java/jdk1.2/rt.jar,
> and the code will compile according to 1.2 rules, compile to 1.2
> classfiles, and be compiled against 1.2 runtime libraries. It will thus
> run on 1.2 JREs!
>
> | I don't know if there is any performance penalty for running jdk 1.2
> | byte code in 1.3/1.4.
>
> Don't believe so, and the JIT would probably eat it up anyway. The JVM
> hasn't got any new instruction set lately (ever), so it's not like "MMX"
> og "SSE" or similar new instructions that is used in 1.5, and cannot be
> used in 1.2.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
RE: log4j 1.3 minimum JDK (was Re: [VOTE] Release log4j 1.2.12rc3)
Posted by Endre Stølsvik <En...@Stolsvik.com>.
On Tue, 16 Aug 2005, Mark Womack wrote:
| We can make it so that log4j is compatible with 1.2 and happy when it runs.
| Just compile using jdk 1.2 instead of jdk 1.3 or 1.4. I think the messages
| we are seeing are related to compiling the release lib with 1.4 instead of
| 1.2 (or 1.1 in the case of 1.2.12). And they are non-fatal warnings, not
| errors. I have to imagine that compiling with jdk 1.2 (or 1.1) will
| generate compatible byte code for that jdk. And it appears that Ant will
| support compiling with different jdk's while itself runs in jdk 1.4.
I do it every day. That is, running ant and the compile on jdk 1.5, and
then running the code on 1.3 (not 1.2, because we haven't targetted that
for the product in question). If you don't set the "target" flag (which
was necessary from 1.4 or something?), the 1.3 jvm says "no way, these are
too new class files". But with the target-stuff it works. The "classic"
flag is out, isn't it?!
You also have to set "bootclasspath" to a jdk 1.2 rt.jar to use those
java.-classes, and thus get errors if you use 1.3+ features of the jdk.
So, set source=1.2, target=1.2 and bootclasspath=/usr/java/jdk1.2/rt.jar,
and the code will compile according to 1.2 rules, compile to 1.2
classfiles, and be compiled against 1.2 runtime libraries. It will thus
run on 1.2 JREs!
| I don't know if there is any performance penalty for running jdk 1.2
| byte code in 1.3/1.4.
Don't believe so, and the JIT would probably eat it up anyway. The JVM
hasn't got any new instruction set lately (ever), so it's not like "MMX"
og "SSE" or similar new instructions that is used in 1.5, and cannot be
used in 1.2.
|
| Assuming the above, the question still remains. Is there a compelling
| reason to dump jdk 1.2 compatibility besides easing the building and testing
| requirements?
No. Don't do it.
Regards,
Endre
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: log4j 1.3 minimum JDK (was Re: [VOTE] Release log4j 1.2.12rc3)
Posted by Paul Smith <ps...@aconex.com>.
>
> We may have a low threshold, but we are not the primary users of the
> framework. And abandoning jdk 1.2 for our convenience is not a
> good reason.
> I find it incredibly annoying when I go to use a tool or a
> framework and
> find that doesn't support the version I am running, or is not
> compatible
> with the environment I have, so I have to upgrade, etc. But I am
> still open
> to hear a compelling reason to dump jdk 1.2 support.
We should talk to our users rather than make decisions for them.
Perhaps a post on the user mailing list to gather feedback?
My (harsh) rationale is that for those people who want (really "are
forced") to use JDK 1.2, then they have log4j1.2.9, which has been
around SOOO long and is known to be perfectly adequate for everyone.
If we can achieve JDK 1.2 compatibility cheap and easy, then that's
good, but I'm not sure the time spent getting it to work is really
worthy the effort?
Paul
RE: [VOTE] Release log4j 1.2.12rc3 (was log4j 1.3 minimum JDK)
Posted by Mark Womack <wo...@adobe.com>.
> As a potential consumer of the "official" build, there are a lot of
> things of the build "machine" that are invisible: the platform, the
> compiler, the version of Ant , the JDK, the specific versions of JAF,
> JMS, JAXP, JNDI, Javamail, Javadoc, etc. Whether the compiler was
> selected by the release manager specifying it on a command line or by
> the release manager editing a build.properties that I never get to
> see is just one of them.
Yep. I think we should consider putting more of that info into the manifest
in some form. Just for reference, the manifest from log4j 1.2.9 has:
Manifest-Version: 1.0
Created-By: Apache Ant 1.5.1
Name: org/apache/log4j/
Implementation-Title: log4j
Implementation-Version: 1.2.9
Implementation-Vendor: "Apache Software Foundation"
Doesn't say what version of the jdk was used for compiling. Ceki, what
version of the jdk did you use to build v1.2.9?
-Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [VOTE] Release log4j 1.2.12rc3 (was log4j 1.3 minimum JDK)
Posted by Curt Arnold <ca...@apache.org>.
On Aug 16, 2005, at 6:55 PM, Mark Womack wrote:
> I will see if I can play with this tonight. It would be nice if these
> settings could be controlled from our build.properties file instead of
> setting property values in the command line.
Placing it in build.properties should the same effect as specifying
on the command line. We provide build.properties.sample, but the
current one in the v1_2branch uses pretty archaic versions of JAF,
etc, so I doubt that it is consistent with the build environment that
you are actually using to produce the "official" build.
As a potential consumer of the "official" build, there are a lot of
things of the build "machine" that are invisible: the platform, the
compiler, the version of Ant , the JDK, the specific versions of JAF,
JMS, JAXP, JNDI, Javamail, Javadoc, etc. Whether the compiler was
selected by the release manager specifying it on a command line or by
the release manager editing a build.properties that I never get to
see is just one of them.
On Aug 16, 2005, at 7:00 PM, Jacob Kjome wrote:
> Quoting Ceki Gülcü <ce...@qos.ch>:
>
>
>>
>> As far as log4j 1.2.x is concerned, I believe that JDK 1.2
>> compatibility was real. I can attest that for all log4j versions
>> prior
>> to 1.2.9, the log4j core was verified to compile under JDK 1.2. The
>> same holds true for log4j 1.3beta.
>>
I think "log4j core" is a key part of that statement. For example,
the perfectly legal code in
o.a.l.chainsaw.receivers.LoggingReceiver.java that the JDK 1.2
compiler fails to compile had not been changed since 2002/05/29 and
appears to have had the issue since its introduction in 2002/03/23.
So I think it is highly unlikely that a distribution of log4j has
been prepared using JDK 1.1 or JDK 1.2 since at least mid-2002.
On Aug 16, 2005, at 7:00 PM, Jacob Kjome wrote:
> Quoting Ceki Gülcü <ce...@qos.ch>:
>
> Then we should verify that and figure out what changed to make it
> so annoyingly
> difficult to build source later than 1.2.9.
I have not attempted to confirm whether the issue occurs in earlier
log4j releases. Mark's build environment was most likely created
independently from Ceki's and likely differ in significant ways (OS,
JDK version, versions of dependencies, etc).
> BTW, what JDK have the releases
> been made under? I'd hasten to bet not JDK1.2 (without taking the
> time to
> verify).
See previous statement. Though it would be nice to get a description
of the build environments for earlier releases from Ceki.
> It's been relatively recently that we set target and source
> attributes in the build.
That became necessary with the introduction of JDK 1.5 which changed
the default value for target (I think from 1.1 to 1.2).
> Yes, the source may have been compatible with JDK1.2,
> but have the official releases actually been compatible? Something
> to test, I
> guess.
There is astonishing little documentation of the issue. Doing a
search shows it popping up in other projects, but there was nothing
in the Sun Java bug database similar other than a 1999-era bug. My
supposition is that sometime between JDK 1.2 and 1.4, the Sun JDK
compilers started emitting what is likely valid 1.1 bytecode per the
spec but which fails to be properly handled by the JIT's in the
earlier JVMs. My guess, but unsubstantiated, is that JDK 1.3's javac
is probably okay.
The same issue affects Ant's distributions at least since Ant 1.5.4
and to a much greater degree. No hints in the Ant mailing lists came
up when I did a search, but I didn't try to drill into the Ant
mailing list or post a message there.
Ideally we'd get the build environment nailed and the frozen into a
VM image or a bootable CD, so the process would be reproducible and
controlled. However, due to the mass of components that would have
some limitation on license transfer or distribution, I don't think we
could ever get to the point of being able to pass the build VM around.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
RE: [VOTE] Release log4j 1.2.12rc3 (was log4j 1.3 minimum JDK)
Posted by Mark Womack <wo...@adobe.com>.
Something else came up that ate up my evening, so I did not get a chance to
look at this like I planned. I will work on this tonight; I want to resolve
this and move forward with the release in some fashion. I'll see what I
come up with and we can decide and move forward.
-Mark
> -----Original Message-----
> From: Mark Womack [mailto:womack@adobe.com]
> Sent: Tuesday, August 16, 2005 4:55 PM
> To: 'Log4J Developers List'
> Subject: RE: [VOTE] Release log4j 1.2.12rc3 (was log4j 1.3 minimum JDK)
>
> I will see if I can play with this tonight. It would be nice if these
> settings could be controlled from our build.properties file instead of
> setting property values in the command line.
>
> -Mark
>
> > -----Original Message-----
> > From: Curt Arnold [mailto:carnold@apache.org]
> > Sent: Tuesday, August 16, 2005 4:07 PM
> > To: Log4J Developers List
> > Subject: Re: [VOTE] Release log4j 1.2.12rc3 (was log4j 1.3 minimum JDK)
> >
> >
> > On Aug 16, 2005, at 4:33 PM, Mark Womack wrote:
> > >
> > > The javac tag supports an "executable" attribute that lets you
> > > specify a
> > > path to the javac to use. Between that and the other attributes, I
> > > think we
> > > will have enough control to do what we want?
> >
> > > I agree that switching to the jdk 1.2 compiler for v1.2.12 at this
> > > point
> > > will be a disruptive risk, but something we may want to consider
> > > and deal
> > > with. But for log4j v1.3 we should certainly look at it.
> >
> > Should be no need to modify the build file, the compiler can be
> > controlled by the -Dbuild.compiler switch on the Ant command and
> > appropriate setting of the PATH and/or JAVA_HOME. It would be
> > undesirable to hard-code a particular compiler choice in the build file.
> >
> > Jikes seemed to be the simplest way to tweak your configuration, but
> > using the JDK 1.2 or 1.1 compiler or building the whole thing on JDK
> > 1.1 or 1.2 (requiring a rebuilt Ant and assembly of things like JAXP
> > that are built into later JVM's) should also work. I was just
> > looking for the minimum possible change to your configuration to
> > avoid losing something like the JMSAppender due to a configuration
> > change.
> >
> > When you do decide what one of the multiple options you use to , it
> > would be good if you could tell us how you built it.
> >
> > Probably worthwhile looking at the recently filed: http://
> > issues.apache.org/bugzilla/show_bug.cgi?id=36213. The issues raised
> > appear also to affect 1.2.12rc3.
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> > For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
RE: [VOTE] Release log4j 1.2.12rc3 (was log4j 1.3 minimum JDK)
Posted by Mark Womack <wo...@adobe.com>.
I will see if I can play with this tonight. It would be nice if these
settings could be controlled from our build.properties file instead of
setting property values in the command line.
-Mark
> -----Original Message-----
> From: Curt Arnold [mailto:carnold@apache.org]
> Sent: Tuesday, August 16, 2005 4:07 PM
> To: Log4J Developers List
> Subject: Re: [VOTE] Release log4j 1.2.12rc3 (was log4j 1.3 minimum JDK)
>
>
> On Aug 16, 2005, at 4:33 PM, Mark Womack wrote:
> >
> > The javac tag supports an "executable" attribute that lets you
> > specify a
> > path to the javac to use. Between that and the other attributes, I
> > think we
> > will have enough control to do what we want?
>
> > I agree that switching to the jdk 1.2 compiler for v1.2.12 at this
> > point
> > will be a disruptive risk, but something we may want to consider
> > and deal
> > with. But for log4j v1.3 we should certainly look at it.
>
> Should be no need to modify the build file, the compiler can be
> controlled by the -Dbuild.compiler switch on the Ant command and
> appropriate setting of the PATH and/or JAVA_HOME. It would be
> undesirable to hard-code a particular compiler choice in the build file.
>
> Jikes seemed to be the simplest way to tweak your configuration, but
> using the JDK 1.2 or 1.1 compiler or building the whole thing on JDK
> 1.1 or 1.2 (requiring a rebuilt Ant and assembly of things like JAXP
> that are built into later JVM's) should also work. I was just
> looking for the minimum possible change to your configuration to
> avoid losing something like the JMSAppender due to a configuration
> change.
>
> When you do decide what one of the multiple options you use to , it
> would be good if you could tell us how you built it.
>
> Probably worthwhile looking at the recently filed: http://
> issues.apache.org/bugzilla/show_bug.cgi?id=36213. The issues raised
> appear also to affect 1.2.12rc3.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [VOTE] Release log4j 1.2.12rc3 (was log4j 1.3 minimum JDK)
Posted by Curt Arnold <ca...@apache.org>.
On Aug 16, 2005, at 4:33 PM, Mark Womack wrote:
>
> The javac tag supports an "executable" attribute that lets you
> specify a
> path to the javac to use. Between that and the other attributes, I
> think we
> will have enough control to do what we want?
> I agree that switching to the jdk 1.2 compiler for v1.2.12 at this
> point
> will be a disruptive risk, but something we may want to consider
> and deal
> with. But for log4j v1.3 we should certainly look at it.
Should be no need to modify the build file, the compiler can be
controlled by the -Dbuild.compiler switch on the Ant command and
appropriate setting of the PATH and/or JAVA_HOME. It would be
undesirable to hard-code a particular compiler choice in the build file.
Jikes seemed to be the simplest way to tweak your configuration, but
using the JDK 1.2 or 1.1 compiler or building the whole thing on JDK
1.1 or 1.2 (requiring a rebuilt Ant and assembly of things like JAXP
that are built into later JVM's) should also work. I was just
looking for the minimum possible change to your configuration to
avoid losing something like the JMSAppender due to a configuration
change.
When you do decide what one of the multiple options you use to , it
would be good if you could tell us how you built it.
Probably worthwhile looking at the recently filed: http://
issues.apache.org/bugzilla/show_bug.cgi?id=36213. The issues raised
appear also to affect 1.2.12rc3.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
RE: log4j 1.3 minimum JDK (was Re: [VOTE] Release log4j 1.2.12rc3)
Posted by Mark Womack <wo...@adobe.com>.
> > We can make it so that log4j is compatible with 1.2 and happy when
> > it runs.
> > Just compile using jdk 1.2 instead of jdk 1.3 or 1.4.
>
> That should be possible, but I suggested using Jikes while producing
> the distribution since it seemed to be an adequate and less
> complicated solution.
>
> I made attempts to compile under JDK 1.2, but that required
> rebuilding Ant 1.6.5 or reverting to an Ant 1.5 that doesn't suffer
> (and more significantly) from the same problem, applying the change
> to LoggingReceiver to work-around its compiler bug, and assembling
> the necessary jar and tweaking the classpath since quite a few of
> which have been added to JDK in 1.3 and later and are assumed to be
> in the build environment.
The javac tag supports an "executable" attribute that lets you specify a
path to the javac to use. Between that and the other attributes, I think we
will have enough control to do what we want?
I agree that switching to the jdk 1.2 compiler for v1.2.12 at this point
will be a disruptive risk, but something we may want to consider and deal
with. But for log4j v1.3 we should certainly look at it.
> > I think the messages
> > we are seeing are related to compiling the release lib with 1.4
> > instead of
> > 1.2 (or 1.1 in the case of 1.2.12). And they are non-fatal
> > warnings, not
> > errors.
>
> I have not seen them result in log4j not properly functioning. But
> Ant builds suffering from the same issue are failing to function, so
> I think the issue should be addressed.
Agreed, we need to understand it better.
> >
> > Assuming the above, the question still remains. Is there a compelling
> > reason to dump jdk 1.2 compatibility besides easing the building
> > and testing
> > requirements?
>
> I haven't seen a compelling reason. However, I think the consensus
> is that the threshold for abandoning JDK 1.2 compatibility on the 1.3
> branch is not high.
We may have a low threshold, but we are not the primary users of the
framework. And abandoning jdk 1.2 for our convenience is not a good reason.
I find it incredibly annoying when I go to use a tool or a framework and
find that doesn't support the version I am running, or is not compatible
with the environment I have, so I have to upgrade, etc. But I am still open
to hear a compelling reason to dump jdk 1.2 support.
> Hopefully, not to confound the issue even more, but my expectation is
> that when we start the log4j 2.0 branch we'd set the target as JDK
> 1.5, though possibly provide variants that would run on earlier
> JDK's. For example, I'd expect log4j 2.0 to use StringBuilder (non
> synchronized equivalent of StringBuffer) in the source code. We
> could consider providing alternative builds that would tweak the
> source code to use StringBuffer.
All bets are off with log4j 2.0. We can make appropriate decisions when we
get to that gate.
-Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: log4j 1.3 minimum JDK (was Re: [VOTE] Release log4j 1.2.12rc3)
Posted by Curt Arnold <ca...@apache.org>.
On Aug 16, 2005, at 1:58 PM, Mark Womack wrote:
> We can make it so that log4j is compatible with 1.2 and happy when
> it runs.
> Just compile using jdk 1.2 instead of jdk 1.3 or 1.4.
That should be possible, but I suggested using Jikes while producing
the distribution since it seemed to be an adequate and less
complicated solution.
I made attempts to compile under JDK 1.2, but that required
rebuilding Ant 1.6.5 or reverting to an Ant 1.5 that doesn't suffer
(and more significantly) from the same problem, applying the change
to LoggingReceiver to work-around its compiler bug, and assembling
the necessary jar and tweaking the classpath since quite a few of
which have been added to JDK in 1.3 and later and are assumed to be
in the build environment.
> I think the messages
> we are seeing are related to compiling the release lib with 1.4
> instead of
> 1.2 (or 1.1 in the case of 1.2.12). And they are non-fatal
> warnings, not
> errors.
I have not seen them result in log4j not properly functioning. But
Ant builds suffering from the same issue are failing to function, so
I think the issue should be addressed.
> I have to imagine that compiling with jdk 1.2 (or 1.1) will
> generate compatible byte code for that jdk. And it appears that
> Ant will
> support compiling with different jdk's while itself runs in jdk
> 1.4. I
> don't know if there is any performance penalty for running jdk 1.2
> byte code
> in 1.3/1.4.
If you feel comfortable configuring Ant to use a classic compiler
while running on a later VM, that would be an option. I'd assume
that you'd be specifying -Dbuild.compiler=classic and need to make
sure that JDK javac was on the path and that tools.jar was not on the
classpath (likely by running under a JRE and not a JDK). However,
switching to an earlier javac seems equivalently disruptive as
switching to jikes.
My understanding is that any performance penalty would be at class
load time and not run-time. If there was a performance penalty, then
the user is free to recompile the jar with whatever compiler they
prefer.
>
> Assuming the above, the question still remains. Is there a compelling
> reason to dump jdk 1.2 compatibility besides easing the building
> and testing
> requirements?
I haven't seen a compelling reason. However, I think the consensus
is that the threshold for abandoning JDK 1.2 compatibility on the 1.3
branch is not high.
Hopefully, not to confound the issue even more, but my expectation is
that when we start the log4j 2.0 branch we'd set the target as JDK
1.5, though possibly provide variants that would run on earlier
JDK's. For example, I'd expect log4j 2.0 to use StringBuilder (non
synchronized equivalent of StringBuffer) in the source code. We
could consider providing alternative builds that would tweak the
source code to use StringBuffer.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
RE: log4j 1.3 minimum JDK (was Re: [VOTE] Release log4j 1.2.12rc3)
Posted by Mark Womack <wo...@adobe.com>.
We can make it so that log4j is compatible with 1.2 and happy when it runs.
Just compile using jdk 1.2 instead of jdk 1.3 or 1.4. I think the messages
we are seeing are related to compiling the release lib with 1.4 instead of
1.2 (or 1.1 in the case of 1.2.12). And they are non-fatal warnings, not
errors. I have to imagine that compiling with jdk 1.2 (or 1.1) will
generate compatible byte code for that jdk. And it appears that Ant will
support compiling with different jdk's while itself runs in jdk 1.4. I
don't know if there is any performance penalty for running jdk 1.2 byte code
in 1.3/1.4.
Assuming the above, the question still remains. Is there a compelling
reason to dump jdk 1.2 compatibility besides easing the building and testing
requirements?
-Mark
> -----Original Message-----
> From: Jacob Kjome [mailto:hoju@visi.com]
> Sent: Tuesday, August 16, 2005 11:26 AM
> To: Log4J Developers List; womack@adobe.com
> Subject: RE: log4j 1.3 minimum JDK (was Re: [VOTE] Release log4j
> 1.2.12rc3)
>
> Quoting Mark Womack <wo...@adobe.com>:
>
> > But is there some specific reason why we want to upgrade and be
> compatible
> > with only >= JDK 1.3? Is there some core class we really need to use in
> > order to make log4j better? If not, then I don't see a compelling
> reason to
> > self-limit ourselves to >= JDK 1.3. We are a logging framework, it just
> > makes more sense to be as compatible as we can be, imo. It is one of
> the
> > pluses for log4j vs jdk 1.4 logging.
> >
>
> We still don't know if our current 1.2.xx releases are truly compatible
> with
> JDK1.2 according to Curt's investigations, but we can all compile and test
> under JDK1.3 quite easily. The idea is nice, but even our promise of
> backward
> compatiblity for the 1.2 branch up to now is turning out to be a possible
> farce. Suggested workarounds by Curt suggest is is not easy to provide
> this
> support. Like others have said, if people haven't upgraded the JVM from
> 1.2.xx, they certainly aren't of the mind to upgrade Log4j or anything
> else.
> JDK1.5 is out and 1.6 is in development. It's time to put JDK1.2 to rest
> which
> will allow us to make promises we can stand by!
>
>
> Jake
>
>
> > -Mark
> >
> > > -----Original Message-----
> > > From: Yoav Shapira [mailto:yoavsh@MIT.EDU]
> > > Sent: Monday, August 15, 2005 10:41 PM
> > > To: 'Log4J Developers List'
> > > Subject: RE: log4j 1.3 minimum JDK (was Re: [VOTE] Release log4j
> > > 1.2.12rc3)
> > >
> > > Hola,
> > > +1 on JDK 1.3. It's more than five years old now. If someone hasn't
> > > updated their JVM in 5 years, they're not going to update log4j from
> > > 1.2...
> > >
> > > Yoav Shapira
> > > System Design and Management Fellow
> > > MIT Sloan School of Management
> > > Cambridge, MA USA
> > > yoavs@computer.org / www.yoavshapira.com
> > >
> > > > -----Original Message-----
> > > > From: Curt Arnold [mailto:carnold@apache.org]
> > > > Sent: Monday, August 15, 2005 9:32 PM
> > > > To: Log4J Developers List
> > > > Subject: log4j 1.3 minimum JDK (was Re: [VOTE] Release log4j
> 1.2.12rc3)
> > > >
> > > >
> > > > On Aug 15, 2005, at 8:23 PM, Paul Smith wrote:
> > > >
> > > > > This does beg the question that one of the original design goals
> of
> > > > > log4j 1.3 was that it's minimum requirement would be JDK 1.2. Are
> > > > > we still all in favour of that? I would like to think that JDK
> 1.3
> > > > > would be an acceptable minimum in this day and age?
> > > >
> > > > I think we need to break that off into another thread to not confuse
> > > > the issue. I could be persuaded. We'd also should specify whether
> > > > we target J2ME or some other subset.
> > > >
> > > > --------------------------------------------------------------------
> -
> > > > To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> > > > For additional commands, e-mail: log4j-dev-help@logging.apache.org
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> > For additional commands, e-mail: log4j-dev-help@logging.apache.org
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
RE: log4j 1.3 minimum JDK (was Re: [VOTE] Release log4j 1.2.12rc3)
Posted by Jacob Kjome <ho...@visi.com>.
Quoting Mark Womack <wo...@adobe.com>:
> But is there some specific reason why we want to upgrade and be compatible
> with only >= JDK 1.3? Is there some core class we really need to use in
> order to make log4j better? If not, then I don't see a compelling reason to
> self-limit ourselves to >= JDK 1.3. We are a logging framework, it just
> makes more sense to be as compatible as we can be, imo. It is one of the
> pluses for log4j vs jdk 1.4 logging.
>
We still don't know if our current 1.2.xx releases are truly compatible with
JDK1.2 according to Curt's investigations, but we can all compile and test
under JDK1.3 quite easily. The idea is nice, but even our promise of backward
compatiblity for the 1.2 branch up to now is turning out to be a possible
farce. Suggested workarounds by Curt suggest is is not easy to provide this
support. Like others have said, if people haven't upgraded the JVM from
1.2.xx, they certainly aren't of the mind to upgrade Log4j or anything else.
JDK1.5 is out and 1.6 is in development. It's time to put JDK1.2 to rest which
will allow us to make promises we can stand by!
Jake
> -Mark
>
> > -----Original Message-----
> > From: Yoav Shapira [mailto:yoavsh@MIT.EDU]
> > Sent: Monday, August 15, 2005 10:41 PM
> > To: 'Log4J Developers List'
> > Subject: RE: log4j 1.3 minimum JDK (was Re: [VOTE] Release log4j
> > 1.2.12rc3)
> >
> > Hola,
> > +1 on JDK 1.3. It's more than five years old now. If someone hasn't
> > updated their JVM in 5 years, they're not going to update log4j from
> > 1.2...
> >
> > Yoav Shapira
> > System Design and Management Fellow
> > MIT Sloan School of Management
> > Cambridge, MA USA
> > yoavs@computer.org / www.yoavshapira.com
> >
> > > -----Original Message-----
> > > From: Curt Arnold [mailto:carnold@apache.org]
> > > Sent: Monday, August 15, 2005 9:32 PM
> > > To: Log4J Developers List
> > > Subject: log4j 1.3 minimum JDK (was Re: [VOTE] Release log4j 1.2.12rc3)
> > >
> > >
> > > On Aug 15, 2005, at 8:23 PM, Paul Smith wrote:
> > >
> > > > This does beg the question that one of the original design goals of
> > > > log4j 1.3 was that it's minimum requirement would be JDK 1.2. Are
> > > > we still all in favour of that? I would like to think that JDK 1.3
> > > > would be an acceptable minimum in this day and age?
> > >
> > > I think we need to break that off into another thread to not confuse
> > > the issue. I could be persuaded. We'd also should specify whether
> > > we target J2ME or some other subset.
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> > > For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
RE: log4j 1.3 minimum JDK (was Re: [VOTE] Release log4j
1.2.12rc3)
Posted by Jacob Kjome <ho...@visi.com>.
At 11:10 AM 8/17/2005 -0400, you wrote:
>Hi,
>
>
>> I wholeheartedly agree. Dropping 1.2 support "just because it's old" is
>> very silly - there must be some -reason- behind that choice.
>>
Did you bother reading both of my responses? Apparently not.
>> Regards,
>> Endre
>
>True, but the reason doesn't have to be technical. If, for a given log4j
>release, the marginal cost (in terms of developer time spent on the issue,
>for example) of maintaining JDK 1.2 support exceeds the marginal benefit (in
>terms of how many users of that release use JDK 1.2 AND would update to the
>given log4j release), that's a reason to dump support. That's fairly
>elementary project management.
>
Amen, Yoav, and that's coming from an Atheist! :-)
Of course, as I've stated previously, there's the other issue of whether
existing releases (not just tagged source, but actual official releases)
work with the stated JDK's. Does anyone know this for sure? Oh, yeah, and
I said "for sure", not theoretically. And since we haven't had "target" or
"source" attributes in the build until very recently, the releases better
darned well have compiled under JDK1.1 (that's the promised level of
support for Log4j-1.2.xx, right?). Did that actually
happen? Doubtful. And given concerns brought to light by Curt, it sounds
like in order to have true clean support for JDK1.1 and 1.2, changes to the
build are needed to be able to build under those JDK's or at least some
clear instructions on how to build with Jikes, also taking into account all
the extra dependencies on libraries not included in JDK1.1 or 1.2 that
exist natively in 1.3+.
Talk of a theoretical possibility of being able to compile the source and
have it run under JDK1.1 and/or 1.2 is pointless if we can't either provide
a release that will actually work under those JDK's (identically to under
later JDK's, meaning no superfluous warnings and such.... and have Log4j
developers verifying that they work) or at least make it easy for someone
to build under (or, at least target) those JDK's. Given the current
discussion, neither of these seem to be true. Either someone takes a
decent amount of time out of their schedule to verify all this or we need
to drop support in Log4j-1.3. We should still strive to support what was
promised for the 1.2 branch. But being that the time and effort involved
in this may be significant and will have to be re-evaluated with every
single change to Log4j-1.3, I see this as a no-brainer to make JDK1.3 the
minimum for Log4j-1.3.
Now, if I haven't gotten the point across that the reason for dropping
JDK1.2 support for Log4j-1.3 is way more involved than "just because it's
old", then I guess I'm talking to a brick wall. Endre (and others with the
same point of view), you may disagree, and I encourage you to explain why
you disagree, but I'd appreciate if you wouldn't simply gloss over what's
been said and then argue that the bottom line for JDK1.3-as-a-minimum
advocates is to get rid of the JDK1.2 requirement "just because it's
old". You were either sleeping or just trying to annoy me.... or both.
>Of course, if there's a developer willing to spend all the time and effort
>needed to support it, so be it. Until we actually run into a technical
>reason.
>
We'll have to see how technical it gets. If it isn't made dead-pan simple
to do under a normal build environment (Any reasonable version of Ant,
meaning probably 1.5 and above, and any reasonable JDK, meaning probably
1.2 and above, both individual developer choices as his/her own environment
demands) and/or if a minority of the committers is willing to put forth the
effort to support this, then support for JDK1.2 really can't be promised...
or it could be, but it would intellectually dishonest.
>On a related note, the adoption rate (migration from older versions to
>latest) for Tomcat 5.5 is higher than for previous branches, even though we
>made a decision to design for J2SE 5.0, and allow running on JDK 1.4 as
>well, but not even JDK 1.3, much less 1.2. We thought it might slow down
>adoption or generate complaints, and the opposite has been true. I'm not
>saying log4j is the same type of product, just providing a data point.
You gave people a little kick in the butt and they responded by keeping up
with the times! Go figure. Good for Tomcat, good for developers. Thanks,
Yoav! :-)
Jake
>
>Yoav
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
RE: log4j 1.3 minimum JDK (was Re: [VOTE] Release log4j 1.2.12rc3)
Posted by Yoav Shapira <yo...@MIT.EDU>.
Hi,
> I wholeheartedly agree. Dropping 1.2 support "just because it's old" is
> very silly - there must be some -reason- behind that choice.
>
> Regards,
> Endre
True, but the reason doesn't have to be technical. If, for a given log4j
release, the marginal cost (in terms of developer time spent on the issue,
for example) of maintaining JDK 1.2 support exceeds the marginal benefit (in
terms of how many users of that release use JDK 1.2 AND would update to the
given log4j release), that's a reason to dump support. That's fairly
elementary project management.
Of course, if there's a developer willing to spend all the time and effort
needed to support it, so be it. Until we actually run into a technical
reason.
On a related note, the adoption rate (migration from older versions to
latest) for Tomcat 5.5 is higher than for previous branches, even though we
made a decision to design for J2SE 5.0, and allow running on JDK 1.4 as
well, but not even JDK 1.3, much less 1.2. We thought it might slow down
adoption or generate complaints, and the opposite has been true. I'm not
saying log4j is the same type of product, just providing a data point.
Yoav
RE: log4j 1.3 minimum JDK (was Re: [VOTE] Release log4j 1.2.12rc3)
Posted by Endre Stølsvik <En...@Stolsvik.com>.
On Tue, 16 Aug 2005, Mark Womack wrote:
| But is there some specific reason why we want to upgrade and be compatible
| with only >= JDK 1.3? Is there some core class we really need to use in
| order to make log4j better? If not, then I don't see a compelling reason to
| self-limit ourselves to >= JDK 1.3. We are a logging framework, it just
| makes more sense to be as compatible as we can be, imo. It is one of the
| pluses for log4j vs jdk 1.4 logging.
I wholeheartedly agree. Dropping 1.2 support "just because it's old" is
very silly - there must be some -reason- behind that choice.
Regards,
Endre
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
RE: log4j 1.3 minimum JDK (was Re: [VOTE] Release log4j 1.2.12rc3)
Posted by Mark Womack <wo...@adobe.com>.
But is there some specific reason why we want to upgrade and be compatible
with only >= JDK 1.3? Is there some core class we really need to use in
order to make log4j better? If not, then I don't see a compelling reason to
self-limit ourselves to >= JDK 1.3. We are a logging framework, it just
makes more sense to be as compatible as we can be, imo. It is one of the
pluses for log4j vs jdk 1.4 logging.
-Mark
> -----Original Message-----
> From: Yoav Shapira [mailto:yoavsh@MIT.EDU]
> Sent: Monday, August 15, 2005 10:41 PM
> To: 'Log4J Developers List'
> Subject: RE: log4j 1.3 minimum JDK (was Re: [VOTE] Release log4j
> 1.2.12rc3)
>
> Hola,
> +1 on JDK 1.3. It's more than five years old now. If someone hasn't
> updated their JVM in 5 years, they're not going to update log4j from
> 1.2...
>
> Yoav Shapira
> System Design and Management Fellow
> MIT Sloan School of Management
> Cambridge, MA USA
> yoavs@computer.org / www.yoavshapira.com
>
> > -----Original Message-----
> > From: Curt Arnold [mailto:carnold@apache.org]
> > Sent: Monday, August 15, 2005 9:32 PM
> > To: Log4J Developers List
> > Subject: log4j 1.3 minimum JDK (was Re: [VOTE] Release log4j 1.2.12rc3)
> >
> >
> > On Aug 15, 2005, at 8:23 PM, Paul Smith wrote:
> >
> > > This does beg the question that one of the original design goals of
> > > log4j 1.3 was that it's minimum requirement would be JDK 1.2. Are
> > > we still all in favour of that? I would like to think that JDK 1.3
> > > would be an acceptable minimum in this day and age?
> >
> > I think we need to break that off into another thread to not confuse
> > the issue. I could be persuaded. We'd also should specify whether
> > we target J2ME or some other subset.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> > For additional commands, e-mail: log4j-dev-help@logging.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
RE: log4j 1.3 minimum JDK (was Re: [VOTE] Release log4j 1.2.12rc3)
Posted by Yoav Shapira <yo...@MIT.EDU>.
Hola,
+1 on JDK 1.3. It's more than five years old now. If someone hasn't
updated their JVM in 5 years, they're not going to update log4j from 1.2...
Yoav Shapira
System Design and Management Fellow
MIT Sloan School of Management
Cambridge, MA USA
yoavs@computer.org / www.yoavshapira.com
> -----Original Message-----
> From: Curt Arnold [mailto:carnold@apache.org]
> Sent: Monday, August 15, 2005 9:32 PM
> To: Log4J Developers List
> Subject: log4j 1.3 minimum JDK (was Re: [VOTE] Release log4j 1.2.12rc3)
>
>
> On Aug 15, 2005, at 8:23 PM, Paul Smith wrote:
>
> > This does beg the question that one of the original design goals of
> > log4j 1.3 was that it's minimum requirement would be JDK 1.2. Are
> > we still all in favour of that? I would like to think that JDK 1.3
> > would be an acceptable minimum in this day and age?
>
> I think we need to break that off into another thread to not confuse
> the issue. I could be persuaded. We'd also should specify whether
> we target J2ME or some other subset.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
log4j 1.3 minimum JDK (was Re: [VOTE] Release log4j 1.2.12rc3)
Posted by Curt Arnold <ca...@apache.org>.
On Aug 15, 2005, at 8:23 PM, Paul Smith wrote:
> This does beg the question that one of the original design goals of
> log4j 1.3 was that it's minimum requirement would be JDK 1.2. Are
> we still all in favour of that? I would like to think that JDK 1.3
> would be an acceptable minimum in this day and age?
I think we need to break that off into another thread to not confuse
the issue. I could be persuaded. We'd also should specify whether
we target J2ME or some other subset.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [VOTE] Release log4j 1.2.12rc3
Posted by Paul Smith <ps...@aconex.com>.
This does beg the question that one of the original design goals of
log4j 1.3 was that it's minimum requirement would be JDK 1.2. Are we
still all in favour of that? I would like to think that JDK 1.3
would be an acceptable minimum in this day and age?
Paul
On 16/08/2005, at 9:47 AM, Curt Arnold wrote:
> Things are not ideal when trying to run log4j 1.2.12 on JDK 1.2 or
> 1.1 and not at all happy when trying to build it there. Later
> javac compilers should produce bytecode compatible with earlier
> JVM's, but when attempting to run log4j on JDK 1.1 or JDK 1.2, you
> will likely get a warning like:
>
>
>> "A nonfatal internal
>> JIT (3.00.72b(x)) error 'chgTar: Conditional' has occurred in org/
>> apache/logj4/Hierarchy.getLogger()..."
>>
>
> However the application appears to function tolerably.
>
> If you attempt to build log4j with Ant 1.5.4 or later (current is
> 1.6.5) on JDK 1.2, you will also get the same message but the build
> will stall. Ant 1.5 did not have that problem. I didn't check
> 1.5.1, .2 or .3.
>
> JDK 1.2 and earlier compilers had problems with "final" member
> variables requiring them to be set at declaration instead of
> accepting them being set in the constructor.
> org.apache.log4j.chainsaw.LoggingReciever will fail to compile with
> early javac due to this compiler bug and could be modified to work
> around the compiler bug.
>
> Building log4j on JDK 1.2 requires a jar containing the JNDI API
> (javax.naming.Context, etc). JNDI got bundled into JDK 1.3, but a
> quick search did not come up with a jar for JDK 1.2.
>
> All these issues should also exist for log4j 1.2.11, but there have
> been no complaints about use of log4j 1.2.11 on older platforms, so
> it appears that the universe of users tracking our current releases
> are not running on older platforms.
>
> I think going back in time and trying to find a JDK 1.2 compatible
> version of Ant, etc, is too destabilizing and not consistent with
> our RC's and 1.2.11.
>
> I'd be +1 for proceeding with a candidate build as long as we add a
> proviso that running log4j 1.2.12 on JDK 1.2 or 1.1 is not
> recommended/tested/supported or something that would hopefully
> discourage someone from just dropping in log4j 1.2.12 into a
> mission critical JDK 1.1 or 1.2 application.
>
> I have not confirmed that everything is satisfactory on JDK 1.3,
> but will before voting on a release.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
RE: [VOTE] Release log4j 1.2.12rc3
Posted by Mark Womack <wo...@adobe.com>.
There has to be a way for us to generate JDK 1.1 compatible code. I thought
that was what the src and target attributes were doing in the ant javac
task.
-Mark
> -----Original Message-----
> From: Curt Arnold [mailto:carnold@apache.org]
> Sent: Monday, August 15, 2005 4:48 PM
> To: Log4J Developers List
> Subject: Re: [VOTE] Release log4j 1.2.12rc3
>
> Things are not ideal when trying to run log4j 1.2.12 on JDK 1.2 or
> 1.1 and not at all happy when trying to build it there. Later javac
> compilers should produce bytecode compatible with earlier JVM's, but
> when attempting to run log4j on JDK 1.1 or JDK 1.2, you will likely
> get a warning like:
>
> > "A nonfatal internal
> > JIT (3.00.72b(x)) error 'chgTar: Conditional' has occurred in org/
> > apache/logj4/Hierarchy.getLogger()..."
>
> However the application appears to function tolerably.
>
> If you attempt to build log4j with Ant 1.5.4 or later (current is
> 1.6.5) on JDK 1.2, you will also get the same message but the build
> will stall. Ant 1.5 did not have that problem. I didn't check
> 1.5.1, .2 or .3.
>
> JDK 1.2 and earlier compilers had problems with "final" member
> variables requiring them to be set at declaration instead of
> accepting them being set in the constructor.
> org.apache.log4j.chainsaw.LoggingReciever will fail to compile with
> early javac due to this compiler bug and could be modified to work
> around the compiler bug.
>
> Building log4j on JDK 1.2 requires a jar containing the JNDI API
> (javax.naming.Context, etc). JNDI got bundled into JDK 1.3, but a
> quick search did not come up with a jar for JDK 1.2.
>
> All these issues should also exist for log4j 1.2.11, but there have
> been no complaints about use of log4j 1.2.11 on older platforms, so
> it appears that the universe of users tracking our current releases
> are not running on older platforms.
>
> I think going back in time and trying to find a JDK 1.2 compatible
> version of Ant, etc, is too destabilizing and not consistent with our
> RC's and 1.2.11.
>
> I'd be +1 for proceeding with a candidate build as long as we add a
> proviso that running log4j 1.2.12 on JDK 1.2 or 1.1 is not
> recommended/tested/supported or something that would hopefully
> discourage someone from just dropping in log4j 1.2.12 into a mission
> critical JDK 1.1 or 1.2 application.
>
> I have not confirmed that everything is satisfactory on JDK 1.3, but
> will before voting on a release.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
RE: [VOTE] Release log4j 1.2.12rc3
Posted by Yoav Shapira <yo...@MIT.EDU>.
Hi,
> Things are not ideal when trying to run log4j 1.2.12 on JDK 1.2 or
> 1.1 and not at all happy when trying to build it there.
I'm glad someone is testing this ;)
> Building log4j on JDK 1.2 requires a jar containing the JNDI API
> (javax.naming.Context, etc). JNDI got bundled into JDK 1.3, but a
> quick search did not come up with a jar for JDK 1.2.
http://java.sun.com/products/jndi/downloads/index.html, click on the
"Download JNDI 1.2.1" link.
Yoav Shapira
System Design and Management Fellow
MIT Sloan School of Management
Cambridge, MA USA
yoavs@computer.org / www.yoavshapira.com
Re: [VOTE] Release log4j 1.2.12rc3
Posted by Curt Arnold <ca...@apache.org>.
Things are not ideal when trying to run log4j 1.2.12 on JDK 1.2 or
1.1 and not at all happy when trying to build it there. Later javac
compilers should produce bytecode compatible with earlier JVM's, but
when attempting to run log4j on JDK 1.1 or JDK 1.2, you will likely
get a warning like:
> "A nonfatal internal
> JIT (3.00.72b(x)) error 'chgTar: Conditional' has occurred in org/
> apache/logj4/Hierarchy.getLogger()..."
However the application appears to function tolerably.
If you attempt to build log4j with Ant 1.5.4 or later (current is
1.6.5) on JDK 1.2, you will also get the same message but the build
will stall. Ant 1.5 did not have that problem. I didn't check
1.5.1, .2 or .3.
JDK 1.2 and earlier compilers had problems with "final" member
variables requiring them to be set at declaration instead of
accepting them being set in the constructor.
org.apache.log4j.chainsaw.LoggingReciever will fail to compile with
early javac due to this compiler bug and could be modified to work
around the compiler bug.
Building log4j on JDK 1.2 requires a jar containing the JNDI API
(javax.naming.Context, etc). JNDI got bundled into JDK 1.3, but a
quick search did not come up with a jar for JDK 1.2.
All these issues should also exist for log4j 1.2.11, but there have
been no complaints about use of log4j 1.2.11 on older platforms, so
it appears that the universe of users tracking our current releases
are not running on older platforms.
I think going back in time and trying to find a JDK 1.2 compatible
version of Ant, etc, is too destabilizing and not consistent with our
RC's and 1.2.11.
I'd be +1 for proceeding with a candidate build as long as we add a
proviso that running log4j 1.2.12 on JDK 1.2 or 1.1 is not
recommended/tested/supported or something that would hopefully
discourage someone from just dropping in log4j 1.2.12 into a mission
critical JDK 1.1 or 1.2 application.
I have not confirmed that everything is satisfactory on JDK 1.3, but
will before voting on a release.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [VOTE] Release log4j 1.2.12rc3
Posted by Paul Smith <ps...@aconex.com>.
+1
On 16/08/2005, at 2:28 AM, Mark Womack wrote:
> I move that we release log4j 1.2.12rc3 as the official release of
> v1.2.12.
> We have addressed a number of annoying bugs, we have added the
> TRACE level.
> The rc candidates have been made available to the user base via email
> announcements. No new issues have been reported.
>
> If we accept 1.2.12rc3 as the final, then I take the rc3 cvs tag,
> modify the
> build number to 1.2.12, tag as v1.2.12 and build the final version
> that the
> LS PMC can then vote to release.
>
> I am +1.
>
> -Mark
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [VOTE] Release log4j 1.2.12rc3
Posted by Jacob Kjome <ho...@visi.com>.
+0
I haven't been involved enough in 1.2.xx development and testing to voice much
of an opition here. I certainly don't want to hold it up if other think it
should be released, hence +0.
Jake
Quoting Mark Womack <wo...@adobe.com>:
> I move that we release log4j 1.2.12rc3 as the official release of v1.2.12.
> We have addressed a number of annoying bugs, we have added the TRACE level.
> The rc candidates have been made available to the user base via email
> announcements. No new issues have been reported.
>
> If we accept 1.2.12rc3 as the final, then I take the rc3 cvs tag, modify the
> build number to 1.2.12, tag as v1.2.12 and build the final version that the
> LS PMC can then vote to release.
>
> I am +1.
>
> -Mark
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org