Re: [classlib] logging from within our implementation
> 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 <[EMAIL PROTECTED]>: 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] logging from within our implementation
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 <[EMAIL PROTECTED]>: 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" <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>: > > 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 <[EMAIL PROTECTED]>: > > >> > > >> > > >> 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: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > Alexei Zakharov, > Intel Middleware Product Division > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -
Re: [classlib] logging from within our implementation
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] logging from within our implementation
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 ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [offlist] Re: [classlib] logging from within our implementation
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) 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] logging from within our implementation
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" <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>: > > 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 <[EMAIL PROTECTED]>: > > >> > > >> > > >> 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: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > Alexei Zakharov, > Intel Middleware Product Division > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] logging from within our implementation
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 <[EMAIL PROTECTED]>: >> 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 <[EMAIL PROTECTED]>: >> >> >> >> >> >> 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: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] logging from within our implementation
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 <[EMAIL PROTECTED]>: 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 <[EMAIL PROTECTED]>: >> >> >> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Alexei Zakharov, Intel Middleware Product Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] logging from within our implementation
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 <[EMAIL PROTECTED]>: >> >> >> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] logging from within our implementation
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 <[EMAIL PROTECTED]>: 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] logging from within our implementation
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: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] logging from within our implementation
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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [offlist] Re: [classlib] logging from within our implementation
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: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [offlist] Re: [classlib] logging from within our implementation
[Eek! ok so you can see that wasn't intended to go onto the list] Apologies for embarrassing George (... but buy the book anyway) 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: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[offlist] Re: [classlib] logging from within our implementation
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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] logging from within our implementation
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 <[EMAIL PROTECTED]>:
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 <[EMAIL PROTECTED]>:
>>>
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 <[EMAIL PROTECTED]>:
>
>> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] logging from within our implementation
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 <[EMAIL PROTECTED]>:
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 <[EMAIL PROTECTED]>:
>> 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 <[EMAIL PROTECTED]>:
>> >>> 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 <[EMAIL PROTECTED]>:
>> >>> >> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] logging from within our implementation
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 <[EMAIL PROTECTED]>:
>> 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 <[EMAIL PROTECTED]>:
>> >>> 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 <[EMAIL PROTECTED]>:
>> >>> >> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] logging from within our implementation
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 <[EMAIL PROTECTED]>:
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 <[EMAIL PROTECTED]>:
>>> 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 <[EMAIL PROTECTED]>:
>>> >> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] logging from within our implementation
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 <[EMAIL PROTECTED]>:
> 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 <[EMAIL PROTECTED]>:
>>
>>> 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: [EMAIL PROTECTED]
>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>
>>>
>>>
>>
>> -
>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>>
>
>
> -
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] logging from within our implementation
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 <[EMAIL PROTECTED]>:
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 <[EMAIL PROTECTED]>:
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] logging from within our implementation
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 <[EMAIL PROTECTED]>:
>>> 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 <[EMAIL PROTECTED]>:
>>> >> 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: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] logging from within our implementation
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 <[EMAIL PROTECTED]>:
>> 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 <[EMAIL PROTECTED]>:
>> >> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] logging from within our implementation
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 <[EMAIL PROTECTED]>:
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 <[EMAIL PROTECTED]>:
>> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] logging from within our implementation
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 <[EMAIL PROTECTED]>:
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 <[EMAIL PROTECTED]>:
>> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] logging from within our implementation
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 <[EMAIL PROTECTED]>:
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] logging from within our implementation
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] logging from within our implementation
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] logging from within our implementation
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] logging from within our implementation
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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] logging from within our implementation
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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] logging from within our implementation
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 <[EMAIL PROTECTED]>: 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] logging from within our implementation
Hi Soeren,
2006/6/1, Soeren Strassfeld <[EMAIL PROTECTED]>:
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] logging from within our implementation
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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] logging from within our implementation
On 5/30/06, Gregory Shimansky <[EMAIL PROTECTED]> 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
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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] logging from within our implementation
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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] logging from within our implementation
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] logging from within our implementation
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] logging from within our implementation
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] logging from within our implementation
On 31/05/06, Chris Gray <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] logging from within our implementation
On Tuesday 30 May 2006 23:38, Alex Blewitt wrote:
> On 30/05/06, Chris Gray <[EMAIL PROTECTED]> 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, OSGihttp://www.k-embedded-java.com/
[EMAIL PROTECTED] +32 3 216 0369
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] logging from within our implementation
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 <[EMAIL PROTECTED]>: 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [classlib] logging from within our implementation
"At the end we are going to dump any logging debris that have any performance or other burden like increase in dependencies" It's Open Source. There's no "end". The bugs will continue to get found, and new features and optimizations will appear from time to time. And putting them in would require checking and debugging, and good logging will help at these stages too. 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. Vasily -Original Message- From: Geir Magnusson Jr [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 30, 2006 10:59 PM To: harmony-dev@incubator.apache.org Subject: Re: [classlib] logging from within our implementation 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] logging from within our implementation
On 30/05/06, Chris Gray <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] logging from within our implementation
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, OSGihttp://www.k-embedded-java.com/ [EMAIL PROTECTED] +32 3 216 0369 - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] logging from within our implementation
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] logging from within our implementation
2006/5/31, Gregory Shimansky <[EMAIL PROTECTED]>:
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] logging from within our implementation
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] logging from within our implementation
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 <[EMAIL PROTECTED]>: 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] logging from within our implementation
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 <[EMAIL PROTECTED]>: +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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] logging from within our implementation
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] logging from within our implementation
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] logging from within our implementation
+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 <[EMAIL PROTECTED]>: 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Alexey A. Petrenko Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] logging from within our implementation
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] logging from within our implementation
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 ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] logging from within our implementation
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] logging from within our implementation
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 ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
