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.limasoftw...@gmail.com ει:
> 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: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
> Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF
>
> http://www.icedrobot.org
>
> Proud GNU Classpath developer: http://www.classpath.org/
> Read About us at: http://planet.classpath.org
> OpenJDK: http://openjdk.java.net/projects/caciocavallo/
>
> Please, support open standards:
> http://endsoftpatents.org/
>
>
> ----- Reply message -----
> Da: "Jing LV" <lvj...@linux.vnet.ibm.com>
> Data: lun, mag 16, 2011 04:08
> Oggetto: An idea: Add a port layer
> A: <bsd-port-dev@openjdk.java.net>
>
> 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
