You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by "Geir Magnusson Jr." <ge...@pobox.com> on 2006/10/29 14:04:55 UTC
[classlib] Preprocessor (was Re: [classlib][rmi] Code smell - Thread.sleep()
in ActivationGroup method)
Can we discuss using a preprocessor?
We have a couple of good reasons to consider it :
1) The Logging Debate That Won't Die - we don't want to encumber our
"production" code with logging or even with runtime enablement checks
for logging i.e.
if (logging.isDebugEnabled())
but it's clear that some people still want to use it for debugging.
2) Java 6 - at some point, we're going to get started on changes to the
classlib that are for Java 6, and I think it's clear we want to stay in
the same code tree.
3) Java ME - We've had some interest (Chris?) in looking at using the
Harmony classlib for ME, which can also have some differences that might
be most conveniently kept in place in the main codebase.
If we did this, I assume that our build becomes a two step process,
first pre-process the code to create separate "buildable source", which
would go into source jars and such for debugging purposes. Then our
current javac/jar process.
I'd also like to be able to work in an IDE with the pre-proc stuff
invisible if possible...
First, anyone think this is a good idea and second, anyone have any
experience with tools in this area?
geir
Mikhail Loenko wrote:
> 2006/10/29, Nathan Beyer <nb...@gmail.com>:
>> I found this bit of code in the java.rmi.activation.ActivationGroup. I
>> snipped the calls to the RMI logger, for a bit more clarity.
>>
>> protected void activeObject(ActivationID id, MarshalledObject mobj)
>> throws ActivationException, UnknownObjectException,
>> RemoteException {
>> try {
>> Thread.sleep(500);
>> } catch (Throwable t) {
>> }
>> // ...
>> monitor.activeObject(id, mobj);
>> // ...
>> }
>>
>> Fighting my instincts, I checked the javadoc for this method and it
>> doesn't say anything about putting the current thread to sleep for
>> one-half of a second, so I'm pretty sure this is a hack of some sort.
>> Anyone have any thoughts about why this is needed? The tests run fine
>> with out this extraneous sleep.
>>
>> BTW - There is a LOT of logging in the RMI module; can we blow this
>> stuff away?
>
> Can we do it later? It's easier to remove then to add and we can
> wait until our VM has those nice features that Tim referred to.
> Meanwhile we could fix the bugs found by our users.
>
> Thanks,
> Mikhail
>
>>
>> -Nathan
>>
>
Re: [classlib] Preprocessor (was Re: [classlib][rmi] Code smell - Thread.sleep() in ActivationGroup method)
Posted by Mikhail Fursov <mi...@gmail.com>.
On 10/30/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>
>
> > 1) The Logging Debate That Won't Die - we don't want to encumber our
> > "production" code with logging or even with runtime enablement
> checks
> > for logging i.e.
> >
> > if (logging.isDebugEnabled())
> >
> > but it's clear that some people still want to use it for debugging.
> >
> >
> > Just a small idea: Let teach JIT to purge this code unless special
> option is ON
> > ? Doing this we solve performance issue at least .
>
> Well, then we have a classlibrary that is only good for use with JIT's
> that have been specially trained to find code that looks like very
> common code for logging implementations.
>
> The results could be hilarious, actually.
More advanced version of the proposal above. I do not say it's ideal but it
solves IDE incompatibility problem of solution with preprocessor.
We can create a special class (Configuration) with final static fields:
public static final boolean isLogEnabled
public static final boolean isJava1_5
public static final boolean isJava1_6
And check these vars in classlib code. Does performance the question? I
think not, we will drop this code during the compilation and this is an easy
task for any JIT.
The only problem is you can't add new methods in a such way. So it's a clean
but not complete solution :(
--
Mikhail Fursov
Re: [classlib] Preprocessor (was Re: [classlib][rmi] Code smell - Thread.sleep() in ActivationGroup method)
Posted by Nathan Beyer <nb...@gmail.com>.
On 10/29/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>
>
> Mikhail Fursov wrote:
> > On 10/29/06, *Geir Magnusson Jr.* <geir@pobox.com
> > <ma...@pobox.com>> wrote:
> >
> >
> > 1) The Logging Debate That Won't Die - we don't want to encumber our
> > "production" code with logging or even with runtime enablement checks
> > for logging i.e.
> >
> > if (logging.isDebugEnabled())
> >
> > but it's clear that some people still want to use it for debugging.
> >
> >
> > Just a small idea: Let teach JIT to purge this code unless special option is ON
> > ? Doing this we solve performance issue at least .
>
> Well, then we have a classlibrary that is only good for use with JIT's
> that have been specially trained to find code that looks like very
> common code for logging implementations.
>
> The results could be hilarious, actually.
This particular use case seems like inserting breadcrumbs for
non-interactive debugging. My preference here would be use AOP via
special compile or just java.lang.instrument transformation.
>
> >
> > If we did this, I assume that our build becomes a two step process,
> > first pre-process the code to create separate "buildable source", which
> > would go into source jars and such for debugging purposes. Then our
> > current javac/jar process.
> >
> > I'd also like to be able to work in an IDE with the pre-proc stuff
> > invisible if possible...
> >
> >
> > This is the main problem. Backporting of
> > your changes from the "buildable source" to the "source with
> > preprocessor" could have more overhead then support of a separate branch
> > for different Java version.
>
> No - you'd edit the original source directly - you wouldn't edit the
> pre-processed source.
>
> But a plugin would let you flip between original and processed...
>
> geir
Could some of this be done via annotations and a specialized
annotations processor? Annotations could be utilized along with a
java.lang.instrument transformer tool. A JIT could also look for
annotations in class files and add special behavior, but the classlib
would be runnable without these behaviors.
Harmony will need some form of an APT eventually and annotations
wouldn't require specialized IDE plugins.
-Nathan
>
> >
> >
> >
> >
> > --
> > Mikhail Fursov
>
Re: [classlib] Preprocessor (was Re: [classlib][rmi] Code smell -
Thread.sleep() in ActivationGroup method)
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Mikhail Fursov wrote:
> On 10/29/06, *Geir Magnusson Jr.* <geir@pobox.com
> <ma...@pobox.com>> wrote:
>
>
> 1) The Logging Debate That Won't Die - we don't want to encumber our
> "production" code with logging or even with runtime enablement checks
> for logging i.e.
>
> if (logging.isDebugEnabled())
>
> but it's clear that some people still want to use it for debugging.
>
>
> Just a small idea: Let teach JIT to purge this code unless special option is ON
> ? Doing this we solve performance issue at least .
Well, then we have a classlibrary that is only good for use with JIT's
that have been specially trained to find code that looks like very
common code for logging implementations.
The results could be hilarious, actually.
>
> If we did this, I assume that our build becomes a two step process,
> first pre-process the code to create separate "buildable source", which
> would go into source jars and such for debugging purposes. Then our
> current javac/jar process.
>
> I'd also like to be able to work in an IDE with the pre-proc stuff
> invisible if possible...
>
>
> This is the main problem. Backporting of
> your changes from the "buildable source" to the "source with
> preprocessor" could have more overhead then support of a separate branch
> for different Java version.
No - you'd edit the original source directly - you wouldn't edit the
pre-processed source.
But a plugin would let you flip between original and processed...
geir
>
>
>
>
> --
> Mikhail Fursov
Re: [classlib] Preprocessor (was Re: [classlib][rmi] Code smell - Thread.sleep() in ActivationGroup method)
Posted by Mikhail Fursov <mi...@gmail.com>.
On 10/29/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>
>
> 1) The Logging Debate That Won't Die - we don't want to encumber our
> "production" code with logging or even with runtime enablement checks
> for logging i.e.
>
> if (logging.isDebugEnabled())
>
> but it's clear that some people still want to use it for debugging.
Just a small idea: Let teach JIT to purge this code unless special option is ON
? Doing this we solve performance issue at least .
If we did this, I assume that our build becomes a two step process,
> first pre-process the code to create separate "buildable source", which
> would go into source jars and such for debugging purposes. Then our
> current javac/jar process.
>
> I'd also like to be able to work in an IDE with the pre-proc stuff
> invisible if possible...
This is the main problem. Backporting of your changes from the "buildable
source" to the "source with preprocessor" could have more overhead then
support of a separate branch for different Java version.
--
Mikhail Fursov
Re: [classlib] Preprocessor
Posted by Tim Ellison <t....@gmail.com>.
Geir Magnusson Jr. wrote:
> Tim Ellison wrote:
>> Where you do go through a source-to-source transform stage it helps of
>> you can collaborate with the second-stage compiler to pass through
>> original line number info (a la JSR45) otherwise debugging gets a bit
>> tiresome.
>
> Right, except I could imagine having an IDE plugin that deals with this
> for you - you edit and debug using the processed code, which is what the
> line numbers will correspond to...
:-) of course, when I say "you" I mean the tooling not the developer.
Regards,
Tim
--
Tim Ellison (t.p.ellison@gmail.com)
Re: [classlib] Preprocessor
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Tim Ellison wrote:
> Etienne Gagnon wrote:
>>> Chris Gray wrote:
>>>> For JavaME I think it's the only way we'd be able to maintain a single
>>>> source tree. We need to be able to "#ifdef out" references to classes
>>>> we don't have, methods we don't implement, etc..
>>>>
>>>> That much being said, I don't have a recommendation for a tool to use.
>>>> Java syntax is sufficiently C-like that cpp is probably do-able, but
>>>> we'd probably stumble over a whole series of gotcha's, and cpp isn't
>>>> exactly [deity]'s gift to preprocessing anyway. Maybe one of the
>>>> aspect-oriented tools (with which I am not at all familiar) could be a
>>>> better bet?
>> You could always do "clean" source-to-source processing using
>> SableCC...:-) Java is a nice language to parse, so you could do some
>> clean parsing, instead of the dumb "unstructured text" replacement of
>> preprocessors.
>>
>> Actually, if all you need if "ifdef'ing out" undesirable references, it
>> could be done by "hiding" modification directives in structured
>> comments, so that these comment remain "javac" invisible. This way you
>> could make it such that:
>> 1- Plain source compilation -> j2se .
>> 2- Structured processed source compilation -> j2me .
>
> I agree, ensuring that the original source remains compilable can be a
> great benefit.
>
> Besides in-lining #ifdef's you can also maintain look-aside files with a
> description of the smaller configurations. That helps to avoid code
> clutter though of course you may prefer to be marking-up the code
> in-line if it is not simply removing whole types/methods.
Yes.
>
> The other thing to remember is that methods that appear in the smaller
> configurations must only be implemented in terms of methods that appear
> in the smaller configurations. For example, you may have to rewrite
> regular IO to not be implemented in terms of NIO so that it remains
> viable in configurations that don't have NIO. In Harmony we have a
> common 'platform IO layer' used for both modules.
>
> Where you do go through a source-to-source transform stage it helps of
> you can collaborate with the second-stage compiler to pass through
> original line number info (a la JSR45) otherwise debugging gets a bit
> tiresome.
Right, except I could imagine having an IDE plugin that deals with this
for you - you edit and debug using the processed code, which is what the
line numbers will correspond to...
>
> Regards,
> Tim
>
>> If you need it, there are 2 or 3 Java 1.5 grammars available for SableCC
>> (different parsing approaches, not different syntax!). As I said, Java
>> is a pleasure to parse when compared to C & C++.
>>
>> It's just an idea, of course... [I know that people can start religious
>> wars about pre-processing; that's why I am suggesting a clean approach,
>> so that j2se people don't have to pre-process].
>>
>> Etienne
>>
>
Re: [classlib] Preprocessor
Posted by Tim Ellison <t....@gmail.com>.
Etienne Gagnon wrote:
>> Chris Gray wrote:
>>> For JavaME I think it's the only way we'd be able to maintain a single
>>> source tree. We need to be able to "#ifdef out" references to classes
>>> we don't have, methods we don't implement, etc..
>>>
>>> That much being said, I don't have a recommendation for a tool to use.
>>> Java syntax is sufficiently C-like that cpp is probably do-able, but
>>> we'd probably stumble over a whole series of gotcha's, and cpp isn't
>>> exactly [deity]'s gift to preprocessing anyway. Maybe one of the
>>> aspect-oriented tools (with which I am not at all familiar) could be a
>>> better bet?
>
> You could always do "clean" source-to-source processing using
> SableCC...:-) Java is a nice language to parse, so you could do some
> clean parsing, instead of the dumb "unstructured text" replacement of
> preprocessors.
>
> Actually, if all you need if "ifdef'ing out" undesirable references, it
> could be done by "hiding" modification directives in structured
> comments, so that these comment remain "javac" invisible. This way you
> could make it such that:
> 1- Plain source compilation -> j2se .
> 2- Structured processed source compilation -> j2me .
I agree, ensuring that the original source remains compilable can be a
great benefit.
Besides in-lining #ifdef's you can also maintain look-aside files with a
description of the smaller configurations. That helps to avoid code
clutter though of course you may prefer to be marking-up the code
in-line if it is not simply removing whole types/methods.
The other thing to remember is that methods that appear in the smaller
configurations must only be implemented in terms of methods that appear
in the smaller configurations. For example, you may have to rewrite
regular IO to not be implemented in terms of NIO so that it remains
viable in configurations that don't have NIO. In Harmony we have a
common 'platform IO layer' used for both modules.
Where you do go through a source-to-source transform stage it helps of
you can collaborate with the second-stage compiler to pass through
original line number info (a la JSR45) otherwise debugging gets a bit
tiresome.
Regards,
Tim
> If you need it, there are 2 or 3 Java 1.5 grammars available for SableCC
> (different parsing approaches, not different syntax!). As I said, Java
> is a pleasure to parse when compared to C & C++.
>
> It's just an idea, of course... [I know that people can start religious
> wars about pre-processing; that's why I am suggesting a clean approach,
> so that j2se people don't have to pre-process].
>
> Etienne
>
--
Tim Ellison (t.p.ellison@gmail.com)
Re: [classlib] Preprocessor (was Re: [classlib][rmi] Code smell -
Thread.sleep() in ActivationGroup method)
Posted by Etienne Gagnon <eg...@sablevm.org>.
> Chris Gray wrote:
>> For JavaME I think it's the only way we'd be able to maintain a single
>> source tree. We need to be able to "#ifdef out" references to classes
>> we don't have, methods we don't implement, etc..
>>
>> That much being said, I don't have a recommendation for a tool to use.
>> Java syntax is sufficiently C-like that cpp is probably do-able, but
>> we'd probably stumble over a whole series of gotcha's, and cpp isn't
>> exactly [deity]'s gift to preprocessing anyway. Maybe one of the
>> aspect-oriented tools (with which I am not at all familiar) could be a
>> better bet?
You could always do "clean" source-to-source processing using
SableCC...:-) Java is a nice language to parse, so you could do some
clean parsing, instead of the dumb "unstructured text" replacement of
preprocessors.
Actually, if all you need if "ifdef'ing out" undesirable references, it
could be done by "hiding" modification directives in structured
comments, so that these comment remain "javac" invisible. This way you
could make it such that:
1- Plain source compilation -> j2se .
2- Structured processed source compilation -> j2me .
If you need it, there are 2 or 3 Java 1.5 grammars available for SableCC
(different parsing approaches, not different syntax!). As I said, Java
is a pleasure to parse when compared to C & C++.
It's just an idea, of course... [I know that people can start religious
wars about pre-processing; that's why I am suggesting a clean approach,
so that j2se people don't have to pre-process].
Etienne
--
Etienne M. Gagnon, Ph.D. http://www.info2.uqam.ca/~egagnon/
SableVM: http://www.sablevm.org/
SableCC: http://www.sablecc.org/
Re: [classlib] Preprocessor (was Re: [classlib][rmi] Code smell - Thread.sleep() in ActivationGroup method)
Posted by Sian January <si...@googlemail.com>.
Yes - I know AspectJ works on the bytecode and not as a pre-processor to the
source code and I don't think any other AO languages do that either.
Although I'm an advocate for AOP I think we would want to think seriously
before introducing a dependency on a non-javac compiler to Harmony. However
it would be good for logging, and it's worth noting that AspectJ 5 can
also match based on annotations, which makes it possible to achieve quite
fine-grained logging without cluttering up the source too much with "if (
logging.isDebugEnabled())" etc.
Thanks,
Sian
On 30/10/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>
>
>
> Chris Gray wrote:
> > On Sunday 29 October 2006 14:04, Geir Magnusson Jr. wrote:
> >> [...]
> >> 3) Java ME - We've had some interest (Chris?) in looking at using the
> >> Harmony classlib for ME, which can also have some differences that
> might
> >> be most conveniently kept in place in the main codebase.
> >
> > Yes, I'm still here and still waiting for an answer to my last mail
> about
> > bringing Mika to the incubator ...
>
> I thought you were off trying to figure out IP provenance.
>
> >
> >> [...]
> >> First, anyone think this is a good idea and second, anyone have any
> >> experience with tools in this area?
> >
> > For JavaME I think it's the only way we'd be able to maintain a single
> source
> > tree. We need to be able to "#ifdef out" references to classes we don't
> have,
> > methods we don't implement, etc..
> >
> > That much being said, I don't have a recommendation for a tool to use.
> Java
> > syntax is sufficiently C-like that cpp is probably do-able, but we'd
> probably
> > stumble over a whole series of gotcha's, and cpp isn't exactly [deity]'s
> gift
> > to preprocessing anyway. Maybe one of the aspect-oriented tools (with
> which I
> > am not at all familiar) could be a better bet?
>
> How? Doesn't that tend to work on the bytecode? I know that I'd be
> uncomfortable with anything where there wasn't a clear source tree
> produced.
>
> geir
>
>
> >
> > Cheers,
> >
> > Chris
> >
>
--
Sian January
IBM Java Technology Centre, UK
Re: [classlib] Preprocessor (was Re: [classlib][rmi] Code smell -
Thread.sleep() in ActivationGroup method)
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Chris Gray wrote:
> On Sunday 29 October 2006 14:04, Geir Magnusson Jr. wrote:
>> [...]
>> 3) Java ME - We've had some interest (Chris?) in looking at using the
>> Harmony classlib for ME, which can also have some differences that might
>> be most conveniently kept in place in the main codebase.
>
> Yes, I'm still here and still waiting for an answer to my last mail about
> bringing Mika to the incubator ...
I thought you were off trying to figure out IP provenance.
>
>> [...]
>> First, anyone think this is a good idea and second, anyone have any
>> experience with tools in this area?
>
> For JavaME I think it's the only way we'd be able to maintain a single source
> tree. We need to be able to "#ifdef out" references to classes we don't have,
> methods we don't implement, etc..
>
> That much being said, I don't have a recommendation for a tool to use. Java
> syntax is sufficiently C-like that cpp is probably do-able, but we'd probably
> stumble over a whole series of gotcha's, and cpp isn't exactly [deity]'s gift
> to preprocessing anyway. Maybe one of the aspect-oriented tools (with which I
> am not at all familiar) could be a better bet?
How? Doesn't that tend to work on the bytecode? I know that I'd be
uncomfortable with anything where there wasn't a clear source tree produced.
geir
>
> Cheers,
>
> Chris
>
Re: [classlib] Preprocessor (was Re: [classlib][rmi] Code smell - Thread.sleep() in ActivationGroup method)
Posted by Chris Gray <ch...@kiffer.be>.
On Sunday 29 October 2006 14:04, Geir Magnusson Jr. wrote:
> [...]
> 3) Java ME - We've had some interest (Chris?) in looking at using the
> Harmony classlib for ME, which can also have some differences that might
> be most conveniently kept in place in the main codebase.
Yes, I'm still here and still waiting for an answer to my last mail about
bringing Mika to the incubator ...
> [...]
> First, anyone think this is a good idea and second, anyone have any
> experience with tools in this area?
For JavaME I think it's the only way we'd be able to maintain a single source
tree. We need to be able to "#ifdef out" references to classes we don't have,
methods we don't implement, etc..
That much being said, I don't have a recommendation for a tool to use. Java
syntax is sufficiently C-like that cpp is probably do-able, but we'd probably
stumble over a whole series of gotcha's, and cpp isn't exactly [deity]'s gift
to preprocessing anyway. Maybe one of the aspect-oriented tools (with which I
am not at all familiar) could be a better bet?
Cheers,
Chris
--
Chris Gray /k/ Embedded Java Solutions BE0503765045
Embedded & Mobile Java, OSGi http://www.k-embedded-java.com/
chris.gray@kiffer.be +32 3 216 0369