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)
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
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 clear that
Mikhail Fursov wrote:
On 10/31/06, *Geir Magnusson Jr.* [EMAIL PROTECTED]
mailto:[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
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 suspended
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
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
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
-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:
1) The Logging Debate That Won't Die - we don't want to encumber our
:[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 10/29/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
1
] 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
-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 ActivationGroup method)
Alexei Zakharov wrote:
Hi all
-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] Code
smell -
Thread.sleep() in ActivationGroup method)
On 10/29/06
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 require
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
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 to
Mikhail Fursov wrote:
On 10/29/06, *Geir Magnusson Jr.* [EMAIL PROTECTED]
mailto:[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
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
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
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
20 matches
Mail list logo
