Re: [classlib] Preprocessor (was Re: [classlib][rmi] Code smell - Thread.sleep() in ActivationGroup method)

Nathan Beyer wrote: I don't know too much about ME profiles, but my opinion would be to start by treating the target platform as a full Java SE port and then look to add optional ME modules to the classlib. For example, port DRLVM to Windows Mobile on Xscale or ARM. Good lord man, bite your t

Re: [classlib] Preprocessor (was Re: [classlib][rmi] Code smell - Thread.sleep() in ActivationGroup method)

I don't know too much about ME profiles, but my opinion would be to start by treating the target platform as a full Java SE port and then look to add optional ME modules to the classlib. For example, port DRLVM to Windows Mobile on Xscale or ARM. I've worked a little bit with IBM's WebSphere Micr

Re: [classlib] Preprocessor (was Re: [classlib][rmi] Code smell - Thread.sleep() in ActivationGroup method)

Mikhail Fursov wrote: > On 10/31/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: >> I guess that if we could get 5.0 complete, we'd could *then* branch for >> 6, but I don't think we'd want to serialize like that. > > I understand the dilemma. If we agree to have 1 stable, 1 'future' > and N sus

Re: [classlib] Preprocessor (was Re: [classlib][rmi] Code smell - Thread.sleep() in ActivationGroup method)

Mikhail Fursov wrote: On 10/31/06, *Geir Magnusson Jr.* <[EMAIL PROTECTED] > wrote: I guess that if we could get 5.0 complete, we'd could *then* branch for 6, but I don't think we'd want to serialize like that. I understand the dilemma. If we agree to h

Re: [classlib] Preprocessor (was Re: [classlib][rmi] Code smell - Thread.sleep() in ActivationGroup method)

On 10/30/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> 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 c

Re: [classlib] Preprocessor (was Re: [classlib][rmi] Code smell - Thread.sleep() in ActivationGroup method)

On 10/31/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: I guess that if we could get 5.0 complete, we'd could *then* branch for 6, but I don't think we'd want to serialize like that. I understand the dilemma. If we agree to have 1 stable, 1 'future' and N suspended (old) branches as a rul

Re: [classlib] Preprocessor (was Re: [classlib][rmi] Code smell - Thread.sleep() in ActivationGroup method)

Mikhail Fursov wrote: Geir, What are the reasons to exclude the most standard solution here: branching. Do you think we need a lot of them? Because I'm not sure how you can easily maintain fixes and general coherence across branches. Also, there are 3 use cases for pre-processor, and it s

Re: [classlib] Preprocessor (was Re: [classlib][rmi] Code smell - Thread.sleep() in ActivationGroup method)

Geir, What are the reasons to exclude the most standard solution here: branching. Do you think we need a lot of them? I see the following advantages to work in branches for different products: 1) Clean code 2) No side effects (no testing!) for other branches when you modify only one branch 3) Eve

Re: [classlib] Preprocessor (was Re: [classlib][rmi] Code smell - Thread.sleep() in ActivationGroup method)

Tim Ellison wrote: Geir Magnusson Jr. wrote: Alexei Zakharov wrote: At the same time I don't feel completely comfortable with the idea of using preprocessor to separate J2SE sources from J2ME. I'm not overjoyed either, but I can't think of many ways that allow fairly clear readability withou

Re: [classlib] Preprocessor (was Re: [classlib][rmi] Code smell - Thread.sleep() in ActivationGroup method)

Geir Magnusson Jr. wrote: > Alexei Zakharov wrote: >> At the same time I don't feel completely comfortable with the idea >> of using preprocessor to separate J2SE sources from J2ME. > > I'm not overjoyed either, but I can't think of many ways that allow > fairly clear readability without don't req

RE: [classlib] Preprocessor (was Re: [classlib][rmi] Code smell - Thread.sleep() in ActivationGroup method)

> >> >-Original Message- >> >From: Mikhail Fursov [mailto:[EMAIL PROTECTED] >> >Sent: Sunday, October 29, 2006 8:56 PM >> >To: harmony-dev@incubator.apache.org; [EMAIL PROTECTED] >> >Subject: Re: [classlib] Preprocessor (was Re: [classlib][rmi] Co

RE: [classlib] Preprocessor (was Re: [classlib][rmi] Code smell - Thread.sleep() in ActivationGroup method)

XML Engineering >-Original Message- >From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED] >Sent: Monday, October 30, 2006 9:29 PM >To: harmony-dev@incubator.apache.org >Subject: Re: [classlib] Preprocessor (was Re: [classlib][rmi] Code smell - >Thread.sleep() in ActivationGro

Re: [classlib] Preprocessor (was Re: [classlib][rmi] Code smell - Thread.sleep() in ActivationGroup method)

g; [EMAIL PROTECTED] >Subject: Re: [classlib] Preprocessor (was Re: [classlib][rmi] Code smell - >Thread.sleep() in ActivationGroup method) > >On 10/29/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: >> >> >> 1) The Logging Debate That Won't Die - we don't

Re: [classlib] Preprocessor (was Re: [classlib][rmi] Code smell - Thread.sleep() in ActivationGroup method)

Message- >From: Mikhail Fursov [mailto:[EMAIL PROTECTED] >Sent: Sunday, October 29, 2006 8:56 PM >To: harmony-dev@incubator.apache.org; [EMAIL PROTECTED] >Subject: Re: [classlib] Preprocessor (was Re: [classlib][rmi] Code smell - >Thread.sleep() in ActivationGroup method) > >On

RE: [classlib] Preprocessor (was Re: [classlib][rmi] Code smell - Thread.sleep() in ActivationGroup method)

9, 2006 8:56 PM >To: harmony-dev@incubator.apache.org; [EMAIL PROTECTED] >Subject: Re: [classlib] Preprocessor (was Re: [classlib][rmi] Code smell - >Thread.sleep() in ActivationGroup method) > >On 10/29/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: >> >> >&g

Re: [classlib] Preprocessor (was Re: [classlib][rmi] Code smell - Thread.sleep() in ActivationGroup method)

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 i

Re: [classlib] Preprocessor (was Re: [classlib][rmi] Code smell - Thread.sleep() in ActivationGroup method)

> 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. >>

Re: [classlib] Preprocessor (was Re: [classlib][rmi] Code smell - Thread.sleep() in ActivationGroup method)

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

Re: [classlib] Preprocessor (was Re: [classlib][rmi] Code smell - Thread.sleep() in ActivationGroup method)

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 s

Re: [classlib] Preprocessor (was Re: [classlib][rmi] Code smell - Thread.sleep() in ActivationGroup method)

On 10/29/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: Mikhail Fursov wrote: > On 10/29/06, *Geir Magnusson Jr.* <[EMAIL PROTECTED] > > wrote: > > > 1) The Logging Debate That Won't Die - we don't want to encumber our > "production" code with logging or eve

Re: [classlib] Preprocessor (was Re: [classlib][rmi] Code smell - Thread.sleep() in ActivationGroup method)

Mikhail Fursov wrote: On 10/29/06, *Geir Magnusson Jr.* <[EMAIL PROTECTED] > 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

Re: [classlib] Preprocessor (was Re: [classlib][rmi] Code smell - Thread.sleep() in ActivationGroup method)

On 10/29/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> 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