An idea: Add a port layer

[Henri Gomez]

Do you think about something like Apache does with APR (Apache
Portable Runtime) ?

2011/5/15 Jing LV <lvjing at linux.vnet.ibm.com>:
> Hello MacOS developers,
>
> I see on openjdk we'll have more platforms - except MacOS, there is some
> discussions about AIX. This is great news to the community, as well as a
> new challenge to the community to manage different native implementation
> for new added platform as well as early platform. The challenges we may
> face are:
> 1. in current implementation, we have native implementation in
> windows/linux/solaris directory, and create some same jni methods. But
> actually they have the same or very similar logic. This is not very
> manageable. If some logic is change we need to modify implementation on
> all platforms. and may cause some of problem as no one knows all
> platforms differences, and the platform developers need to understand
> the logic before the modification, it may be a extra work for developers
> like MacOS engineers.
> 2. different platforms offers different system APIs, and even different
> versions of system have different APIs; in current implementation I see
> some code like
> #ifdef someplatform
> use some API
> #endif
> This increases the complexity of the code, and make code ugly. Also the
> developer may have much trouble to read and modify if necessary.
> 3. Openjdk is working on project digjaw/modularization, it may meet some
> trouble if the native API and logic are separated by platform level, not
> in functional level.
>
> I am wondering if a port layer, leave all APIs differences in this
> layer. The jni developers can use this unified API, like "int write(fd,
> byte[])" should work on all platforms openjdk supported, including
> linux, windows, MacOS etc. This may help us the developers:
> 1. the platform developer can focus on covering the API difference and
> care nothing of the upper logical - say, e.g, focus on write some given
> bytes into the give fd, do not care what the fd is and how to deal with
> the buffers etc, so we will write it only once, and only update for new
> APIs when necessary. Meanwhile, the classlib developers can use an
> unified system API and focus on the logic, we write the code once for
> all platforms. It save time and effort on both side.
> 2. The code is then clear, no #endif is required, this helps the
> developer to read and understand, and much easier to modify.
> 3. it may help to modularize the jdk as well.
>
> An new portlib may also have some problems, like modification on the
> current code, and performance. We need to define the portlayer well, and
> make excellent build script to avoid performance degradation of the
> layer. However, in the long run, the portlayer will really help the
> developers as well as JDK, like some other opensource jdk do.
>
> I believe the portlayer would help MacOS developers a lot in code
> maintenance, and when updating new features. I'd like to listen to your
> opinions/comments/suggestions on this topic.
>
> Thanks!
>
> --
> Best Regards,
> Jimmy, Jing LV
>
>
>