An idea: Add a port layer

Jing LV lvjing at
Mon May 16 06:11:32 PDT 2011

Hello Mario,

     That's good news! Your rich experience will greatly help everyone 
on this topic! :)
     In early days I was also developing some portlib and I focused on a 
common native interface, covering the differences between windows, linux 
and some other platforms. I understand service providers but it is a bit 
new to me to apply c/c++ implementation as providers, but this is really 
a new way we can consider.

     If I understand correct then at least we can count on a realtime 
(QNX) system layer :D  I also post on macos list (if there is some other 
platform list please tell me) to see if we have won others' interest on 
this topic.

于 2011-5-16 14:29, neugens.limasoftware at 写道:
> This is a very good idea.
> I have a lot if experience in porting java on weird OS and I can tell 
> you I had lots of troubles trying to unify the various native layers.
> In some OS, a common native interface should be enough, but I think a 
> better solution is to have service providers together with native 
> abstractions, similar to the concept we already have in the current 
> filesystem api.
> In either case, this is definitely a great idea and you can count on 
> me for some manpower :) I have access to a QNX box for the moment 
> (which is mostly compatible, needs some minor things in the network 
> interfaces, and the graphics layer of course), but I can help with 
> other OS as well if I get access to them somehow.
> Mario
> -- 
> Sent from HTC Desire...
> pgp key: PGP Key ID: 80F240CF
> Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF
> Proud GNU Classpath developer:
> Read About us at:
> OpenJDK:
> Please, support open standards:
> ----- Reply message -----
> Da: "Jing LV" <lvjing at>
> Data: lun, mag 16, 2011 04:08
> Oggetto: An idea: Add a port layer
> A: <bsd-port-dev at>
> Hello BSD developers,
> I see on openjdk we'll have more platforms - except BSD, MacOS, there is
> 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 BSD/AIX 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
> BSD/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 BSD 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

Best Regards,
Jimmy, Jing LV

More information about the bsd-port-dev mailing list