Etienne Gagnon wrote:
Tim Ellison wrote:
I'm inclined to say that we tackle the 1.5/1.6 differences as our
example. Marking-up a module like NIO would be easy enough.
That's what I was hoping for. One concrete example :)
I'm thrilled to see something happen in the sandbox (that's really
Tim Ellison wrote:
I'll wait until you have a simple contrived example working and settled
upon some syntax for mark-up, then I'll help to mark-up some real
example and test the tooling. Let me know when you have something ready
to try.
Yes, I have to figure out some sane syntax for all
Etienne Gagnon wrote:
Tim Ellison wrote:
I'll wait until you have a simple contrived example working and settled
upon some syntax for mark-up, then I'll help to mark-up some real
example and test the tooling. Let me know when you have something ready
to try.
Yes, I have to figure out some
Tim Ellison wrote:
Geir Magnusson Jr. wrote:
Because I can imagine that as a SE programmer, I would want 1 of 2 things :
1) clean code to work on for a specific target (say SE 5)
2) a hybrid version of your dev1 that only has the glop for a subset of
the platforms (say just Java SE 5 and
Tim Ellison wrote:
Etienne Gagnon wrote:
I'm proposing to simply use precise svn url/version identification as
markup:
snip
As long as we are *sure* that the releasetarget code was built from
precisely that url/version (without any local workspace modification)
then it should be as precise
Geir Magnusson Jr. wrote:
Tim Ellison wrote:
There are multiple 'devtarget's -- each contains all the source code
marked-up for every target being developed, but each is distinct by
having different targets uncommented. Since each devtarget contains the
entire source code it is possible to
Tim Ellison wrote:
Geir Magnusson Jr. wrote:
Tim Ellison wrote:
There are multiple 'devtarget's -- each contains all the source code
marked-up for every target being developed, but each is distinct by
having different targets uncommented. Since each devtarget contains the
entire source code
Geir Magnusson Jr. wrote:
[...]
2) Master is virtual, dev1..N are concrete, one dev form is Most Favored
Nation Status so something coherent can be shoved into SVN (Q: is MFNS
necessary? Nice, yes, but necessary?)
I definitely think that it is necessary (where J2SE5 is the preferred
Tim Ellison wrote:
Agreed. It would be interesting to determine the most effective
location for those markers (measured by reverse mapping accuracy vs.
number of markers).
I am a fan of accuracy... Yet, maybe it would be simple enough if a
release was always based on a specific svn URL, then
Etienne Gagnon wrote:
Geir Magnusson Jr. wrote:
[...]
2) Master is virtual, dev1..N are concrete, one dev form is Most Favored
Nation Status so something coherent can be shoved into SVN (Q: is MFNS
necessary? Nice, yes, but necessary?)
I definitely think that it is necessary (where J2SE5 is
Etienne Gagnon wrote:
I'm proposing to simply use precise svn url/version identification as
markup:
snip
As long as we are *sure* that the releasetarget code was built from
precisely that url/version (without any local workspace modification)
then it should be as precise as having markups
Tim Ellison wrote:
Geir Magnusson Jr. wrote:
As fun as this discussion is, it's all theoretical.
There's no harm in a bit of fun :-)
So how about we create a sandbox in SVN and copy over a few types to
mark-up while Etienne is developing the processor, and we can all watch
that evolve?
Geir Magnusson Jr. wrote:
Tim Ellison wrote:
I'm inclined to say that we tackle the 1.5/1.6 differences as our
example. Marking-up a module like NIO would be easy enough.
That's what I was hoping for. One concrete example :)
I'm thrilled to see something happen in the sandbox (that's
Some concreteness would be great :)
2006/11/3, Tim Ellison [EMAIL PROTECTED]:
Geir Magnusson Jr. wrote:
As fun as this discussion is, it's all theoretical.
There's no harm in a bit of fun :-)
So how about we create a sandbox in SVN and copy over a few types to
mark-up while Etienne is
Tim Ellison wrote:
I'm inclined to say that we tackle the 1.5/1.6 differences as our
example. Marking-up a module like NIO would be easy enough.
That's what I was hoping for. One concrete example :)
I'm thrilled to see something happen in the sandbox (that's really the
only way to do it... I'd
I may be totally off track here, but how about just having two copies of all
the files that differ? I don't believe it would be that many, and it would
save us from having complicated source files or having to use special tools
or special IDE plug-ins. For me the value of having clearly
Sian January wrote:
I may be totally off track here, but how about just having two copies
of all the files that differ? I don't believe it would be that many,
and it would save us from having complicated source files or having to
use special tools or special IDE plug-ins. For me the value
I believe that in CVS when you make a branch there's nothing in it to begin
with, so if you check out code from the branch it looks the same as code in
head. Then if a change is made in a file in head and that file hasn't been
changed in the branch that change is reflected in the branch. My
Sian January wrote:
I believe that in CVS when you make a branch there's nothing in it to
begin with, so if you check out code from the branch it looks the same
as code in head. Then if a change is made in a file in head and that
file hasn't been changed in the branch that change is
On 11/2/06, Sian January [EMAIL PROTECTED] wrote:
Just thinking about J2ME, I can imagine that some source files are going
to be very different. For example there are no Java 5 features in J2ME,
so
any generic classes will have to be almost completely different. My
concern
is that trying to
On 02/11/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
Sian January wrote:
I believe that in CVS when you make a branch there's nothing in it to
begin with, so if you check out code from the branch it looks the same
as code in head. Then if a change is made in a file in head and that
Sian January wrote:
On 02/11/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
Sian January wrote:
I believe that in CVS when you make a branch there's nothing in it to
begin with, so if you check out code from the branch it looks the same
as code in head. Then if a change is made in a
Tim Ellison wrote:
For example, if class X of the main version is not part of j2me,
process(j2me) would move this file to a subdirectory .streams/.
Why would you move the files rather than exclude them?
I was assuming that the processor would generate a whole new source tree
for each
Geir Magnusson Jr. wrote:
To release code, one would apply:
process(X, release-target) = Y
Now, it is important to understand that Y, in this case, is NOT suitable
for doing any modification as
revert(Y) = Kaboom! (The tool will simply report that it can't do it;
Geir Magnusson Jr. wrote:
[...]
See, I'm hoping for something a tad different :
1) For building : process() (and revert() for fun) for cmd line use for
the build scripts, so we just do
...
2) For development : IDE plugin where
a) I can tell plugin that my project def/configuration
Sian January wrote:
I may be totally off track here, but how about just having two copies of
all
the files that differ? I don't believe it would be that many, and it would
save us from having complicated source files or having to use special tools
or special IDE plug-ins. For me the value
Etienne Gagnon wrote:
Geir Magnusson Jr. wrote:
[...]
See, I'm hoping for something a tad different :
1) For building : process() (and revert() for fun) for cmd line use for
the build scripts, so we just do
...
2) For development : IDE plugin where
a) I can tell plugin that my
Geir Magnusson Jr. wrote:
I have nothing against this! But, we have to make sure:
1- we don't lose the communication aspect of telling developers about
parrallel development.
I'm not sure I understand what problem you are trying to solve there. We
do parallel development on the source
On 11/3/06, Etienne Gagnon [EMAIL PROTECTED] wrote:
Mikhail Fursov wrote:
Good point! I think Java1.2 classes format is a reason to move J2ME
development into separate branch.
The only usecase for preprocessor is left (correct me if I miss
something)
is Java6 changes.
?
a) This is class
Etienne Gagnon wrote:
[SNIP]
Such changes are usually not dealt with very neatly with svn merge.
I'm confused. I don't think anyone has suggested that we use svn
merge for this.
Now, if using the processign tool, you get at least 2 benefits over svn
merge:
1- No need to do any svn
Geir Magnusson Jr. wrote:
The communication aspect of 2 can be quite helpful when doing
system-wide changes. Just think about the effect of simply doing a
system-wide reindentation of source code; this is a nightmare when
developing using branches, as diff/merge tools are line-based, not
Etienne Gagnon wrote:
Geir Magnusson Jr. wrote:
The communication aspect of 2 can be quite helpful when doing
system-wide changes. Just think about the effect of simply doing a
system-wide reindentation of source code; this is a nightmare when
developing using branches, as diff/merge tools
BTW, I'm more than happy if you just do a quick sketch of what you're
thinking, and we resume the convo from there.
I just wanted to clear up some confusion I had.
geir
Geir Magnusson Jr. wrote:
Etienne Gagnon wrote:
Geir Magnusson Jr. wrote:
The communication aspect of 2 can be quite
Etienne Gagnon wrote:
Tim Ellison wrote:
For example, if class X of the main version is not part of j2me,
process(j2me) would move this file to a subdirectory .streams/.
Why would you move the files rather than exclude them?
I was assuming that the processor would generate a whole new
Etienne Gagnon wrote:
Geir Magnusson Jr. wrote:
To release code, one would apply:
process(X, release-target) = Y
Now, it is important to understand that Y, in this case, is NOT suitable
for doing any modification as
revert(Y) = Kaboom! (The tool will simply report that it can't do it;
Geir Magnusson Jr. wrote:
Etienne Gagnon wrote:
Geir Magnusson Jr. wrote:
The communication aspect of 2 can be quite helpful when doing
system-wide changes. Just think about the effect of simply doing a
system-wide reindentation of source code; this is a nightmare when
developing using
So this has been a long and exciting thread, and it's still not clear
that we understand each other. There are at least two different models
here.
I'll go re-read and try and clarify the difference, and I suppose the
next step for Etienne would be an example of how his approach works. It
Geir Magnusson Jr. wrote:
Nathan Beyer wrote:
What's the concern about just using the prescribed branching pattern
for SVN? There are some other nice tricks like externals for pulling
in common files into the working copies of other branches (ala the
'concurrent' code in 'standard' that's
Etienne Gagnon wrote:
Tim Ellison wrote:
IMO it's not ideal that the preprocessed source still contains all the
streams, albeit in comments. It wouldn't make the source very
'consumable' to the Mrs. SE or ME developer.
Hmmm... It's always possible to have a special output mode that puts
Tim Ellison wrote:
Geir Magnusson Jr. wrote:
Nathan Beyer wrote:
What's the concern about just using the prescribed branching pattern
for SVN? There are some other nice tricks like externals for pulling
in common files into the working copies of other branches (ala the
'concurrent' code in
Message-
From: Nathan Beyer [mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 01, 2006 4:06 AM
To: harmony-dev@incubator.apache.org
Subject: Re: [classlib] Preprocessor - CHECKPOINT
What's the concern about just using the prescribed branching pattern
for SVN? There are some other nice tricks
To: harmony-dev@incubator.apache.org
Subject: Re: [classlib] Preprocessor - CHECKPOINT
Tim Ellison wrote:
IMO it's not ideal that the preprocessed source still contains all
the
streams, albeit in comments. It wouldn't make the source very
'consumable' to the Mrs. SE or ME developer.
Hmmm
.
With best regards,
Alexei Fedotov,
Intel Java XML Engineering
-Original Message-
From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 01, 2006 4:39 AM
To: harmony-dev@incubator.apache.org
Subject: Re: [classlib] Preprocessor - CHECKPOINT
Etienne Gagnon wrote
Geir Magnusson Jr. wrote:
There's caching too, I think. LogCache4J
What I meant was that it didn't seem like we came to a conclusion on it
- that if we had a general pre-processing solution, we could use that
too for logging, rather than have two.
The actual use-cases will help figure
On 11/1/06, Etienne Gagnon [EMAIL PROTECTED] wrote:
Problem
---
supporting a different API specifications/versions, such as j2me and
j2se1.4, in addition to the main version (e.g. j2se1.5)
Solution
This is a trickier problem. We can divide the problem at two main levels:
1-
Mikhail Fursov wrote:
At the file/directory level, each version (e.g. j2me, j2se1.4, ...)
...
Just my $0.02: IMO it's unreal to support J2SE 1.4 1.5 in the same
source.
Too many differences in the language due to generics. This example needs
branches weekly manual merges (not a big problem
On 11/1/06, Etienne Gagnon [EMAIL PROTECTED] wrote:
For comfortable IDE development, one could imagine that the IDE editor
can reduce to one-line visible comments (or better, specially
formatted ones) so that it gives you the impression that you are really
wearing target-specific spectacles.
Mikhail Fursov wrote:
On 11/1/06, Etienne Gagnon [EMAIL PROTECTED] wrote:
For comfortable IDE development, one could imagine that the IDE editor
can reduce to one-line visible comments (or better, specially
formatted ones) so that it gives you the impression that you are really
wearing
On 11/1/06, Etienne Gagnon [EMAIL PROTECTED] wrote:
Comfortable development happens only using development targets. E.g.
1- process(X, devtarget) - Z
2- edit Z in IDE using comfortable development, where you see a single
commented line for every hidden stream code chunk, keeping you aware
Etienne Gagnon wrote:
Here two typical some use cases, and some proposed solutions:
Problem
---
logging, and other situations where you really don't want to put the
additional source code in the main source files
Solution
use aspects (Plug: you might want to give a look
@incubator.apache.org
Subject: Re: [classlib] Preprocessor - CHECKPOINT
Geir Magnusson Jr. wrote:
There's caching too, I think. LogCache4J
What I meant was that it didn't seem like we came to a conclusion on
it
- that if we had a general pre-processing solution, we could use that
too for logging, rather
Etienne Gagnon wrote:
Geir Magnusson Jr. wrote:
There's caching too, I think. LogCache4J
What I meant was that it didn't seem like we came to a conclusion on it
- that if we had a general pre-processing solution, we could use that
too for logging, rather than have two.
The actual use-cases
I've read a few articles about J2ME development using Antenna, which
has a Java preprocessor task for Ant [1]. The Mobility Pack for
NetBeans includes a Java preprocessor, which it claims is
similar/based on Antenna [2].
I still feel a little dirty about the thought of preprocessing Java
source,
Cool. Any Eclipse Plugin gurus here that could create a whatever it's
called in eclipse speak... perspective? that has two edit panes, one
with the code w the preproc directives in it, and one that is the result
of the preproc given some defines?
geir
Nathan Beyer wrote:
I've read a few
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:
What are the reasons to exclude the most standard solution here: branching.
Do you think we need a lot of them?
I don't think we are excluding any option for maintaining similar code
streams (5.0 6.0, SE ME, etc.) it's just a discussion at the moment.
Similarly, I'm not
On 10/31/06, Tim Ellison [EMAIL PROTECTED] wrote:
Mikhail Fursov wrote:
What are the reasons to exclude the most standard solution here:
branching.
Do you think we need a lot of them?
I don't think we are excluding any option for maintaining similar code
streams (5.0 6.0, SE ME, etc.) it's
Tim Ellison wrote:
Mikhail Fursov wrote:
What are the reasons to exclude the most standard solution here: branching.
Do you think we need a lot of them?
I don't think we are excluding any option for maintaining similar code
streams (5.0 6.0, SE ME, etc.) it's just a discussion at the
-Original Message-
From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]
Sent: Tuesday, October 31, 2006 12:28 PM
To: harmony-dev@incubator.apache.org
Subject: Re: [classlib] Preprocessor
Tim Ellison wrote:
Mikhail Fursov wrote:
What are the reasons to exclude the most standard solution
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
On 10/31/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
We use SVN. How do you propose to do it cleanly in SVN?
I just want to add a simple example for consideration, before we agree on
the final solution.
How do you think, is it possible to maintain java1.4 and java1.5 sources in
the same
Mikhail Fursov wrote:
Yes, the main reason I love Java is a power of tools! If you force me to
work in notepad instead of IDEA with the only reason that we need a
preprocessor I will have a doubt if the solution is reasonable.
Agreed. And that is a reason why it makes sense to have the
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
On 10/31/06, Tim Ellison [EMAIL PROTECTED] wrote:
You can have pointcuts on a whole number of events, including method
invocations but also exception handling, field assignments and accesses,
etc. But you can only add behavior, you cannot subtract from the
original code.
Thanks for your
Tim Ellison wrote:
Mikhail Fursov wrote:
Yes, the main reason I love Java is a power of tools! If you force me to
work in notepad instead of IDEA with the only reason that we need a
preprocessor I will have a doubt if the solution is reasonable.
Agreed. And that is a reason why it makes
Mikhail Fursov wrote:
On 10/31/06, Tim Ellison [EMAIL PROTECTED] wrote:
You can have pointcuts on a whole number of events, including method
invocations but also exception handling, field assignments and accesses,
etc. But you can only add behavior, you cannot subtract from the
original
to break that system.
With best regards,
Alexei Fedotov,
Intel Java XML Engineering
-Original Message-
From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]
Sent: Tuesday, October 31, 2006 1:50 PM
To: harmony-dev@incubator.apache.org
Subject: Re: [classlib] Preprocessor
Fedotov, Alexei
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
Geir Magnusson Jr. wrote:
Tim Ellison wrote:
Mikhail Fursov wrote:
Yes, the main reason I love Java is a power of tools! If you force me to
work in notepad instead of IDEA with the only reason that we need a
preprocessor I will have a doubt if the solution is reasonable.
Agreed. And that is
Geir Magnusson Jr. wrote:
Tim Ellison wrote:
Right, but you (Mr Harmony developer) don't modify the 'processed code',
you work in the 'code w/ preprocessor statements', so you probably want
the code you are modifying to be real, compilable Java code too.
Agreed, but I was thinking though
Tim Ellison wrote:
Geir Magnusson Jr. wrote:
Tim Ellison wrote:
Mikhail Fursov wrote:
Yes, the main reason I love Java is a power of tools! If you force me to
work in notepad instead of IDEA with the only reason that we need a
preprocessor I will have a doubt if the solution is reasonable.
[WARNING: Long!]
Here's an idea.
It would be quite easy (for me, at least ;-) ) to develop a
line-preserving AND revertible processing tool so that:
1- source + javac = j2se
2- source + processor(target) + javac = target, where target is a
parameter (j2me, etc.)
3- source +
Tim Ellison wrote:
Geir Magnusson Jr. wrote:
Tim Ellison wrote:
Right, but you (Mr Harmony developer) don't modify the 'processed code',
you work in the 'code w/ preprocessor statements', so you probably want
the code you are modifying to be real, compilable Java code too.
Agreed, but I was
Etienne Gagnon wrote:
Here's an idea.
big snip
IMO it's not ideal that the preprocessed source still contains all the
streams, albeit in comments. It wouldn't make the source very
'consumable' to the Mrs. SE or ME developer.
The ability for classlib developers to do the switching would be good
Tim Ellison wrote:
IMO it's not ideal that the preprocessed source still contains all the
streams, albeit in comments. It wouldn't make the source very
'consumable' to the Mrs. SE or ME developer.
Hmmm... It's always possible to have a special output mode that puts
empty (or advertizing,
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
What's the concern about just using the prescribed branching pattern
for SVN? There are some other nice tricks like externals for pulling
in common files into the working copies of other branches (ala the
'concurrent' code in 'standard' that's pulled into 'enhanced' on
checkout). I would propose
Nathan Beyer wrote:
What's the concern about just using the prescribed branching pattern
for SVN? There are some other nice tricks like externals for pulling
in common files into the working copies of other branches (ala the
'concurrent' code in 'standard' that's pulled into 'enhanced' on
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
Etienne Gagnon wrote:
Tim Ellison wrote:
IMO it's not ideal that the preprocessed source still contains all the
streams, albeit in comments. It wouldn't make the source very
'consumable' to the Mrs. SE or ME developer.
Hmmm... It's always possible to have a special output mode that puts
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
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
:[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
.
With best regards,
Alexei Fedotov,
Intel Java XML Engineering
-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
-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
for the common
part.
With best regards,
Alexei Fedotov,
Intel Java XML Engineering
-Original Message-
From: Alexei Zakharov [mailto:[EMAIL PROTECTED]
Sent: Monday, October 30, 2006 8:05 PM
To: harmony-dev@incubator.apache.org
Subject: Re: [classlib] Preprocessor (was Re: [classlib][rmi] Code
smell
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
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
96 matches
Mail list logo
