harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <g...@pobox.com>
Subject [classlib] Preprocessor (was Re: [classlib][rmi] Code smell - Thread.sleep() in ActivationGroup method)
Date Sun, 29 Oct 2006 13:04:55 GMT

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?


Mikhail Loenko wrote:
> 2006/10/29, Nathan Beyer <nbeyer@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

View raw message