Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: neutral (asf.osuosl.org: 195.212.29.139 is neither permitted nor
 denied by domain of mark.hindess@googlemail.com)
Message-Id: <200606271555.k5RFtm9H032090@d06av02.portsmouth.uk.ibm.com>
From: Mark Hindess <mark.hindess@googlemail.com>
To: harmony-dev@incubator.apache.org
Subject: Re: awt and swing integration issues 
In-reply-to: Your message of "Tue, 27 Jun 2006 16:49:16 BST."
             <200606271549.k5RFnEVH020363@d06av02.portsmouth.uk.ibm.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 27 Jun 2006 16:55:50 +0100


On 27 June 2006 at 16:49, Mark Hindess <mark.hindess@googlemail.com> wrote:
> 
> On 27 June 2006 at 7:00, "bootjvm" <bootjvm@earthlink.net> wrote:
> > 
> > Concerning Mark's observation lsat week on AWT/Swing
> > where only a, "couple of files" were C++ instead of C
> > source code:
> >
> > I thing it would make library maintenance easier when everything is
> > done in one single, regular manner.  If everything is C but a short
> > segment, it would make the world run better to not have exceptions to
> > the rule if they could be converted into C.  Mixed language projects
> > in a mode like this _often_ have maintenance issues in this arena.
> > Therefore, I would suggest this conversion be done.
> 
> I'm looking at the integration of the native code from the awt/swing
> 'misc' dependency right now.
> 
> I think these natives will quite likely get merged in to luni at some
> point.  At that point, it would definitely make sense to convert them
> to C to avoid adding unnecessary requirements to a core element of the
> Harmony classlib.

I just remembered that the binary size was significantly less after 
converting from C++ to C (when I did the auth natives).  So that's
another reason for the simple misc dependency natives to be converted.

-Mark.

> On the other hand I'm not quite so concerned about the use of C++ for
> awt - since the requirement there (for ease of use with GDI) is justified.
> 
> Regards,
>  Mark.
> 
> > Dan Lydick
> > 
> > > [Original Message]
> > > From: Geir Magnusson Jr <geir@pobox.com>
> > > To: <harmony-dev@incubator.apache.org>
> > > Date: 6/19/06 6:49:38 AM
> > > Subject: Re: awt and swing integration issues
> > >
> > > My USD0.02...
> > >
> > > 1) If I were to write a GUI toolkit, I can't imagine why I wouldn't use
> > > C++ given relationships like "DialogBox is a Window"
> > >
> > > 2) Isn't it a reasonably safe bet that any platform that has a GUI is
> > > 'advanced' enough to have a reasonable C++ compiler for it?
> > >
> > > I understand the need to stick to the simplicity of C, but I'm not
> > > surprised w/ the C++
> > >
> > > Mark, are you suggesting we convert it back to C?
> > >
> > > geir
> > >
> > > Alexey Petrenko wrote:
> > > > 2006/6/18, Mark Hindess <mark.hindess@googlemail.com>:
> > > >>
> > > >> On 18 June 2006 at 22:16, "Alexey Petrenko"
> > > >> <alexey.a.petrenko@gmail.com> wrote:
> > > >> > 2006/6/18, Mark Hindess <mark.hindess@googlemail.com>:
> > > >> > > c) I'm also wondering about the motivation for using C++ when I
> > can't
> > > >> > > see any pressing reason to require this.
> > > >> > You mean that most of the native code is C++ but not C?
> > > >>
> > > >> Yes.  It seems to be a mixture of C and C++ and although I only looked
> > > >> at a couple of files I didn't see anything that really needed C++
> > > >> features.
> > > >>
> > > >> For portability I'd stick to C if C++ isn't really required.
> > > > But C++ gives at least 2 benefits for developer:
> > > > 1. Strict type checking
> > > > 2. It is allow to write env->FindClass("java/lang/Object") instead of
> > > > (*env)->FindClass(env, "java/lang/Object") :)
> > > > 
> > > > Windows version also uses GDI+ which is class library.
> > > > 
> > > > So I vote for C++...
> > >
> > > ---------------------------------------------------------------------
> > > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> > > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> > >
> > 
> > 
> > 
> > 
> > ---------------------------------------------------------------------
> > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> 
> 
> 
> 
> 
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org


---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org