Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: pass (herse.apache.org: domain of alexei.zakharov@gmail.com
 designates 66.249.92.171 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=h4br+ETgjKZUcuLKGPp+n7Gtdt6rBOrfDR3F1zBvfvpACepzHZzK7Hp/d9Cu50XdFQQLcotHAmm8oLjbPBnKHwKrLK6jLEeooDP9xv2iroUUBNBZO9sxzGHdSMYYXi6BRZKjtgDPCk3hqlf2bh0rRgZigLFjrrcbOpzM5K7zUSo=
Message-ID: <2c9597b90610300905h2792f22bk430c272b5f4c1dc2@mail.gmail.com>
Date: Mon, 30 Oct 2006 20:05:02 +0300
From: "Alexei Zakharov" <alexei.zakharov@gmail.com>
To: harmony-dev@incubator.apache.org
Subject: Re: [classlib] Preprocessor (was Re: [classlib][rmi] Code smell -
 Thread.sleep() in ActivationGroup method)
In-Reply-To: <8E389A5F2FEABA4CB1DEC35A25CB39CE694EF8@mssmsx411>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <8E389A5F2FEABA4CB1DEC35A25CB39CE694EF8@mssmsx411>

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 <alexei.a.fedotov@intel.com>:
>                        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:mike.fursov@gmail.com]
> >Sent: Sunday, October 29, 2006 8:56 PM
> >To: harmony-dev@incubator.apache.org; geir@pobox.com
> >Subject: Re: [classlib] Preprocessor (was Re: [classlib][rmi] Code
> smell -
> >Thread.sleep() in ActivationGroup method)
> >
> >On 10/29/06, Geir Magnusson Jr. <geir@pobox.com> 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