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

[Geir Magnusson Jr.]

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 tongue! :)



I've worked a little bit with IBM's WebSphere Micro Environment and it
runs on the ME-type devices, like Windows Mobile, but it also runs on
Windows XP/2003. Obviously this is the opposite scenario, but the
concept is sharing the same VM with a subset class library




As for logging -- I agree with Tim, just don't do it. If we really
want logging, then just use AspectJ or the like. AspectJ can do
compile or runtime injection with the same aspects; at least it used
to a few years ago.


I think we've all agreed a long time ago that we're not going to have 
logging in production code.  The point here is to find a harmless way of 
letting people do it if they want to for classlib development ...


geir




-Nathan

On 10/31/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:



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 (old) branches as a rule we finally will tune our process and
> will have almost no overhead to propagate changes from one branch to
> another. The hell is when you do not have any stable schema and create
> long living branches without reasons.
>
> The success of preprocessor's idea is also heavily depends how will we
> use it.
> For example, what about "old versions"? Should we someday move the code
> into separate branch or collect N-years old versions in the same 
source?


Yes, I assume that we'd branch and park 5 at some point, putting it into
maintenance, and then just if there is a bug, deal with them on case by
case back into main tree.

But that's just version of SE mainline. There also is The Logging Topic
That Will Not Die, as well as capabilities and profiles for ME (if
someone wanted to do so), but I know almost zero about how that works in
real life.

geir

>
>
>
> --
> Mikhail Fursov

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

[Nathan Beyer]

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 Micro Environment and it
runs on the ME-type devices, like Windows Mobile, but it also runs on
Windows XP/2003. Obviously this is the opposite scenario, but the
concept is sharing the same VM with a subset class library.

As for logging -- I agree with Tim, just don't do it. If we really
want logging, then just use AspectJ or the like. AspectJ can do
compile or runtime injection with the same aspects; at least it used
to a few years ago.

-Nathan

On 10/31/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:



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 (old) branches as a rule we finally will tune our process and
> will have almost no overhead to propagate changes from one branch to
> another. The hell is when you do not have any stable schema and create
> long living branches without reasons.
>
> The success of preprocessor's idea is also heavily depends how will we
> use it.
> For example, what about "old versions"? Should we someday move the code
> into separate branch or collect N-years old versions in the same source?

Yes, I assume that we'd branch and park 5 at some point, putting it into
maintenance, and then just if there is a bug, deal with them on case by
case back into main tree.

But that's just version of SE mainline. There also is The Logging Topic
That Will Not Die, as well as capabilities and profiles for ME (if
someone wanted to do so), but I know almost zero about how that works in
real life.

geir

>
>
>
> --
> Mikhail Fursov

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

[Tim Ellison]

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 (old) branches as a rule we finally will tune our
> process and will have almost no overhead to propagate changes from
> one branch to another. The hell is when you do not have any stable
> schema and create long living branches without reasons.
> 
> The success of preprocessor's idea is also heavily depends how will
> we use it. For example, what about "old versions"? Should we someday
> move the code into separate branch or collect N-years old versions in
> the same source?

IMO you need both VCM branches (for code maintenance streams) and
preprocessor (for code 'shape' streams).

Regards,
Tim

-- 

Tim Ellison ([EMAIL PROTECTED])

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

[Geir Magnusson Jr.]

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 (old) branches as a rule we finally will tune our process and 
will have almost no overhead to propagate changes from one branch to 
another. The hell is when you do not have any stable schema and create 
long living branches without reasons.


The success of preprocessor's idea is also heavily depends how will we 
use it.
For example, what about "old versions"? Should we someday move the code 
into separate branch or collect N-years old versions in the same source?


Yes, I assume that we'd branch and park 5 at some point, putting it into 
maintenance, and then just if there is a bug, deal with them on case by 
case back into main tree.


But that's just version of SE mainline. There also is The Logging Topic 
That Will Not Die, as well as capabilities and profiles for ME (if 
someone wanted to do so), but I know almost zero about how that works in 
real life.


geir





--
Mikhail Fursov

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

[Mikhail Fursov]

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

[Mikhail Fursov]

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 rule we finally will tune our process and will
have almost no overhead to propagate changes from one branch to another. The
hell is when you do not have any stable schema and create long living
branches without reasons.

The success of preprocessor's idea is also heavily depends how will we use
it.
For example, what about "old versions"? Should we someday move the code into
separate branch or collect N-years old versions in the same source?



--
Mikhail Fursov

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

[Geir Magnusson Jr.]

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 sounds like we'd 
go rapidly to branch-hell.


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 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) Everyone knows how to work with branches.
4) No need to support very old versions in the same sources.

Disadvanates
1) Need to propagate a fix to all product branches we have.

?


--
Mikhail Fursov

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

[Mikhail Fursov]

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) Everyone knows how to work with branches.
4) No need to support very old versions in the same sources.

Disadvanates
1) Need to propagate a fix to all product branches we have.

?


--
Mikhail Fursov

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

[Geir Magnusson Jr.]

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 without don't require tons of IDE-specific
tooling.  This is what bothers me about aspects - can you get a real
clue what's going to happen looking at the source code?


To be fair though, it's pretty hard to see what is going on in any large
software system without IDE support.  If you haven't looked at AspectJ
[1] for a while it's worth looking again -- they do a pretty cool job of
showing what is going to happen with aspects applied.


I can't find the plugins for IDEA :)

I know what you mean, but I can tend to reach for any of the main IDEs 
and work on most projects.  It's just when a project mandates an IDE 
that I get itchy.


Now, I know in our case that we may have to do that and I'm willing to 
completely go to the dark side and use Eclipse all the time (and aspectJ 
has support for more than one because of it's history... it didn't start 
at Eclipse...), but I'm hoping there are enough clever people around so 
we can get a broad set of tools...




I agree with your point that it's not going to be helpful to require
"tons of IDE-specific tooling".

[1] http://www.eclipse.org/aspectj/

Regards,
Tim

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

[Tim Ellison]

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 tons of IDE-specific
> tooling.  This is what bothers me about aspects - can you get a real
> clue what's going to happen looking at the source code?

To be fair though, it's pretty hard to see what is going on in any large
software system without IDE support.  If you haven't looked at AspectJ
[1] for a while it's worth looking again -- they do a pretty cool job of
showing what is going to happen with aspects applied.

I agree with your point that it's not going to be helpful to require
"tons of IDE-specific tooling".

[1] http://www.eclipse.org/aspectj/

Regards,
Tim

-- 

Tim Ellison ([EMAIL PROTECTED])

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

[Fedotov, Alexei A]

Alexey wrote,
> > At the same time I don't feel
>> completely comfortable with the idea of using preprocessor to
separate
>> J2SE sources from J2ME.

A preprocessor looks a possible choice for maintaining several profiles
(eg Java ME vs Java SE). We need compact and preferably precompiled
sources to be efficient on small devices.

There is one more option. Can we use a good source control system
instead? Java ME workspace could be a child of Java SE one. I believe
something like BitKeeper or Teemware can keep things different when
needed and propagate bug fixes and patches painlessly 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 -
>Thread.sleep() in ActivationGroup method)
>
>Hi all,
>
>Well, as an individual who has the tendency to pure Java programming I
>will be happier if I can control things on the source-code level. I
>can't say I don't like the idea about sophisticated JIT with the
>powerful AI inside, but if we are talking about logging then IMHO a
>good preprocessor is the thing that we need (but we may also continue
>to JIT away stuff if we like). At the same time I don't feel
>completely comfortable with the idea of using preprocessor to separate
>J2SE sources from J2ME.
>
>No clue about particular technology. It can be SableCC, something
>custom-made, velocity or whatever.
>
>Thanks,
>
>2006/10/30, Fedotov, Alexei A <[EMAIL PROTECTED]>:
>>Premature optimization is the root of all evil
>>Donald Knuth
>>
>>
>> >Just a small idea: Let teach JIT to purge this code unless special
>> option
>> >is ON
>>
>> +1
>>
>> I believe a computer should adapt to my way of thinking. I prefer a
>> simple and readable code to an efficient one since the former one
saves
>> the time of my life, why the latter one saves some electricity.
>>
>> 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] 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 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.
>
>
>--
>Alexei Zakharov,
>Intel Enterprise Solutions Software Division

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

[Fedotov, Alexei A]

Geir wrote,
>Not only that, we create a class library that places **weird**
requirements
>on any VM that wants to use it.

Ok, I believe this was honest. :-) As far as I know the optimization
Mikhail is talking about is nearly standard for any optimizing JIT. 

Isn't it just a simple inlining? I accept that inlining in Java is a bit
more complex, than in C, since you can load classes and redefine methods
on fly. Anyway optimizing JIT recompiles the whole thing when such event
happens and an appropriate callback is called.

With best regards,
Alexei Fedotov,
Intel Java & 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 ActivationGroup method)
>
>
>
>Alexei Zakharov wrote:
>> Hi all,
>>
>> Well, as an individual who has the tendency to pure Java programming
I
>> will be happier if I can control things on the source-code level. I
>> can't say I don't like the idea about sophisticated JIT with the
>> powerful AI inside, but if we are talking about logging then IMHO a
>> good preprocessor is the thing that we need (but we may also continue
>> to JIT away stuff if we like).
>
>Not only that, we create a class library that places weird requirements
>on any VM that wants to use it.  No thanks.
>
> > 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 tons of IDE-specific
>tooling.  This is what bothers me about aspects - can you get a real
>clue what's going to happen looking at the source code?
>
>geir
>
>>
>> No clue about particular technology. It can be SableCC, something
>> custom-made, velocity or whatever.
>>
>> Thanks,
>>
>> 2006/10/30, Fedotov, Alexei A <[EMAIL PROTECTED]>:
>>>Premature optimization is the root of all
evil
>>>Donald Knuth
>>>
>>>
>>> >Just a small idea: Let teach JIT to purge this code unless special
>>> option
>>> >is ON
>>>
>>> +1
>>>
>>> I believe a computer should adapt to my way of thinking. I prefer a
>>> simple and readable code to an efficient one since the former one
saves
>>> the time of my life, why the latter one saves some electricity.
>>>
>>> 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] 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 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.
>>
>>

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

[Geir Magnusson Jr.]

Alexei Zakharov wrote:

Hi all,

Well, as an individual who has the tendency to pure Java programming I
will be happier if I can control things on the source-code level. I
can't say I don't like the idea about sophisticated JIT with the
powerful AI inside, but if we are talking about logging then IMHO a
good preprocessor is the thing that we need (but we may also continue
to JIT away stuff if we like). 


Not only that, we create a class library that places weird requirements 
on any VM that wants to use it.  No thanks.


> 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 tons of IDE-specific 
tooling.  This is what bothers me about aspects - can you get a real 
clue what's going to happen looking at the source code?


geir



No clue about particular technology. It can be SableCC, something
custom-made, velocity or whatever.

Thanks,

2006/10/30, Fedotov, Alexei A <[EMAIL PROTECTED]>:

   Premature optimization is the root of all evil
   Donald Knuth


>Just a small idea: Let teach JIT to purge this code unless special
option
>is ON

+1

I believe a computer should adapt to my way of thinking. I prefer a
simple and readable code to an efficient one since the former one saves
the time of my life, why the latter one saves some electricity.

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

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

[Alexei Zakharov]

Hi all,

Well, as an individual who has the tendency to pure Java programming I
will be happier if I can control things on the source-code level. I
can't say I don't like the idea about sophisticated JIT with the
powerful AI inside, but if we are talking about logging then IMHO a
good preprocessor is the thing that we need (but we may also continue
to JIT away stuff if we like). At the same time I don't feel
completely comfortable with the idea of using preprocessor to separate
J2SE sources from J2ME.

No clue about particular technology. It can be SableCC, something
custom-made, velocity or whatever.

Thanks,

2006/10/30, Fedotov, Alexei A <[EMAIL PROTECTED]>:

   Premature optimization is the root of all evil
   Donald Knuth


>Just a small idea: Let teach JIT to purge this code unless special
option
>is ON

+1

I believe a computer should adapt to my way of thinking. I prefer a
simple and readable code to an efficient one since the former one saves
the time of my life, why the latter one saves some electricity.

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



--
Alexei Zakharov,
Intel Enterprise Solutions Software Division

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

[Fedotov, Alexei A]

Premature optimization is the root of all evil
Donald Knuth


>Just a small idea: Let teach JIT to purge this code unless special
option
>is ON

+1

I believe a computer should adapt to my way of thinking. I prefer a
simple and readable code to an efficient one since the former one saves
the time of my life, why the latter one saves some electricity.

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] 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 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 (was Re: [classlib][rmi] Code smell - Thread.sleep() in ActivationGroup method)

[Sian January]

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. <[EMAIL PROTECTED]> 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)

[Etienne Gagnon]

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


signature.asc
Description: OpenPGP digital signature

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

[Geir Magnusson Jr.]

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)

[Chris Gray]

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, OSGihttp://www.k-embedded-java.com/
[EMAIL PROTECTED] +32 3 216 0369

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

[Nathan Beyer]

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

[Geir Magnusson Jr.]

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 (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)

[Mikhail Fursov]

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