harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sean Qiu" <sean.xx....@gmail.com>
Subject Re: [jdktools][JDWP]using portlib to support JDWP transport/agent?
Date Tue, 26 Feb 2008 01:37:49 GMT
+1, agree.

2008/2/25, Oliver Deakin <oliver.deakin@googlemail.com>:
>
> +1 to simplifying and unifying the jdwp source by using portlib. I agree
> with further posts that if there is missing functionality from portlib
> that is required, it should be added to portlib where possible rather
> than adding platform specific source to jdwp.
>
>
> Jimmy,Jing Lv wrote:
> > Hi All,
> >
> >      As I read the current JDWP transport/agent implementation I found
> > that it has two folders, which means now we have two copies of code
> > for windows and Linux. As we know, Harmony have a portlib which can
> > facilitate the development to various of platforms, so I believe maybe
> > we can use portlib to merge current 2  transport/agent into one?
> >      IMHO, we will get following advantage if we use portlib in JDWP:
> > 1. Harmony have various of customers on various of platform(e.g, I
> > remember some MacOS users do works on Harmony), we can use portlib to
> > support such users without any modification on code;
> > 2. keep only one copy of code, omit unnecessary copies for various of
> > platforms. In this case, if any bug/improvement occurs, we can work on
> > only one codebase so that to facilitate the developement and avoid
> > some platform-specific errors.
> >
> >      And the current implementation shows we may need to refactor
> > network and memory APIs to with platform specific APIs, luckiely it
> > seems no much work.
> >      Any comments/suggestions?
> >
> >
>
> --
>
> Oliver Deakin
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
>
>


-- 
Sean, Xiao Xia Qiu
China Software Development Lab, IBM

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message