You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Geir Magnusson Jr <ge...@pobox.com> on 2006/05/30 18:10:51 UTC
[classlib] logging from within our implementation
Seems like there is an important issue here, but the discussion can't
seem to escape out of the thicket of the example.
1) Should we allow any logging from within the classlibrary?
2) How should we do it?
There are a bunch of ways for the second question... using j.u.l, using
IOC and injecting our own logging target to reduce dependencies and
make people think before logging, using aspects?
Comments? We probably should try to get to a conclusion in general...
geir
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib] logging from within our implementation
Posted by Alexei Zakharov <al...@gmail.com>.
Mark,
> My non-virtual machine of choice is a linux system. It's DNS provider
> (in the system libraries) doesn't log failures directly.
> I can't understand why it should be different for my virtual machine.
Your choice is linux, other person's choice is windows, I'm ok with
both. Unix systems are known with their silent command line tools and
this is not the only possible way we necessarily should go. I don't
see why this Linux <-> JVM corellation should be so strong.
> My operating system provides a number of specialist tools for
> diagnosing/resolving (pardon the pun) DNS problems, I'd rather use them
> for this task than burden the jvm with this task. They will undoubtedly
> do a better job because that is their only job.
Sorry, I didn't catch it. You are arguing against java DNS tools? Sun
has it, it is better for us to have it. And if we have it, it is
better to have a good tool rather than bad one. And a good tool does
the job as good as it can. Including providing meaningful user-level
log messages (let it be disabled by default if you prefer). ;-)
2006/6/8, Mark Hindess <ma...@googlemail.com>:
>
> My non-virtual machine of choice is a linux system. It's DNS provider
> (in the system libraries) doesn't log failures directly.
>
> I can't understand why it should be different for my virtual machine.
> Certainly no other JVM's do this and we should be striving to maintain
> behaviour that isn't going to surprise/confuse users[0].
>
> My operating system provides a number of specialist tools for
> diagnosing/resolving (pardon the pun) DNS problems, I'd rather use them
> for this task than burden the jvm with this task. They will undoubtedly
> do a better job because that is their only job.
>
> I realise that this is an argument for not having logging on by
> default. It is not an argument for not having logging at all.
>
> Just my 0.02 GBP.
>
> Regards,
> Mark.
>
> [0] There may be times when the greater good is served by breaking this
> rule - surprising users not confusing them ;-) - but I don't think
> this is one of them.
>
> On 8 June 2006 at 20:03, "Alexei Zakharov" <al...@gmail.com> wrote:
> > Once again. DNS provider does not look like another math lib. Yes, it
> > is a part of JVM. But it is a network application nevetheless like ftp
> > client, icq or whatever. It needs to warn people about some network
> > conditions and events without self-termination. It has maximum one
> > user-level log message (nano- or microseconds) per several network
> > transactions (can last many seconds). I don't see any reasonable
> > motivation to remove such messages. We won't get any performance
> > impact. Only reduce the usability of the system by doing this.
> >
> > 2006/6/8, Geir Magnusson Jr <ge...@pobox.com>:
> > > I can't recall my jvms ever logging that way for critical stuff - they
> > > usually just throw errors, right?
> > >
> > > Alexei Zakharov wrote:
> > > > People, have compassion on critical error/info messages at least (>=
> > > > Level.WARNING) . This is not a DEBUG logging, this is useful stuff for
> > > > end user!
> > > >
> > > > 2006/6/8, Geir Magnusson Jr <ge...@pobox.com>:
> > > >>
> > > >>
> > > >> Tim Ellison wrote:
> > > >> > Resurrecting this thread, with some trepidation...
> > > >> >
> > > >> > We went round the houses a bit, but did we reach a conclusion to the
> > > >> > questions you posed?
> > > >>
> > > >> Sadly, no, it doesn't seem so.
> > > >>
> > > >> I was hoping that Aspect-Master-George might give us some hints...
> > > >>
> > > >> >
> > > >> > I'm eager to fix-up the DNS provider code.
> > > >>
> > > >> Is there something driving that other than the desire to "put it to
> > > >> bed"? (Just curious)
> > > >>
> > > >> Can you just comment the stuff out? (or I can - I'll be happy to)
> > > >>
> > > >> geir
> > > >>
> > > >> >
> > > >> > Regards,
> > > >> > Tim
> > > >> >
> > > >> > Geir Magnusson Jr wrote:
> > > >> >> Seems like there is an important issue here, but the discussion can't
> > > >> >> seem to escape out of the thicket of the example.
> > > >> >>
> > > >> >> 1) Should we allow any logging from within the classlibrary?
> > > >> >>
> > > >> >> 2) How should we do it?
> > > >> >>
> > > >> >> There are a bunch of ways for the second question... using j.u.l,
> > > >> using
> > > >> >> IOC and injecting our own logging target to reduce dependencies and
> > > >> >> make people think before logging, using aspects?
> > > >> >>
> > > >> >> Comments? We probably should try to get to a conclusion in general..
> > .
> > > >> >>
> > > >> >> geir
> > > >
> > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> > > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> > >
> > >
> >
> >
> > --
> > Alexei Zakharov,
> > Intel Middleware Product Division
> >
> > ---------------------------------------------------------------------
> > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
--
Alexei Zakharov,
Intel Middleware Product Division
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib] logging from within our implementation
Posted by Tim Ellison <t....@gmail.com>.
There are many places where the VM / class libraries interact with the
outside world; in some cases very similar to the DNS provider (e.g.
URLClassLoader, ServerSocketChannel, etc) in other cases no so similar
(e.g. allocating OS memory, writing to the file system, etc).
As Geir said, the code typically will deal with problems it encounters
where it makes sense to continue, or throws an exception / error where
it does not.
An advantage of being a 'virtual' machine is that you can introspect the
execution (debugging, execution trace, exceptions, etc.) orthogonally to
the application logic relatively easily.
Regards,
Tim
Alexei Zakharov wrote:
> Once again. DNS provider does not look like another math lib. Yes, it
> is a part of JVM. But it is a network application nevetheless like ftp
> client, icq or whatever. It needs to warn people about some network
> conditions and events without self-termination. It has maximum one
> user-level log message (nano- or microseconds) per several network
> transactions (can last many seconds). I don't see any reasonable
> motivation to remove such messages. We won't get any performance
> impact. Only reduce the usability of the system by doing this.
>
> 2006/6/8, Geir Magnusson Jr <ge...@pobox.com>:
>> I can't recall my jvms ever logging that way for critical stuff - they
>> usually just throw errors, right?
>>
>> Alexei Zakharov wrote:
>> > People, have compassion on critical error/info messages at least (>=
>> > Level.WARNING) . This is not a DEBUG logging, this is useful stuff for
>> > end user!
>> >
>> > 2006/6/8, Geir Magnusson Jr <ge...@pobox.com>:
>> >>
>> >>
>> >> Tim Ellison wrote:
>> >> > Resurrecting this thread, with some trepidation...
>> >> >
>> >> > We went round the houses a bit, but did we reach a conclusion to the
>> >> > questions you posed?
>> >>
>> >> Sadly, no, it doesn't seem so.
>> >>
>> >> I was hoping that Aspect-Master-George might give us some hints...
>> >>
>> >> >
>> >> > I'm eager to fix-up the DNS provider code.
>> >>
>> >> Is there something driving that other than the desire to "put it to
>> >> bed"? (Just curious)
>> >>
>> >> Can you just comment the stuff out? (or I can - I'll be happy to)
>> >>
>> >> geir
>> >>
>> >> >
>> >> > Regards,
>> >> > Tim
>> >> >
>> >> > Geir Magnusson Jr wrote:
>> >> >> Seems like there is an important issue here, but the discussion
>> can't
>> >> >> seem to escape out of the thicket of the example.
>> >> >>
>> >> >> 1) Should we allow any logging from within the classlibrary?
>> >> >>
>> >> >> 2) How should we do it?
>> >> >>
>> >> >> There are a bunch of ways for the second question... using j.u.l,
>> >> using
>> >> >> IOC and injecting our own logging target to reduce dependencies
>> and
>> >> >> make people think before logging, using aspects?
>> >> >>
>> >> >> Comments? We probably should try to get to a conclusion in
>> general...
>> >> >>
>> >> >> geir
>> >
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>
>>
>
>
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib] logging from within our implementation
Posted by Alexei Zakharov <al...@gmail.com>.
Once again. DNS provider does not look like another math lib. Yes, it
is a part of JVM. But it is a network application nevetheless like ftp
client, icq or whatever. It needs to warn people about some network
conditions and events without self-termination. It has maximum one
user-level log message (nano- or microseconds) per several network
transactions (can last many seconds). I don't see any reasonable
motivation to remove such messages. We won't get any performance
impact. Only reduce the usability of the system by doing this.
2006/6/8, Geir Magnusson Jr <ge...@pobox.com>:
> I can't recall my jvms ever logging that way for critical stuff - they
> usually just throw errors, right?
>
> Alexei Zakharov wrote:
> > People, have compassion on critical error/info messages at least (>=
> > Level.WARNING) . This is not a DEBUG logging, this is useful stuff for
> > end user!
> >
> > 2006/6/8, Geir Magnusson Jr <ge...@pobox.com>:
> >>
> >>
> >> Tim Ellison wrote:
> >> > Resurrecting this thread, with some trepidation...
> >> >
> >> > We went round the houses a bit, but did we reach a conclusion to the
> >> > questions you posed?
> >>
> >> Sadly, no, it doesn't seem so.
> >>
> >> I was hoping that Aspect-Master-George might give us some hints...
> >>
> >> >
> >> > I'm eager to fix-up the DNS provider code.
> >>
> >> Is there something driving that other than the desire to "put it to
> >> bed"? (Just curious)
> >>
> >> Can you just comment the stuff out? (or I can - I'll be happy to)
> >>
> >> geir
> >>
> >> >
> >> > Regards,
> >> > Tim
> >> >
> >> > Geir Magnusson Jr wrote:
> >> >> Seems like there is an important issue here, but the discussion can't
> >> >> seem to escape out of the thicket of the example.
> >> >>
> >> >> 1) Should we allow any logging from within the classlibrary?
> >> >>
> >> >> 2) How should we do it?
> >> >>
> >> >> There are a bunch of ways for the second question... using j.u.l,
> >> using
> >> >> IOC and injecting our own logging target to reduce dependencies and
> >> >> make people think before logging, using aspects?
> >> >>
> >> >> Comments? We probably should try to get to a conclusion in general...
> >> >>
> >> >> geir
> >
> >
> >
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
--
Alexei Zakharov,
Intel Middleware Product Division
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib] logging from within our implementation
Posted by Geir Magnusson Jr <ge...@pobox.com>.
I can't recall my jvms ever logging that way for critical stuff - they
usually just throw errors, right?
Alexei Zakharov wrote:
> People, have compassion on critical error/info messages at least (>=
> Level.WARNING) . This is not a DEBUG logging, this is useful stuff for
> end user!
>
> 2006/6/8, Geir Magnusson Jr <ge...@pobox.com>:
>>
>>
>> Tim Ellison wrote:
>> > Resurrecting this thread, with some trepidation...
>> >
>> > We went round the houses a bit, but did we reach a conclusion to the
>> > questions you posed?
>>
>> Sadly, no, it doesn't seem so.
>>
>> I was hoping that Aspect-Master-George might give us some hints...
>>
>> >
>> > I'm eager to fix-up the DNS provider code.
>>
>> Is there something driving that other than the desire to "put it to
>> bed"? (Just curious)
>>
>> Can you just comment the stuff out? (or I can - I'll be happy to)
>>
>> geir
>>
>> >
>> > Regards,
>> > Tim
>> >
>> > Geir Magnusson Jr wrote:
>> >> Seems like there is an important issue here, but the discussion can't
>> >> seem to escape out of the thicket of the example.
>> >>
>> >> 1) Should we allow any logging from within the classlibrary?
>> >>
>> >> 2) How should we do it?
>> >>
>> >> There are a bunch of ways for the second question... using j.u.l,
>> using
>> >> IOC and injecting our own logging target to reduce dependencies and
>> >> make people think before logging, using aspects?
>> >>
>> >> Comments? We probably should try to get to a conclusion in general...
>> >>
>> >> geir
>
>
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib] logging from within our implementation
Posted by Alexei Zakharov <al...@gmail.com>.
People, have compassion on critical error/info messages at least (>=
Level.WARNING) . This is not a DEBUG logging, this is useful stuff for
end user!
2006/6/8, Geir Magnusson Jr <ge...@pobox.com>:
>
>
> Tim Ellison wrote:
> > Resurrecting this thread, with some trepidation...
> >
> > We went round the houses a bit, but did we reach a conclusion to the
> > questions you posed?
>
> Sadly, no, it doesn't seem so.
>
> I was hoping that Aspect-Master-George might give us some hints...
>
> >
> > I'm eager to fix-up the DNS provider code.
>
> Is there something driving that other than the desire to "put it to
> bed"? (Just curious)
>
> Can you just comment the stuff out? (or I can - I'll be happy to)
>
> geir
>
> >
> > Regards,
> > Tim
> >
> > Geir Magnusson Jr wrote:
> >> Seems like there is an important issue here, but the discussion can't
> >> seem to escape out of the thicket of the example.
> >>
> >> 1) Should we allow any logging from within the classlibrary?
> >>
> >> 2) How should we do it?
> >>
> >> There are a bunch of ways for the second question... using j.u.l, using
> >> IOC and injecting our own logging target to reduce dependencies and
> >> make people think before logging, using aspects?
> >>
> >> Comments? We probably should try to get to a conclusion in general...
> >>
> >> geir
--
Alexei Zakharov,
Intel Middleware Product Division
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib] logging from within our implementation
Posted by Alexei Zakharov <al...@gmail.com>.
> > I promise that if we need logging then I'll personally volunteer to
> > uncomment those same lines, and let Alexei make fun of me while saying
> > 'I told you so'.
> in Russian.
I can do it in several languages of your choice (Russian, English,
Japanese) if this helps to resolve the situation with logging. :)
2006/6/9, Geir Magnusson Jr <ge...@pobox.com>:
> Tim Ellison wrote:
> > Geir Magnusson Jr wrote:
> >> Tim Ellison wrote:
> >>> Resurrecting this thread, with some trepidation...
> >>>
> >>> We went round the houses a bit, but did we reach a conclusion to the
> >>> questions you posed?
> >> Sadly, no, it doesn't seem so.
> >>
> >> I was hoping that Aspect-Master-George might give us some hints...
> >>
> >>> I'm eager to fix-up the DNS provider code.
> >> Is there something driving that other than the desire to "put it to
> >> bed"? (Just curious)
> >>
> >> Can you just comment the stuff out? (or I can - I'll be happy to)
> >
> > Ok, so here goes...
> >
> > I shall leave the logging statements in place but comment them out (so
> > they are easy to replace if we decide we can't live without them, or
> > indeed that all classlib code should contain logging) and I will remove
> > the o.a.h.util.logging.LogConst type from the JNDI module.
>
> Oh, o.a.h.util.logging.LogConst... we barely knew ye....
>
> >
> > I promise that if we need logging then I'll personally volunteer to
> > uncomment those same lines, and let Alexei make fun of me while saying
> > 'I told you so'.
>
> in Russian.
>
> geir
>
> >
> > Regards,
> > Tim
--
Alexei Zakharov,
Intel Middleware Product Division
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib] logging from within our implementation
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Tim Ellison wrote:
> Geir Magnusson Jr wrote:
>> Tim Ellison wrote:
>>> Resurrecting this thread, with some trepidation...
>>>
>>> We went round the houses a bit, but did we reach a conclusion to the
>>> questions you posed?
>> Sadly, no, it doesn't seem so.
>>
>> I was hoping that Aspect-Master-George might give us some hints...
>>
>>> I'm eager to fix-up the DNS provider code.
>> Is there something driving that other than the desire to "put it to
>> bed"? (Just curious)
>>
>> Can you just comment the stuff out? (or I can - I'll be happy to)
>
> Ok, so here goes...
>
> I shall leave the logging statements in place but comment them out (so
> they are easy to replace if we decide we can't live without them, or
> indeed that all classlib code should contain logging) and I will remove
> the o.a.h.util.logging.LogConst type from the JNDI module.
Oh, o.a.h.util.logging.LogConst... we barely knew ye....
>
> I promise that if we need logging then I'll personally volunteer to
> uncomment those same lines, and let Alexei make fun of me while saying
> 'I told you so'.
in Russian.
geir
>
> Regards,
> Tim
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib] logging from within our implementation
Posted by Tim Ellison <t....@gmail.com>.
Geir Magnusson Jr wrote:
>
> Tim Ellison wrote:
>> Resurrecting this thread, with some trepidation...
>>
>> We went round the houses a bit, but did we reach a conclusion to the
>> questions you posed?
>
> Sadly, no, it doesn't seem so.
>
> I was hoping that Aspect-Master-George might give us some hints...
>
>> I'm eager to fix-up the DNS provider code.
>
> Is there something driving that other than the desire to "put it to
> bed"? (Just curious)
>
> Can you just comment the stuff out? (or I can - I'll be happy to)
Ok, so here goes...
I shall leave the logging statements in place but comment them out (so
they are easy to replace if we decide we can't live without them, or
indeed that all classlib code should contain logging) and I will remove
the o.a.h.util.logging.LogConst type from the JNDI module.
I promise that if we need logging then I'll personally volunteer to
uncomment those same lines, and let Alexei make fun of me while saying
'I told you so'.
Regards,
Tim
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib] logging from within our implementation
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Tim Ellison wrote:
> Resurrecting this thread, with some trepidation...
>
> We went round the houses a bit, but did we reach a conclusion to the
> questions you posed?
Sadly, no, it doesn't seem so.
I was hoping that Aspect-Master-George might give us some hints...
>
> I'm eager to fix-up the DNS provider code.
Is there something driving that other than the desire to "put it to
bed"? (Just curious)
Can you just comment the stuff out? (or I can - I'll be happy to)
geir
>
> Regards,
> Tim
>
> Geir Magnusson Jr wrote:
>> Seems like there is an important issue here, but the discussion can't
>> seem to escape out of the thicket of the example.
>>
>> 1) Should we allow any logging from within the classlibrary?
>>
>> 2) How should we do it?
>>
>> There are a bunch of ways for the second question... using j.u.l, using
>> IOC and injecting our own logging target to reduce dependencies and
>> make people think before logging, using aspects?
>>
>> Comments? We probably should try to get to a conclusion in general...
>>
>> geir
>>
>> ---------------------------------------------------------------------
>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>
>>
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib] logging from within our implementation
Posted by Tim Ellison <t....@gmail.com>.
Resurrecting this thread, with some trepidation...
We went round the houses a bit, but did we reach a conclusion to the
questions you posed?
I'm eager to fix-up the DNS provider code.
Regards,
Tim
Geir Magnusson Jr wrote:
> Seems like there is an important issue here, but the discussion can't
> seem to escape out of the thicket of the example.
>
> 1) Should we allow any logging from within the classlibrary?
>
> 2) How should we do it?
>
> There are a bunch of ways for the second question... using j.u.l, using
> IOC and injecting our own logging target to reduce dependencies and
> make people think before logging, using aspects?
>
> Comments? We probably should try to get to a conclusion in general...
>
> geir
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib] logging from within our implementation
Posted by Alexei Zakharov <al...@gmail.com>.
I can agree that libraries like java.util and java.math probably will
not need any logging on the production stage. But some parts of the
classlib look more like applications rather than libraries. Providers
can be the good example. And logging for such apps can be considered
as part of UI. Let's say UI for advanced users. Such app will lost its
usefulness if logging is completely removed.
A lot of applications use logging. All enterprise servers extensively
use logging in spite of the fact that performance is very important
for j2ee.
2006/5/30, Gregory Shimansky <gs...@gmail.com>:
> On Tuesday 30 May 2006 22:59 Tim Ellison wrote:
> > >> The logging info being proposed is developer-oriented. I hope that
> > >> people are not expecting our users to understand our developer trace
> > >> info -- we, as developers, have better tools than printf to figure out
> > >> what is happening.
> > >
> > > I have to admit that I don't agree w/ "better" as a universally general
> > > statement,
> >
> > Well I guess it is a POV, but give me a java-aware debugger and trace
> > tools over printf any day.
>
> Hello Tim
>
> I don't want to start any flame, but want to show an example of an application
> (yes it is not a class library, just a big java application) which has a lot
> of logging hardcoded into it. It is Eclipse :)
>
> Maybe java-aware debugger didn't help eclipse developers all the time as much
> as tracing did.
>
> --
> Gregory Shimansky, Intel Middleware Products Division
--
Alexei Zakharov,
Intel Middleware Product Division
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib] logging from within our implementation
Posted by Gregory Shimansky <gs...@gmail.com>.
On Tuesday 30 May 2006 22:59 Tim Ellison wrote:
> >> The logging info being proposed is developer-oriented. I hope that
> >> people are not expecting our users to understand our developer trace
> >> info -- we, as developers, have better tools than printf to figure out
> >> what is happening.
> >
> > I have to admit that I don't agree w/ "better" as a universally general
> > statement,
>
> Well I guess it is a POV, but give me a java-aware debugger and trace
> tools over printf any day.
Hello Tim
I don't want to start any flame, but want to show an example of an application
(yes it is not a class library, just a big java application) which has a lot
of logging hardcoded into it. It is Eclipse :)
Maybe java-aware debugger didn't help eclipse developers all the time as much
as tracing did.
--
Gregory Shimansky, Intel Middleware Products Division
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib] logging from within our implementation
Posted by Mikhail Loenko <ml...@gmail.com>.
I have a question.
Consider scenario:
JRE has java.security configuration file that includes list of
providers. At some
(usually start-up) time this file is being loaded and parsed. Then providers are
loaded too and list of available algorithms is created.
Some algorithms or even whole providers might require native libraries, those
libraries could be unavailable at the moment of load attempt.
If the libraries are unavailable we have the following options:
1. Do not include algorithm that requires unavailable libraries into the list
of available algorithms.
2. Do not include whole provider
3. Terminate VM
It is reasonabe that 1&2 are supplemented with some logging.
RI seems to do #2 plus logging.
What should we do if logging is prohibited?
Thanks,
Mikhail
2006/5/31, Geir Magnusson Jr <ge...@pobox.com>:
>
>
> Tim Ellison wrote:
> > Geir Magnusson Jr wrote:
> >>> The logging info being proposed is developer-oriented. I hope that
> >>> people are not expecting our users to understand our developer trace
> >>> info -- we, as developers, have better tools than printf to figure out
> >>> what is happening.
> >> I have to admit that I don't agree w/ "better" as a universally general
> >> statement,
> >
> > Well I guess it is a POV, but give me a java-aware debugger and trace
> > tools over printf any day.
>
> To be clear [again], don't get caught on "printf", because no one is
> advocating that, I believe.
>
> geir
>
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib] logging from within our implementation
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Tim Ellison wrote:
> Geir Magnusson Jr wrote:
>>> The logging info being proposed is developer-oriented. I hope that
>>> people are not expecting our users to understand our developer trace
>>> info -- we, as developers, have better tools than printf to figure out
>>> what is happening.
>> I have to admit that I don't agree w/ "better" as a universally general
>> statement,
>
> Well I guess it is a POV, but give me a java-aware debugger and trace
> tools over printf any day.
To be clear [again], don't get caught on "printf", because no one is
advocating that, I believe.
geir
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib] logging from within our implementation
Posted by Tim Ellison <t....@gmail.com>.
Geir Magnusson Jr wrote:
>
>
> Tim Ellison wrote:
>> Geir Magnusson Jr wrote:
>>> Seems like there is an important issue here, but the discussion can't
>>> seem to escape out of the thicket of the example.
>>>
>>> 1) Should we allow any logging from within the classlibrary?
>>
>> Just in case there was any doubt from my earlier postings...
>>
>> I think we should not be explicitly logging debug info as part of our
>> class library implementation.
>
> In any form?
Right -- no explicit logging in any form.
>>> 2) How should we do it?
>>>
>>> There are a bunch of ways for the second question... using j.u.l, using
>>> IOC and injecting our own logging target to reduce dependencies and
>>> make people think before logging, using aspects?
>>
>> Both j.u.l and IoC would require code in the implementation to perform
>> the logging actions (or check the guard). Putting this logic throughout
>> the class library will IMHO result in module coupling, code bloat and
>> overall performance degradation (or no logging!).
>
> Right - that's why I was thinking of the latter.
i.e. aspects?
> Something that would
> have no runtime overhead, yet allow us to capture more information other
> than just execution path and stack values :)
>>
>> Adding logging statements is expecting the class library developer to
>> decide /a priori/ what debug|trace info is useful to the person trying
>> to resolve a problem. Existing debug|trace tools work with the runtime
>> to figure out the pertinent information as you are interested in it.
>> (The only caveat being 'flight data recorder' type trace where the trace
>> points are typically very low overhead and always on).
>>
>>> Comments? We probably should try to get to a conclusion in general...
>>
>> The logging info being proposed is developer-oriented. I hope that
>> people are not expecting our users to understand our developer trace
>> info -- we, as developers, have better tools than printf to figure out
>> what is happening.
>
> I have to admit that I don't agree w/ "better" as a universally general
> statement,
Well I guess it is a POV, but give me a java-aware debugger and trace
tools over printf any day.
> as debug statements can include information provided by the
> developer not immediately obvious.
I would claim that there are tools that can provide the statement value
info 'live' rather than having to encode them into the class library
code directly.
> Is there some kind of aspect framework we can use? Then for
> develeopers, they have to implicitly do something to get the stuff to
> come out, it's not a runtime cost for anyone else, and the stuff stays
> in the codebase for use later?
Aspects can be applied to the code without any explicit modification to
the class library logic, so there is nothing to 'stay in the codebase'.
Regards,
Tim
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib] logging from within our implementation
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Chris Gray wrote:
>
> It's probably also not a good idea to rely too much on JIT optimisations,
> given that Harmony should run on a number of VMs and not all of these will
> have a fully optimising JIT in all circumstances. It should be possible to
> compile the class libraries with or without logging.
Yes - that was my thought which I was hoping someone would bring up and
I wouldn't have to :)
geir
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib] logging from within our implementation
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Alex Blewitt wrote:
>
> They removed the debugging statements, and it ran so fast that they
> discovered all kinds of race conditions that they hadn't designed for.
> So they had to put the debugging statements back in to slow it down
> before shipping it to the customer :-) Mind you, I expect that
> marketing would have jumped on the bandwaggon with 2.0! Much faster
> than 1.0! but I didn't hang around long enough there to find out :-)
I ran into this same exact problem years ago working on one of the first
multi-processor direct-to-disk digital audio recording/editing systems.
We inherited the halfway done OS from someone and our job was to
finish it.
It worked ok but had a lot of yammering to the console, so we knocked
out all the debug printfs.
It stopped working. (There is no "close enough" when feeding audio to a
D/A... if you are late, you are late and you can hear it...)
There were two of us doing it as a consulting project, and I can to this
day remember the look of utter fear in my partner's eyes as we had about
3 weeks left to the biggest tradeshow of the year.
We eventually got it working, but it was a very valuable and painful lesson.
geir
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib] logging from within our implementation
Posted by Stefano Mazzocchi <st...@apache.org>.
Alexei Zakharov wrote:
> However, I like the general idea of using Velocity as a Java preprocessor
> :)
I really don't.
--
Stefano.
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib] logging from within our implementation
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Alexei Zakharov wrote:
> I worry about the situation when we got something Velocity-like in
> java code. Strings like "#foreach" or smth. like it in comments. This
> will probably break the V. compiler.
>
Hey now....
Where do we have #foreach in our code?
geir
> 2006/6/1, Soeren Strassfeld <nc...@netcologne.de>:
>> Hi Alexei,
>>
>> I think the result in both examples is quite the same, I just liked
>> the Idea to just add java comments to the code, so you don´t
>> need a precompiler as long as you build the classlib with logging
>> statements.
>>
>> Cheers,
>> Soeren
>>
>> Alexei Zakharov schrieb:
>> > Hi Soeren,
>> >
>> > 2006/6/1, Soeren Strassfeld <nc...@netcologne.de>:
>> >> How about using Velocity as Preprocessor.
>> >> You could put all logging Statements between an
>> >> //#if ($debug)
>> >> and
>> >> //#end
>> >> So the Code would stay pure java, and the debug Version could be
>> >> compiled
>> >> without a Preprocessor.
>> >
>> > Is this something better than just using java in the same way?
>> >
>> > static final boolean DEBUG = false;
>> > if (DEBUG) {
>> > // wiped away by java compiler
>> > log("my useful log message");
>> > }
>> >
>> > The problem of your approach as well as the above example is the
>> > additional syntax you need to add to each log call.
>> >
>> > However, I like the general idea of using Velocity as a Java
>> preprocessor
>> > :)
>> >
>
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib] logging from within our implementation
Posted by Alexei Zakharov <al...@gmail.com>.
For example, I failed to pass the following valid Java fragment
through the Velocity 1.4 compiler:
public static void main(String argv[]) {
// for #foreach lovers
String s = "I love #foreach statement";
}
2006/6/2, Geir Magnusson Jr <ge...@pobox.com>:
>
>
> Alexei Zakharov wrote:
> >> Where do we have #foreach in our code?
> >
> > I suppose nowhere currently. I mean we will need to define additional
> > coding rules to avoid using of such strings in the future.
>
> Why? velocity does a reasonable job at figuring out VTL-like things
> that aren't VTL...
>
> geir
>
> >
> >> (who wrote a significant portion of velocity...)
> >
> > Really? I had no idea about that :))
> >
> >
> > 2006/6/2, Geir Magnusson Jr <ge...@pobox.com>:
> >> Prove it.
> >>
> >> geir
> >>
> >> (who wrote a significant portion of velocity...)
> >>
> >> Soeren Strassfeld wrote:
> >> > That´s true, of course!
> >> >
> >> > Alexei Zakharov schrieb:
> >> >> I worry about the situation when we got something Velocity-like in
> >> >> java code. Strings like "#foreach" or smth. like it in comments. This
> >> >> will probably break the V. compiler.
> >> >>
> >> >> 2006/6/1, Soeren Strassfeld <nc...@netcologne.de>:
> >> >>> Hi Alexei,
> >> >>>
> >> >>> I think the result in both examples is quite the same, I just liked
> >> >>> the Idea to just add java comments to the code, so you don´t
> >> >>> need a precompiler as long as you build the classlib with logging
> >> >>> statements.
> >> >>>
> >> >>> Cheers,
> >> >>> Soeren
> >> >>>
> >> >>> Alexei Zakharov schrieb:
> >> >>> > Hi Soeren,
> >> >>> >
> >> >>> > 2006/6/1, Soeren Strassfeld <nc...@netcologne.de>:
> >> >>> >> How about using Velocity as Preprocessor.
> >> >>> >> You could put all logging Statements between an
> >> >>> >> //#if ($debug)
> >> >>> >> and
> >> >>> >> //#end
> >> >>> >> So the Code would stay pure java, and the debug Version could be
> >> >>> >> compiled
> >> >>> >> without a Preprocessor.
> >> >>> >
> >> >>> > Is this something better than just using java in the same way?
> >> >>> >
> >> >>> > static final boolean DEBUG = false;
> >> >>> > if (DEBUG) {
> >> >>> > // wiped away by java compiler
> >> >>> > log("my useful log message");
> >> >>> > }
> >> >>> >
> >> >>> > The problem of your approach as well as the above example is the
> >> >>> > additional syntax you need to add to each log call.
> >> >>> >
> >> >>> > However, I like the general idea of using Velocity as a Java
> >> >>> preprocessor
> >> >>> > :)
--
Alexei Zakharov,
Intel Middleware Product Division
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib] logging from within our implementation
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Alexei Zakharov wrote:
>> Where do we have #foreach in our code?
>
> I suppose nowhere currently. I mean we will need to define additional
> coding rules to avoid using of such strings in the future.
Why? velocity does a reasonable job at figuring out VTL-like things
that aren't VTL...
geir
>
>> (who wrote a significant portion of velocity...)
>
> Really? I had no idea about that :))
>
>
> 2006/6/2, Geir Magnusson Jr <ge...@pobox.com>:
>> Prove it.
>>
>> geir
>>
>> (who wrote a significant portion of velocity...)
>>
>> Soeren Strassfeld wrote:
>> > That´s true, of course!
>> >
>> > Alexei Zakharov schrieb:
>> >> I worry about the situation when we got something Velocity-like in
>> >> java code. Strings like "#foreach" or smth. like it in comments. This
>> >> will probably break the V. compiler.
>> >>
>> >> 2006/6/1, Soeren Strassfeld <nc...@netcologne.de>:
>> >>> Hi Alexei,
>> >>>
>> >>> I think the result in both examples is quite the same, I just liked
>> >>> the Idea to just add java comments to the code, so you don´t
>> >>> need a precompiler as long as you build the classlib with logging
>> >>> statements.
>> >>>
>> >>> Cheers,
>> >>> Soeren
>> >>>
>> >>> Alexei Zakharov schrieb:
>> >>> > Hi Soeren,
>> >>> >
>> >>> > 2006/6/1, Soeren Strassfeld <nc...@netcologne.de>:
>> >>> >> How about using Velocity as Preprocessor.
>> >>> >> You could put all logging Statements between an
>> >>> >> //#if ($debug)
>> >>> >> and
>> >>> >> //#end
>> >>> >> So the Code would stay pure java, and the debug Version could be
>> >>> >> compiled
>> >>> >> without a Preprocessor.
>> >>> >
>> >>> > Is this something better than just using java in the same way?
>> >>> >
>> >>> > static final boolean DEBUG = false;
>> >>> > if (DEBUG) {
>> >>> > // wiped away by java compiler
>> >>> > log("my useful log message");
>> >>> > }
>> >>> >
>> >>> > The problem of your approach as well as the above example is the
>> >>> > additional syntax you need to add to each log call.
>> >>> >
>> >>> > However, I like the general idea of using Velocity as a Java
>> >>> preprocessor
>> >>> > :)
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib] logging from within our implementation
Posted by Alexei Zakharov <al...@gmail.com>.
>Where do we have #foreach in our code?
I suppose nowhere currently. I mean we will need to define additional
coding rules to avoid using of such strings in the future.
> (who wrote a significant portion of velocity...)
Really? I had no idea about that :))
2006/6/2, Geir Magnusson Jr <ge...@pobox.com>:
> Prove it.
>
> geir
>
> (who wrote a significant portion of velocity...)
>
> Soeren Strassfeld wrote:
> > That´s true, of course!
> >
> > Alexei Zakharov schrieb:
> >> I worry about the situation when we got something Velocity-like in
> >> java code. Strings like "#foreach" or smth. like it in comments. This
> >> will probably break the V. compiler.
> >>
> >> 2006/6/1, Soeren Strassfeld <nc...@netcologne.de>:
> >>> Hi Alexei,
> >>>
> >>> I think the result in both examples is quite the same, I just liked
> >>> the Idea to just add java comments to the code, so you don´t
> >>> need a precompiler as long as you build the classlib with logging
> >>> statements.
> >>>
> >>> Cheers,
> >>> Soeren
> >>>
> >>> Alexei Zakharov schrieb:
> >>> > Hi Soeren,
> >>> >
> >>> > 2006/6/1, Soeren Strassfeld <nc...@netcologne.de>:
> >>> >> How about using Velocity as Preprocessor.
> >>> >> You could put all logging Statements between an
> >>> >> //#if ($debug)
> >>> >> and
> >>> >> //#end
> >>> >> So the Code would stay pure java, and the debug Version could be
> >>> >> compiled
> >>> >> without a Preprocessor.
> >>> >
> >>> > Is this something better than just using java in the same way?
> >>> >
> >>> > static final boolean DEBUG = false;
> >>> > if (DEBUG) {
> >>> > // wiped away by java compiler
> >>> > log("my useful log message");
> >>> > }
> >>> >
> >>> > The problem of your approach as well as the above example is the
> >>> > additional syntax you need to add to each log call.
> >>> >
> >>> > However, I like the general idea of using Velocity as a Java
> >>> preprocessor
> >>> > :)
--
Alexei Zakharov,
Intel Middleware Product Division
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib] logging from within our implementation
Posted by Alexei Zakharov <al...@gmail.com>.
After several tries I've got the desired result with
//#if ($debug)\
log.finest("my useful debug message");
//#end\
But probably there is a nicer way to do the same thing. I am not an
expert in Velocity.
2006/6/2, Soeren Strassfeld <nc...@netcologne.de>:
> At least, you have to be very careful.
> Just had a simple test
> where
> public static void main(String[] args){
> //#if (true)
> System.out.println("logging");
> //#end
> }
> was merged to
> public static void main(String[] args){
> // System.out.println("logging");
> // }
>
> Soeren
>
> (who thanks Geir every day for velocity ;)
>
> Geir Magnusson Jr schrieb:
> > Prove it.
> >
> > geir
> >
> > (who wrote a significant portion of velocity...)
> >
> >
> >
> > Soeren Strassfeld wrote:
> >
> >> That´s true, of course!
> >>
> >> Alexei Zakharov schrieb:
> >>
> >>> I worry about the situation when we got something Velocity-like in
> >>> java code. Strings like "#foreach" or smth. like it in comments. This
> >>> will probably break the V. compiler.
> >>>
> >>> 2006/6/1, Soeren Strassfeld <nc...@netcologne.de>:
> >>>
> >>>> Hi Alexei,
> >>>>
> >>>> I think the result in both examples is quite the same, I just liked
> >>>> the Idea to just add java comments to the code, so you don´t
> >>>> need a precompiler as long as you build the classlib with logging
> >>>> statements.
> >>>>
> >>>> Cheers,
> >>>> Soeren
> >>>>
> >>>> Alexei Zakharov schrieb:
> >>>>
> >>>>> Hi Soeren,
> >>>>>
> >>>>> 2006/6/1, Soeren Strassfeld <nc...@netcologne.de>:
> >>>>>
> >>>>>> How about using Velocity as Preprocessor.
> >>>>>> You could put all logging Statements between an
> >>>>>> //#if ($debug)
> >>>>>> and
> >>>>>> //#end
> >>>>>> So the Code would stay pure java, and the debug Version could be
> >>>>>> compiled
> >>>>>> without a Preprocessor.
> >>>>>>
> >>>>> Is this something better than just using java in the same way?
> >>>>>
> >>>>> static final boolean DEBUG = false;
> >>>>> if (DEBUG) {
> >>>>> // wiped away by java compiler
> >>>>> log("my useful log message");
> >>>>> }
> >>>>>
> >>>>> The problem of your approach as well as the above example is the
> >>>>> additional syntax you need to add to each log call.
> >>>>>
> >>>>> However, I like the general idea of using Velocity as a Java
> >>>>>
> >>>> preprocessor
> >>>>
> >>>>> :)
--
Alexei Zakharov,
Intel Middleware Product Division
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib] logging from within our implementation
Posted by Geir Magnusson Jr <ge...@pobox.com>.
I looks like it did exactly what you told it to do :)
geir
Soeren Strassfeld wrote:
> At least, you have to be very careful.
> Just had a simple test
> where
> public static void main(String[] args){
> //#if (true)
> System.out.println("logging");
> //#end
> }
> was merged to
> public static void main(String[] args){
> // System.out.println("logging");
> // }
>
> Soeren
>
> (who thanks Geir every day for velocity ;)
>
> Geir Magnusson Jr schrieb:
>> Prove it.
>>
>> geir
>>
>> (who wrote a significant portion of velocity...)
>>
>>
>>
>> Soeren Strassfeld wrote:
>>
>>> That´s true, of course!
>>>
>>> Alexei Zakharov schrieb:
>>>
>>>> I worry about the situation when we got something Velocity-like in
>>>> java code. Strings like "#foreach" or smth. like it in comments. This
>>>> will probably break the V. compiler.
>>>>
>>>> 2006/6/1, Soeren Strassfeld <nc...@netcologne.de>:
>>>>
>>>>> Hi Alexei,
>>>>>
>>>>> I think the result in both examples is quite the same, I just liked
>>>>> the Idea to just add java comments to the code, so you don´t
>>>>> need a precompiler as long as you build the classlib with logging
>>>>> statements.
>>>>>
>>>>> Cheers,
>>>>> Soeren
>>>>>
>>>>> Alexei Zakharov schrieb:
>>>>>
>>>>>> Hi Soeren,
>>>>>>
>>>>>> 2006/6/1, Soeren Strassfeld <nc...@netcologne.de>:
>>>>>>
>>>>>>> How about using Velocity as Preprocessor.
>>>>>>> You could put all logging Statements between an
>>>>>>> //#if ($debug)
>>>>>>> and
>>>>>>> //#end
>>>>>>> So the Code would stay pure java, and the debug Version could be
>>>>>>> compiled
>>>>>>> without a Preprocessor.
>>>>>>>
>>>>>> Is this something better than just using java in the same way?
>>>>>>
>>>>>> static final boolean DEBUG = false;
>>>>>> if (DEBUG) {
>>>>>> // wiped away by java compiler
>>>>>> log("my useful log message");
>>>>>> }
>>>>>>
>>>>>> The problem of your approach as well as the above example is the
>>>>>> additional syntax you need to add to each log call.
>>>>>>
>>>>>> However, I like the general idea of using Velocity as a Java
>>>>>>
>>>>> preprocessor
>>>>>
>>>>>> :)
>>>>>>
>>>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib] logging from within our implementation
Posted by Soeren Strassfeld <nc...@netcologne.de>.
At least, you have to be very careful.
Just had a simple test
where
public static void main(String[] args){
//#if (true)
System.out.println("logging");
//#end
}
was merged to
public static void main(String[] args){
// System.out.println("logging");
// }
Soeren
(who thanks Geir every day for velocity ;)
Geir Magnusson Jr schrieb:
> Prove it.
>
> geir
>
> (who wrote a significant portion of velocity...)
>
>
>
> Soeren Strassfeld wrote:
>
>> That´s true, of course!
>>
>> Alexei Zakharov schrieb:
>>
>>> I worry about the situation when we got something Velocity-like in
>>> java code. Strings like "#foreach" or smth. like it in comments. This
>>> will probably break the V. compiler.
>>>
>>> 2006/6/1, Soeren Strassfeld <nc...@netcologne.de>:
>>>
>>>> Hi Alexei,
>>>>
>>>> I think the result in both examples is quite the same, I just liked
>>>> the Idea to just add java comments to the code, so you don´t
>>>> need a precompiler as long as you build the classlib with logging
>>>> statements.
>>>>
>>>> Cheers,
>>>> Soeren
>>>>
>>>> Alexei Zakharov schrieb:
>>>>
>>>>> Hi Soeren,
>>>>>
>>>>> 2006/6/1, Soeren Strassfeld <nc...@netcologne.de>:
>>>>>
>>>>>> How about using Velocity as Preprocessor.
>>>>>> You could put all logging Statements between an
>>>>>> //#if ($debug)
>>>>>> and
>>>>>> //#end
>>>>>> So the Code would stay pure java, and the debug Version could be
>>>>>> compiled
>>>>>> without a Preprocessor.
>>>>>>
>>>>> Is this something better than just using java in the same way?
>>>>>
>>>>> static final boolean DEBUG = false;
>>>>> if (DEBUG) {
>>>>> // wiped away by java compiler
>>>>> log("my useful log message");
>>>>> }
>>>>>
>>>>> The problem of your approach as well as the above example is the
>>>>> additional syntax you need to add to each log call.
>>>>>
>>>>> However, I like the general idea of using Velocity as a Java
>>>>>
>>>> preprocessor
>>>>
>>>>> :)
>>>>>
>>>>>
>>>
>> ---------------------------------------------------------------------
>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>
>>
>>
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib] logging from within our implementation
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Prove it.
geir
(who wrote a significant portion of velocity...)
Soeren Strassfeld wrote:
> That´s true, of course!
>
> Alexei Zakharov schrieb:
>> I worry about the situation when we got something Velocity-like in
>> java code. Strings like "#foreach" or smth. like it in comments. This
>> will probably break the V. compiler.
>>
>> 2006/6/1, Soeren Strassfeld <nc...@netcologne.de>:
>>> Hi Alexei,
>>>
>>> I think the result in both examples is quite the same, I just liked
>>> the Idea to just add java comments to the code, so you don´t
>>> need a precompiler as long as you build the classlib with logging
>>> statements.
>>>
>>> Cheers,
>>> Soeren
>>>
>>> Alexei Zakharov schrieb:
>>> > Hi Soeren,
>>> >
>>> > 2006/6/1, Soeren Strassfeld <nc...@netcologne.de>:
>>> >> How about using Velocity as Preprocessor.
>>> >> You could put all logging Statements between an
>>> >> //#if ($debug)
>>> >> and
>>> >> //#end
>>> >> So the Code would stay pure java, and the debug Version could be
>>> >> compiled
>>> >> without a Preprocessor.
>>> >
>>> > Is this something better than just using java in the same way?
>>> >
>>> > static final boolean DEBUG = false;
>>> > if (DEBUG) {
>>> > // wiped away by java compiler
>>> > log("my useful log message");
>>> > }
>>> >
>>> > The problem of your approach as well as the above example is the
>>> > additional syntax you need to add to each log call.
>>> >
>>> > However, I like the general idea of using Velocity as a Java
>>> preprocessor
>>> > :)
>>> >
>>
>>
>
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib] logging from within our implementation
Posted by Soeren Strassfeld <nc...@netcologne.de>.
That´s true, of course!
Alexei Zakharov schrieb:
> I worry about the situation when we got something Velocity-like in
> java code. Strings like "#foreach" or smth. like it in comments. This
> will probably break the V. compiler.
>
> 2006/6/1, Soeren Strassfeld <nc...@netcologne.de>:
>> Hi Alexei,
>>
>> I think the result in both examples is quite the same, I just liked
>> the Idea to just add java comments to the code, so you don´t
>> need a precompiler as long as you build the classlib with logging
>> statements.
>>
>> Cheers,
>> Soeren
>>
>> Alexei Zakharov schrieb:
>> > Hi Soeren,
>> >
>> > 2006/6/1, Soeren Strassfeld <nc...@netcologne.de>:
>> >> How about using Velocity as Preprocessor.
>> >> You could put all logging Statements between an
>> >> //#if ($debug)
>> >> and
>> >> //#end
>> >> So the Code would stay pure java, and the debug Version could be
>> >> compiled
>> >> without a Preprocessor.
>> >
>> > Is this something better than just using java in the same way?
>> >
>> > static final boolean DEBUG = false;
>> > if (DEBUG) {
>> > // wiped away by java compiler
>> > log("my useful log message");
>> > }
>> >
>> > The problem of your approach as well as the above example is the
>> > additional syntax you need to add to each log call.
>> >
>> > However, I like the general idea of using Velocity as a Java
>> preprocessor
>> > :)
>> >
>
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib] logging from within our implementation
Posted by Alexei Zakharov <al...@gmail.com>.
I worry about the situation when we got something Velocity-like in
java code. Strings like "#foreach" or smth. like it in comments. This
will probably break the V. compiler.
2006/6/1, Soeren Strassfeld <nc...@netcologne.de>:
> Hi Alexei,
>
> I think the result in both examples is quite the same, I just liked
> the Idea to just add java comments to the code, so you don´t
> need a precompiler as long as you build the classlib with logging
> statements.
>
> Cheers,
> Soeren
>
> Alexei Zakharov schrieb:
> > Hi Soeren,
> >
> > 2006/6/1, Soeren Strassfeld <nc...@netcologne.de>:
> >> How about using Velocity as Preprocessor.
> >> You could put all logging Statements between an
> >> //#if ($debug)
> >> and
> >> //#end
> >> So the Code would stay pure java, and the debug Version could be
> >> compiled
> >> without a Preprocessor.
> >
> > Is this something better than just using java in the same way?
> >
> > static final boolean DEBUG = false;
> > if (DEBUG) {
> > // wiped away by java compiler
> > log("my useful log message");
> > }
> >
> > The problem of your approach as well as the above example is the
> > additional syntax you need to add to each log call.
> >
> > However, I like the general idea of using Velocity as a Java preprocessor
> > :)
> >
--
Alexei Zakharov,
Intel Middleware Product Division
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib] logging from within our implementation
Posted by Soeren Strassfeld <nc...@netcologne.de>.
Hi Alexei,
I think the result in both examples is quite the same, I just liked
the Idea to just add java comments to the code, so you don´t
need a precompiler as long as you build the classlib with logging
statements.
Cheers,
Soeren
Alexei Zakharov schrieb:
> Hi Soeren,
>
> 2006/6/1, Soeren Strassfeld <nc...@netcologne.de>:
>> How about using Velocity as Preprocessor.
>> You could put all logging Statements between an
>> //#if ($debug)
>> and
>> //#end
>> So the Code would stay pure java, and the debug Version could be
>> compiled
>> without a Preprocessor.
>
> Is this something better than just using java in the same way?
>
> static final boolean DEBUG = false;
> if (DEBUG) {
> // wiped away by java compiler
> log("my useful log message");
> }
>
> The problem of your approach as well as the above example is the
> additional syntax you need to add to each log call.
>
> However, I like the general idea of using Velocity as a Java preprocessor
> :)
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib] logging from within our implementation
Posted by Alexei Zakharov <al...@gmail.com>.
Hi Soeren,
2006/6/1, Soeren Strassfeld <nc...@netcologne.de>:
> How about using Velocity as Preprocessor.
> You could put all logging Statements between an
> //#if ($debug)
> and
> //#end
> So the Code would stay pure java, and the debug Version could be compiled
> without a Preprocessor.
Is this something better than just using java in the same way?
static final boolean DEBUG = false;
if (DEBUG) {
// wiped away by java compiler
log("my useful log message");
}
The problem of your approach as well as the above example is the
additional syntax you need to add to each log call.
However, I like the general idea of using Velocity as a Java preprocessor
:)
--
Alexei Zakharov,
Intel Middleware Product Division
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib] logging from within our implementation
Posted by Soeren Strassfeld <nc...@netcologne.de>.
Hi all,
How about using Velocity as Preprocessor.
You could put all logging Statements between an
//#if ($debug)
and
//#end
So the Code would stay pure java, and the debug Version could be compiled
without a Preprocessor.
Regards,
Soeren
Anton Luht schrieb:
> It is possible to remove all calls to logging below a certain level
> from .class files using BCEL:
> http://surguy.net/articles/removing-log-messages.xml . In this example
> logging is removed on fly when class is loaded, but this tool can be
> run against class files in the process of building release version.
> For example, debug version can contain all logging and release - only
> errors. This approach has one disadvantage: it is non-standard and
> looks like a dirty hack :)
>
> On 31 May 2006 19:24:18 +0700, Egor Pasko <eg...@gmail.com> wrote:
>> On the 0x17A day of Apache Harmony Alex Blewitt wrote:
>> > Moral 1: saying 'It's OK, debug logging can be turned off and
>> > log.debug(msg) is inexpensive' is a lie. If you really feel the need
>> > for sprinkling debug statements everywhere (and I'm with others in
>> > using a good IDE to track down problems) then surround every debug
>> > with if (log.debugEnabled()) { log.debug(msg) }. Yes, it has the same
>> > effect, but at least you don't bother wasting the calcuation of the
>> > message itself, and in this case, even a dozy JIT can optimise it
>> > away.
>>
>> +1 for log.debugEnabled() :)
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [offlist] Re: [classlib] logging from within our implementation
Posted by Leo Simons <ma...@leosimons.com>.
On Mon, Jun 05, 2006 at 11:17:50AM +0100, Tim Ellison wrote:
> [Eek! ok so you can see that wasn't intended to go onto the list]
FWIW and IMVHO, this kind of thing is entirely appropriate on-list :-)
> Apologies for embarrassing George (... but buy the book anyway<g>)
I just might!
> Tim Ellison wrote:
> > Talk to George, he's a world expert on Aspects
> >
> > (and co-author of a book on the subject)
> > http://www.amazon.com/gp/product/0321245873/qid=1149502393/sr=1-1/ref=sr_1_1/102-7435876-8007311?s=books&v=glance&n=283155
> >
> > Regards,
> > Tim
> >
> >
> > Geir Magnusson Jr wrote:
> >> Stefano Mazzocchi wrote:
> >>
> >>> Maybe we should start thinking more with that in mind and think about
> >>> scratching our own itches in terms of development... we might find some
> >>> serious innovation on the way to there.
> >>>
> >> I think the disagreement boils down to defining the "itch". I'm not
> >> interested in the overhead because while we will own the VM for our
> >> distro, it's still overhead and additionally, we want others w/ VMs to
> >> use our classlibrary too (like Sun, BEA, IBM, Apple... )
> >>
> >> I'm going to dork around w/ aspects to see if we can make the addition
> >> of debugging a pre-processing step used by people that want to debug...
> >>
> >> geir
--
LSD
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [offlist] Re: [classlib] logging from within our implementation
Posted by Tim Ellison <t....@gmail.com>.
[Eek! ok so you can see that wasn't intended to go onto the list]
Apologies for embarrassing George (... but buy the book anyway<g>)
Tim
Tim Ellison wrote:
> Talk to George, he's a world expert on Aspects
>
> (and co-author of a book on the subject)
> http://www.amazon.com/gp/product/0321245873/qid=1149502393/sr=1-1/ref=sr_1_1/102-7435876-8007311?s=books&v=glance&n=283155
>
> Regards,
> Tim
>
>
> Geir Magnusson Jr wrote:
>> Stefano Mazzocchi wrote:
>>
>>> Maybe we should start thinking more with that in mind and think about
>>> scratching our own itches in terms of development... we might find some
>>> serious innovation on the way to there.
>>>
>> I think the disagreement boils down to defining the "itch". I'm not
>> interested in the overhead because while we will own the VM for our
>> distro, it's still overhead and additionally, we want others w/ VMs to
>> use our classlibrary too (like Sun, BEA, IBM, Apple... )
>>
>> I'm going to dork around w/ aspects to see if we can make the addition
>> of debugging a pre-processing step used by people that want to debug...
>>
>> geir
>>
>> ---------------------------------------------------------------------
>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>
>>
>
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [offlist] Re: [classlib] logging from within our implementation
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Cool - he can tell us how it's done then :)
geir
Tim Ellison wrote:
> Talk to George, he's a world expert on Aspects
>
> (and co-author of a book on the subject)
> http://www.amazon.com/gp/product/0321245873/qid=1149502393/sr=1-1/ref=sr_1_1/102-7435876-8007311?s=books&v=glance&n=283155
>
> Regards,
> Tim
>
>
> Geir Magnusson Jr wrote:
>> Stefano Mazzocchi wrote:
>>
>>> Maybe we should start thinking more with that in mind and think about
>>> scratching our own itches in terms of development... we might find some
>>> serious innovation on the way to there.
>>>
>> I think the disagreement boils down to defining the "itch". I'm not
>> interested in the overhead because while we will own the VM for our
>> distro, it's still overhead and additionally, we want others w/ VMs to
>> use our classlibrary too (like Sun, BEA, IBM, Apple... )
>>
>> I'm going to dork around w/ aspects to see if we can make the addition
>> of debugging a pre-processing step used by people that want to debug...
>>
>> geir
>>
>> ---------------------------------------------------------------------
>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>
>>
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
[offlist] Re: [classlib] logging from within our implementation
Posted by Tim Ellison <t....@gmail.com>.
Talk to George, he's a world expert on Aspects
(and co-author of a book on the subject)
http://www.amazon.com/gp/product/0321245873/qid=1149502393/sr=1-1/ref=sr_1_1/102-7435876-8007311?s=books&v=glance&n=283155
Regards,
Tim
Geir Magnusson Jr wrote:
>
> Stefano Mazzocchi wrote:
>
>> Maybe we should start thinking more with that in mind and think about
>> scratching our own itches in terms of development... we might find some
>> serious innovation on the way to there.
>>
>
> I think the disagreement boils down to defining the "itch". I'm not
> interested in the overhead because while we will own the VM for our
> distro, it's still overhead and additionally, we want others w/ VMs to
> use our classlibrary too (like Sun, BEA, IBM, Apple... )
>
> I'm going to dork around w/ aspects to see if we can make the addition
> of debugging a pre-processing step used by people that want to debug...
>
> geir
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib] logging from within our implementation
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Stefano Mazzocchi wrote:
>
> Maybe we should start thinking more with that in mind and think about
> scratching our own itches in terms of development... we might find some
> serious innovation on the way to there.
>
I think the disagreement boils down to defining the "itch". I'm not
interested in the overhead because while we will own the VM for our
distro, it's still overhead and additionally, we want others w/ VMs to
use our classlibrary too (like Sun, BEA, IBM, Apple... )
I'm going to dork around w/ aspects to see if we can make the addition
of debugging a pre-processing step used by people that want to debug...
geir
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib] logging from within our implementation
Posted by Stefano Mazzocchi <st...@apache.org>.
Vladimir Gorr wrote:
> We need to remember the class file transformation via BCEL implies the
> performance degradation at load-time.
> IMO using the source code like this
>
> *static final boolean DEBUG = false;
> if (DEBUG) {
> // wiped away by java compiler
> log("my useful log message");
> }
> *
> will give better performance but demands the additional efforts for the
> re-factoring the source code.
People,
in case you have forgotten, we are writing a virtual machine, which
means we can practically do anything, including externally triggered
runtime bytecode modification. Aspect injection, whatever.
I've seen a presentation of JRockit's management console and they seem
to be able to do stuff like that (I need to play more)
As much as I'm a proud printf kind of guy, I never had the luxury of
owning the keys to the internals of the machine that ran my code.
Maybe we should start thinking more with that in mind and think about
scratching our own itches in terms of development... we might find some
serious innovation on the way to there.
--
Stefano.
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib] logging from within our implementation
Posted by Vladimir Gorr <vv...@gmail.com>.
We need to remember the class file transformation via BCEL implies the
performance degradation at load-time.
IMO using the source code like this
*static final boolean DEBUG = false;
if (DEBUG) {
// wiped away by java compiler
log("my useful log message");
}
*
will give better performance but demands the additional efforts for the
re-factoring the source code.
Thanks,
Vladimir.
On 6/1/06, Anton Luht <an...@gmail.com> wrote:
>
> Alexei,
>
> I've suggested BCEL but not ASM because it is an Apache product and
> its license certainly fits Harmony and the author tells that he used
> BCEL before.
>
> I've used it a couple of times and everything worked just fine. No
> code corruptions ever happened. It is mentioned in Sun Developer
> Network JavaOne Online Technical Sessions. Seems like it's a mature
> tool (even judging by version - 5.1 :) ).
>
> On 6/1/06, Alexei Zakharov <al...@gmail.com> wrote:
> > As far as I understand they use ObjectWEb ASM rather than BCEL in
> > their example. But in any case, this approach implies trust in these
> > code-manipulation libraries. Does it stable enough? Can't it produce
> > corrupted byte-code?
>
> --
> Regards,
> Anton Luht,
> Intel Middleware Products Division
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
Re: [classlib] logging from within our implementation
Posted by Anton Luht <an...@gmail.com>.
Alexei,
I've suggested BCEL but not ASM because it is an Apache product and
its license certainly fits Harmony and the author tells that he used
BCEL before.
I've used it a couple of times and everything worked just fine. No
code corruptions ever happened. It is mentioned in Sun Developer
Network JavaOne Online Technical Sessions. Seems like it's a mature
tool (even judging by version - 5.1 :) ).
On 6/1/06, Alexei Zakharov <al...@gmail.com> wrote:
> As far as I understand they use ObjectWEb ASM rather than BCEL in
> their example. But in any case, this approach implies trust in these
> code-manipulation libraries. Does it stable enough? Can't it produce
> corrupted byte-code?
--
Regards,
Anton Luht,
Intel Middleware Products Division
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib] logging from within our implementation
Posted by Alexei Zakharov <al...@gmail.com>.
As far as I understand they use ObjectWEb ASM rather than BCEL in
their example. But in any case, this approach implies trust in these
code-manipulation libraries. Does it stable enough? Can't it produce
corrupted byte-code?
2006/6/1, Geir Magnusson Jr <ge...@pobox.com>:
>
> Anton Luht wrote:
> > It is possible to remove all calls to logging below a certain level
> > from .class files using BCEL:
> > http://surguy.net/articles/removing-log-messages.xml . In this example
> > logging is removed on fly when class is loaded, but this tool can be
> > run against class files in the process of building release version.
> > For example, debug version can contain all logging and release - only
> > errors. This approach has one disadvantage: it is non-standard and
> > looks like a dirty hack :)
>
> Yah. I'd rather see us add the logging this way rather than removing
> it, using annotations or aspects or something... I'll try to experiment
> with this tomorrow.
---
Alexei Zakharov,
Intel Middleware Product Division
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib] logging from within our implementation
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Anton Luht wrote:
> It is possible to remove all calls to logging below a certain level
> from .class files using BCEL:
> http://surguy.net/articles/removing-log-messages.xml . In this example
> logging is removed on fly when class is loaded, but this tool can be
> run against class files in the process of building release version.
> For example, debug version can contain all logging and release - only
> errors. This approach has one disadvantage: it is non-standard and
> looks like a dirty hack :)
>
Yah. I'd rather see us add the logging this way rather than removing
it, using annotations or aspects or something... I'll try to experiment
with this tomorrow.
I really hate discussing logging. It's impossible to have a short
conversation where everyone agrees. Yoko, the CORBA project in the
incubator, is going through a very similar issue...
geir
> On 31 May 2006 19:24:18 +0700, Egor Pasko <eg...@gmail.com> wrote:
>> On the 0x17A day of Apache Harmony Alex Blewitt wrote:
>> > Moral 1: saying 'It's OK, debug logging can be turned off and
>> > log.debug(msg) is inexpensive' is a lie. If you really feel the need
>> > for sprinkling debug statements everywhere (and I'm with others in
>> > using a good IDE to track down problems) then surround every debug
>> > with if (log.debugEnabled()) { log.debug(msg) }. Yes, it has the same
>> > effect, but at least you don't bother wasting the calcuation of the
>> > message itself, and in this case, even a dozy JIT can optimise it
>> > away.
>>
>> +1 for log.debugEnabled() :)
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib] logging from within our implementation
Posted by Anton Luht <an...@gmail.com>.
It is possible to remove all calls to logging below a certain level
from .class files using BCEL:
http://surguy.net/articles/removing-log-messages.xml . In this example
logging is removed on fly when class is loaded, but this tool can be
run against class files in the process of building release version.
For example, debug version can contain all logging and release - only
errors. This approach has one disadvantage: it is non-standard and
looks like a dirty hack :)
On 31 May 2006 19:24:18 +0700, Egor Pasko <eg...@gmail.com> wrote:
> On the 0x17A day of Apache Harmony Alex Blewitt wrote:
> > Moral 1: saying 'It's OK, debug logging can be turned off and
> > log.debug(msg) is inexpensive' is a lie. If you really feel the need
> > for sprinkling debug statements everywhere (and I'm with others in
> > using a good IDE to track down problems) then surround every debug
> > with if (log.debugEnabled()) { log.debug(msg) }. Yes, it has the same
> > effect, but at least you don't bother wasting the calcuation of the
> > message itself, and in this case, even a dozy JIT can optimise it
> > away.
>
> +1 for log.debugEnabled() :)
--
Regards,
Anton Luht,
Intel Middleware Products Division
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib] logging from within our implementation
Posted by Egor Pasko <eg...@gmail.com>.
On the 0x17A day of Apache Harmony Alex Blewitt wrote:
> Moral 1: saying 'It's OK, debug logging can be turned off and
> log.debug(msg) is inexpensive' is a lie. If you really feel the need
> for sprinkling debug statements everywhere (and I'm with others in
> using a good IDE to track down problems) then surround every debug
> with if (log.debugEnabled()) { log.debug(msg) }. Yes, it has the same
> effect, but at least you don't bother wasting the calcuation of the
> message itself, and in this case, even a dozy JIT can optimise it
> away.
+1 for log.debugEnabled() :)
to optimize away log.debug(obj) JIT should perform devirtualization for
toString(), with escape analysis. That may turn out to be too
expensive. So, a reasonable JIT may optimize it some day, but not
always :)
BTW, highly optimizing JIT from the DRLVM contribution (=Jitrino.OPT)
does *not* perform escape analysis yet. That resides in TODO list :)
In fact, all-pure-java annotations may help to completely solve the
issue. There may be hints for JIT that it is safe to optimize some
code in a certain way. In release mode some pieces of code can be
annotated for deletion. Is it a good practice to support annotations
of that kind in Harmony JITs? Or is it a dirty hack? :)
--
Egor Pasko, Intel Managed Runtime Division
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib] logging from within our implementation
Posted by Alex Blewitt <al...@gmail.com>.
On 31/05/06, Chris Gray <ch...@kiffer.be> wrote:
> On Tuesday 30 May 2006 23:38, Alex Blewitt wrote:
> >
> > Not necessarily. Evaluation of arguments may have side-effects, and
> > therefore even if the call to the logging gets optimised away, the
> > evaluation may not be.
>
> You're right, and the more I look at it the less likely it seems to me that
> the evaluation of parameters will be optimised away. To start with string
> concatenation: the expression ("hello " + "world") has no side-effects...
True. That's why a decent logging API doesn't just take a single
String, but can take an arbitrary number of them (or even better,
Objects). So you'd be able to do logger.info(["Hello","World"]); and
only when the logging is being performed would it need to do the
concatenation (or more likely, just two print statements). The only
problem is you'd still have the construction time of the array; I
don't know if the VARARGs implementation would solve that.
Even better, if it takes objects, you don't even need to do the
.toString() operation until you know you need it as a string.
On 31/05/06 Someone Else Wrote:
> j.u.l logging is well designed, and if used correctly, has minimal performance
> penalty, since unused logging directives are simply wiped out by optmimizing Jit.
I don't think anyone I've met thinks that j.u.l logging is well
designed. It was a bodge job that took some ideas from log4j and then
did its own thing. And unlike log4j, it could only be run on 1.4+
systems. And both of those tend to prefer having a single String
message in their arguments, with the result that everyone does a
string concatenation in their logging message (although there is a
parameterised message format, it doesn't tend to be used because it's
more verbose in calling code).
And the logging directives are *not* wiped out by an optimizing Jit.
Even if it's intelligent enough to know that the method it's calling
is a no-op, it can't guarantee that the evaluation of the arguments
have no side effects. I worked on a project once where there were
debug log statements liberally sprinkled through the code, where
messages (often large ones, as toString() are wont to create). The
issue was, the system ran like a dog even when debug logging was
disabled. The problem was that even though the log.debug(String)
wasn't doing anything, the largeObject.toString() *was* and eating up
a bunch of memory/processor for no good reason.
They removed the debugging statements, and it ran so fast that they
discovered all kinds of race conditions that they hadn't designed for.
So they had to put the debugging statements back in to slow it down
before shipping it to the customer :-) Mind you, I expect that
marketing would have jumped on the bandwaggon with 2.0! Much faster
than 1.0! but I didn't hang around long enough there to find out :-)
You've also got to take into account that no matter how clever people
think they are when using a StringBuffer in a toString() method, as
soon as you get a collection of objects, you end up with n+1
StringBuffers (one for each object's toString, and one for the
collection itsef).
If you're ever doing performant logging, it's much better to have a
toString(StringBuffer) method that allows you to pass-through a
StringBuffer into the object you want. You can even stub the
toString() to create a new StringBuffer and pass it into the
parameterised version to save doing it in many places.
Moral 1: saying 'It's OK, debug logging can be turned off and
log.debug(msg) is inexpensive' is a lie. If you really feel the need
for sprinkling debug statements everywhere (and I'm with others in
using a good IDE to track down problems) then surround every debug
with if (log.debugEnabled()) { log.debug(msg) }. Yes, it has the same
effect, but at least you don't bother wasting the calcuation of the
message itself, and in this case, even a dozy JIT can optimise it
away.
Moral 2: logging is expensive; toString() doubly so. Much better to
pass in an object (whether that's a StringBuffer or an OutputStream or
a Writer doesn't really matter) so that the toString() method can
append information as it goes, rather than creating lots of strings as
is the case with any kind of compound object.
Moral 3: If you're going to design a multi-threaded system, think
about race conditions first :-)
Alex.
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib] logging from within our implementation
Posted by Chris Gray <ch...@kiffer.be>.
On Tuesday 30 May 2006 23:38, Alex Blewitt wrote:
> On 30/05/06, Chris Gray <ch...@kiffer.be> wrote:
> > If the implementation is an empty method and is final, a straightforward
> > static flow analysis will show that the evaluation of the arguments can
> > also be optimised away.
>
> Not necessarily. Evaluation of arguments may have side-effects, and
> therefore even if the call to the logging gets optimised away, the
> evaluation may not be.
You're right, and the more I look at it the less likely it seems to me that
the evaluation of parameters will be optimised away. To start with string
concatenation: the expression ("hello " + "world") has no side-effects, but
the optimiser has to perform an escape analysis in order to recognise that
new StringBuffer("hello ").append("world")has none. (StringBuilder I guess
these days). And in ("Frobbing the " + foo), if (as is likely) the type of
foo is a non-final class or interface, all bets are off; a subclass could
override the toString() method to have all kind of side-effects. Logging
("Connecting to " + remotehost.getHostName()) certainly has side-effects.
It's probably also not a good idea to rely too much on JIT optimisations,
given that Harmony should run on a number of VMs and not all of these will
have a fully optimising JIT in all circumstances. It should be possible to
compile the class libraries with or without logging.
Chris
--
Chris Gray /k/ Embedded Java Solutions BE0503765045
Embedded & Mobile Java, OSGi http://www.k-embedded-java.com/
chris.gray@kiffer.be +32 3 216 0369
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib] logging from within our implementation
Posted by Alex Blewitt <al...@gmail.com>.
On 30/05/06, Chris Gray <ch...@kiffer.be> wrote:
> If the implementation is an empty method and is final, a straightforward
> static flow analysis will show that the evaluation of the arguments can also
> be optimised away.
Not necessarily. Evaluation of arguments may have side-effects, and
therefore even if the call to the logging gets optimised away, the
evaluation may not be. It's better to have an array of Strings and let
the logger do the concatenation rather than have a single
Object/String and performing the concatenation, because then the
logger can do the concatenation through stream manipulation rather
than in-memory copying.
That said, I don't think there's a great benefit of having logging in
production code once it's complete, and I think that an aspect would
be a better way of compiling with debugging code in.
Alex.
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib] logging from within our implementation
Posted by Chris Gray <ch...@kiffer.be>.
On Tuesday 30 May 2006 22:46, Ivan Volosyuk wrote:
> Hmm, I see one drawback of this approach: arguments will still be
> evaluated even if logger itself will be empty. So, some care needed to
> maintain performance with such logger.
If the implementation is an empty method and is final, a straightforward
static flow analysis will show that the evaluation of the arguments can also
be optimised away.
Chris
--
Chris Gray /k/ Embedded Java Solutions BE0503765045
Embedded & Mobile Java, OSGi http://www.k-embedded-java.com/
chris.gray@kiffer.be +32 3 216 0369
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib] logging from within our implementation
Posted by robert burrell donkin <ro...@gmail.com>.
On 5/30/06, Gregory Shimansky <gs...@gmail.com> wrote:
>
> On Wednesday 31 May 2006 00:46 Ivan Volosyuk wrote:
> > > Any good behaving optimizing runtime would inline empty methods into
> > > nothing and therefore no performance impact would be made.
> >
> > Excelent! This is much better and simplier.
> >
> > public final class CLogger {
> > public static void msg(Object... ) {..}
> > }
> >
> > Hmm, I see one drawback of this approach: arguments will still be
> > evaluated even if logger itself will be empty. So, some care needed to
> > maintain performance with such logger.
>
> If dead code elimination is done after inlining, then most likely code
> like
> string concatination and stuff like that would be deleted as well.
1 IMO ceki's next generation bridging API has the signatures much closer to
being right than any other lightweight API i know of. one idea is that you
provide methods with extra parameters that are concatinated in the method
(if needed). for example:
debug(Object message)
debug(Object message, Object parameterOne)
debug(Object message, Object parameterOne, Object parameterTwo)
debug(Object message, Object parameterOne, Object parameterTwo, Object
parameterThree)
for a project such as harmony, it seems reasonable (to me) to restrict the
allowed logging calls to a limited number of parameters. developers should
remove any unreasonable calls before checking. so this solution might be a
good match.
2 for harmony, i'd consider not using a logging class at all. add private do
nothing template methods to any class that is likely to need logging. if a
developer needs to turn on logging for a class they run an enhancer to wire
those calls to an appropriate logging architecture.
for example:
public class DoSomethingCool {
public void whatever(What what, Ever ever) {
debug("This is really complex!", what, ever);
...
}
private debug(Object message) {}
private debug(Object message, Object parameterOne) {}
private debug(Object message, Object parameterOne, Object parameterTwo)
{}
private debug(Object message, Object parameterOne, Object parameterTwo,
Object parameterThree) {}
}
- robert
Re: [classlib] logging from within our implementation
Posted by Gregory Shimansky <gs...@gmail.com>.
On Wednesday 31 May 2006 00:46 Ivan Volosyuk wrote:
> > Any good behaving optimizing runtime would inline empty methods into
> > nothing and therefore no performance impact would be made.
>
> Excelent! This is much better and simplier.
>
> public final class CLogger {
> public static void msg(Object... ) {..}
> }
>
> Hmm, I see one drawback of this approach: arguments will still be
> evaluated even if logger itself will be empty. So, some care needed to
> maintain performance with such logger.
If dead code elimination is done after inlining, then most likely code like
string concatination and stuff like that would be deleted as well.
Disclaimer: I am not a compiler expert, so I may be wrong.
--
Gregory Shimansky, Intel Middleware Products Division
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib] logging from within our implementation
Posted by Ivan Volosyuk <iv...@gmail.com>.
2006/5/31, Gregory Shimansky <gs...@gmail.com>:
> On Wednesday 31 May 2006 00:09 Ivan Volosyuk wrote:
> > I am not sure, we can say someday: Yes, the code is absolutely bug
> > free! Remove the logging!
> >
> > I have a suggestion, which can help leave logging in place while still
> > having no impact on performance. The logging can be used for debuging
> > of features and will be removed in release version. It require some
> > changes to build system though.
> >
> > The idea is quite simple: we can use C preprocessor directives in java
> > files. When building the preprocessor will be executed before java
> > compiler (if the source-file's timestamp was changed). Thus we can
> > have logger-free release builds and debug builds with full weight
> > logging.
>
> I have a simpler suggestion which doesn't require any tools foreign to java.
>
> Make classlib debugging infrastructure internal class, not java.util.logging,
> but an internal wrapper to classes in java.util.logging. And in release
> version all its methods should be empty.
>
> Any good behaving optimizing runtime would inline empty methods into nothing
> and therefore no performance impact would be made.
Excelent! This is much better and simplier.
public final class CLogger {
public static void msg(Object... ) {..}
}
Hmm, I see one drawback of this approach: arguments will still be
evaluated even if logger itself will be empty. So, some care needed to
maintain performance with such logger.
--
Ivan
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib] logging from within our implementation
Posted by Gregory Shimansky <gs...@gmail.com>.
On Wednesday 31 May 2006 00:09 Ivan Volosyuk wrote:
> I am not sure, we can say someday: Yes, the code is absolutely bug
> free! Remove the logging!
>
> I have a suggestion, which can help leave logging in place while still
> having no impact on performance. The logging can be used for debuging
> of features and will be removed in release version. It require some
> changes to build system though.
>
> The idea is quite simple: we can use C preprocessor directives in java
> files. When building the preprocessor will be executed before java
> compiler (if the source-file's timestamp was changed). Thus we can
> have logger-free release builds and debug builds with full weight
> logging.
I have a simpler suggestion which doesn't require any tools foreign to java.
Make classlib debugging infrastructure internal class, not java.util.logging,
but an internal wrapper to classes in java.util.logging. And in release
version all its methods should be empty.
Any good behaving optimizing runtime would inline empty methods into nothing
and therefore no performance impact would be made.
--
Gregory Shimansky, Intel Middleware Products Division
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib] logging from within our implementation
Posted by Ivan Volosyuk <iv...@gmail.com>.
I am not sure, we can say someday: Yes, the code is absolutely bug
free! Remove the logging!
I have a suggestion, which can help leave logging in place while still
having no impact on performance. The logging can be used for debuging
of features and will be removed in release version. It require some
changes to build system though.
The idea is quite simple: we can use C preprocessor directives in java
files. When building the preprocessor will be executed before java
compiler (if the source-file's timestamp was changed). Thus we can
have logger-free release builds and debug builds with full weight
logging.
--
Ivan
2006/5/30, Alexey Petrenko <al...@gmail.com>:
> +1
>
> Logging is useful on development and bugfixing stages. Since not all
> the Harmony VMs fully supports JVMDI, JMVPI or JVMTI.
> And it will be better to remove all the logging after finishing
> development/bugfixing.
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib] logging from within our implementation
Posted by Alexey Petrenko <al...@gmail.com>.
+1
Logging is useful on development and bugfixing stages. Since not all
the Harmony VMs fully supports JVMDI, JMVPI or JVMTI.
And it will be better to remove all the logging after finishing
development/bugfixing.
2006/5/30, Geir Magnusson Jr <ge...@pobox.com>:
> Just to be clear, I certainly sympathize with Tim and support getting
> rid of implementation debug logging in the long term.
>
> Maybe the way to compromise/phrase it is agree that when a package is
> done, we will pitch all the logging? I can see why having logging
> around while things are being developed is helpful, and committing to
> SVN is ok since we want people to commit "early and often, and having to
> pull out logging would be a disincentive for someone working on
> something big.
>
> Does this help?
>
> "At the end we are going to dump any logging debris that have any
> performance or other burden like increase in dependencies"
>
> geir
>
>
> Geir Magnusson Jr wrote:
> >
> >
> > Tim Ellison wrote:
> >> Geir Magnusson Jr wrote:
> >>> Seems like there is an important issue here, but the discussion can't
> >>> seem to escape out of the thicket of the example.
> >>>
> >>> 1) Should we allow any logging from within the classlibrary?
> >>
> >> Just in case there was any doubt from my earlier postings...
> >>
> >> I think we should not be explicitly logging debug info as part of our
> >> class library implementation.
> >
> > In any form?
> >
> >>> 2) How should we do it?
> >>>
> >>> There are a bunch of ways for the second question... using j.u.l, using
> >>> IOC and injecting our own logging target to reduce dependencies and
> >>> make people think before logging, using aspects?
> >>
> >> Both j.u.l and IoC would require code in the implementation to perform
> >> the logging actions (or check the guard). Putting this logic throughout
> >> the class library will IMHO result in module coupling, code bloat and
> >> overall performance degradation (or no logging!).
> >
> > Right - that's why I was thinking of the latter. Something that would
> > have no runtime overhead, yet allow us to capture more information other
> > than just execution path and stack values :)
> >>
> >> Adding logging statements is expecting the class library developer to
> >> decide /a priori/ what debug|trace info is useful to the person trying
> >> to resolve a problem. Existing debug|trace tools work with the runtime
> >> to figure out the pertinent information as you are interested in it.
> >> (The only caveat being 'flight data recorder' type trace where the trace
> >> points are typically very low overhead and always on).
> >>
> >>> Comments? We probably should try to get to a conclusion in general...
> >>
> >> The logging info being proposed is developer-oriented. I hope that
> >> people are not expecting our users to understand our developer trace
> >> info -- we, as developers, have better tools than printf to figure out
> >> what is happening.
> >
> > I have to admit that I don't agree w/ "better" as a universally general
> > statement, as debug statements can include information provided by the
> > developer not immediately obvious.
> >
> > Is there some kind of aspect framework we can use? Then for
> > develeopers, they have to implicitly do something to get the stuff to
> > come out, it's not a runtime cost for anyone else, and the stuff stays
> > in the codebase for use later?
> >
> > geir
> >
> > ---------------------------------------------------------------------
> > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
--
Alexey A. Petrenko
Intel Middleware Products Division
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib] logging from within our implementation
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Just to be clear, I certainly sympathize with Tim and support getting
rid of implementation debug logging in the long term.
Maybe the way to compromise/phrase it is agree that when a package is
done, we will pitch all the logging? I can see why having logging
around while things are being developed is helpful, and committing to
SVN is ok since we want people to commit "early and often, and having to
pull out logging would be a disincentive for someone working on
something big.
Does this help?
"At the end we are going to dump any logging debris that have any
performance or other burden like increase in dependencies"
geir
Geir Magnusson Jr wrote:
>
>
> Tim Ellison wrote:
>> Geir Magnusson Jr wrote:
>>> Seems like there is an important issue here, but the discussion can't
>>> seem to escape out of the thicket of the example.
>>>
>>> 1) Should we allow any logging from within the classlibrary?
>>
>> Just in case there was any doubt from my earlier postings...
>>
>> I think we should not be explicitly logging debug info as part of our
>> class library implementation.
>
> In any form?
>
>>> 2) How should we do it?
>>>
>>> There are a bunch of ways for the second question... using j.u.l, using
>>> IOC and injecting our own logging target to reduce dependencies and
>>> make people think before logging, using aspects?
>>
>> Both j.u.l and IoC would require code in the implementation to perform
>> the logging actions (or check the guard). Putting this logic throughout
>> the class library will IMHO result in module coupling, code bloat and
>> overall performance degradation (or no logging!).
>
> Right - that's why I was thinking of the latter. Something that would
> have no runtime overhead, yet allow us to capture more information other
> than just execution path and stack values :)
>>
>> Adding logging statements is expecting the class library developer to
>> decide /a priori/ what debug|trace info is useful to the person trying
>> to resolve a problem. Existing debug|trace tools work with the runtime
>> to figure out the pertinent information as you are interested in it.
>> (The only caveat being 'flight data recorder' type trace where the trace
>> points are typically very low overhead and always on).
>>
>>> Comments? We probably should try to get to a conclusion in general...
>>
>> The logging info being proposed is developer-oriented. I hope that
>> people are not expecting our users to understand our developer trace
>> info -- we, as developers, have better tools than printf to figure out
>> what is happening.
>
> I have to admit that I don't agree w/ "better" as a universally general
> statement, as debug statements can include information provided by the
> developer not immediately obvious.
>
> Is there some kind of aspect framework we can use? Then for
> develeopers, they have to implicitly do something to get the stuff to
> come out, it's not a runtime cost for anyone else, and the stuff stays
> in the codebase for use later?
>
> geir
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib] logging from within our implementation
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Tim Ellison wrote:
> Geir Magnusson Jr wrote:
>> Seems like there is an important issue here, but the discussion can't
>> seem to escape out of the thicket of the example.
>>
>> 1) Should we allow any logging from within the classlibrary?
>
> Just in case there was any doubt from my earlier postings...
>
> I think we should not be explicitly logging debug info as part of our
> class library implementation.
In any form?
>> 2) How should we do it?
>>
>> There are a bunch of ways for the second question... using j.u.l, using
>> IOC and injecting our own logging target to reduce dependencies and
>> make people think before logging, using aspects?
>
> Both j.u.l and IoC would require code in the implementation to perform
> the logging actions (or check the guard). Putting this logic throughout
> the class library will IMHO result in module coupling, code bloat and
> overall performance degradation (or no logging!).
Right - that's why I was thinking of the latter. Something that would
have no runtime overhead, yet allow us to capture more information other
than just execution path and stack values :)
>
> Adding logging statements is expecting the class library developer to
> decide /a priori/ what debug|trace info is useful to the person trying
> to resolve a problem. Existing debug|trace tools work with the runtime
> to figure out the pertinent information as you are interested in it.
> (The only caveat being 'flight data recorder' type trace where the trace
> points are typically very low overhead and always on).
>
>> Comments? We probably should try to get to a conclusion in general...
>
> The logging info being proposed is developer-oriented. I hope that
> people are not expecting our users to understand our developer trace
> info -- we, as developers, have better tools than printf to figure out
> what is happening.
I have to admit that I don't agree w/ "better" as a universally general
statement, as debug statements can include information provided by the
developer not immediately obvious.
Is there some kind of aspect framework we can use? Then for
develeopers, they have to implicitly do something to get the stuff to
come out, it's not a runtime cost for anyone else, and the stuff stays
in the codebase for use later?
geir
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [classlib] logging from within our implementation
Posted by Tim Ellison <t....@gmail.com>.
Geir Magnusson Jr wrote:
> Seems like there is an important issue here, but the discussion can't
> seem to escape out of the thicket of the example.
>
> 1) Should we allow any logging from within the classlibrary?
Just in case there was any doubt from my earlier postings...
I think we should not be explicitly logging debug info as part of our
class library implementation.
> 2) How should we do it?
>
> There are a bunch of ways for the second question... using j.u.l, using
> IOC and injecting our own logging target to reduce dependencies and
> make people think before logging, using aspects?
Both j.u.l and IoC would require code in the implementation to perform
the logging actions (or check the guard). Putting this logic throughout
the class library will IMHO result in module coupling, code bloat and
overall performance degradation (or no logging!).
Adding logging statements is expecting the class library developer to
decide /a priori/ what debug|trace info is useful to the person trying
to resolve a problem. Existing debug|trace tools work with the runtime
to figure out the pertinent information as you are interested in it.
(The only caveat being 'flight data recorder' type trace where the trace
points are typically very low overhead and always on).
> Comments? We probably should try to get to a conclusion in general...
The logging info being proposed is developer-oriented. I hope that
people are not expecting our users to understand our developer trace
info -- we, as developers, have better tools than printf to figure out
what is happening.
Regards,
Tim
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org