You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Stefano Mazzocchi <st...@apache.org> on 2006/02/10 15:54:15 UTC
Using APR for Harmony's native link to the OS?
tellison@apache.org wrote:
> Author: tellison
> Date: Fri Feb 10 05:57:38 2006
> New Revision: 376690
>
> URL: http://svn.apache.org/viewcvs?rev=376690&view=rev
> Log:
> Applying patches received as HARMONY-42 (com.ibm.io.nio.FileChannel is not fully implemented)
> - refactoring of some java platform code
> - additional behavior on NIO file channels
> - refactoring of some IO code
> - work in progress on memory mapping
Tim's commits made me think about something that I thought about a
loooooong time ago (probably 1999) in the "would be awesome" kind of
department but I put off for a future where we would have a project to
work on a JVM.
turns out we do have one now and turns out that APR[1] is a library that
is now very solid and reached API stability over years of work by a lot
of people.
so, here it is, does it make sense to have harmony depend on APR and
therefore abstract away all those OS-specificities? (I'm talking about
both the VM and the native part of the class library).
It also has a major social side effects: it would create the ultimate
social bridge between the HTTPD/APR side of the foundation and the java
side of the foundation, maybe allowing people from one side to
contribute to the other, or, at least to help out in the interface
between them which naturally is the JVM.
What do you think?
[1] http://apr.apache.org/
--
Stefano.
Re: Using APR for Harmony's native link to the OS?
Posted by Andrey Chernyshev <a....@gmail.com>.
On 2/10/06, Enrico Migliore <en...@fatti.com> wrote:
> Stefano Mazzocchi wrote:
>
> > tellison@apache.org wrote:
> >
> >> Author: tellison
> >> Date: Fri Feb 10 05:57:38 2006
> >> New Revision: 376690
> >>
> >> URL: http://svn.apache.org/viewcvs?rev=376690&view=rev
> >> Log:
> >> Applying patches received as HARMONY-42 (com.ibm.io.nio.FileChannel
> >> is not fully implemented)
> >> - refactoring of some java platform code
> >> - additional behavior on NIO file channels
> >> - refactoring of some IO code
> >> - work in progress on memory mapping
> >
> >
> > Tim's commits made me think about something that I thought about a
> > loooooong time ago (probably 1999) in the "would be awesome" kind of
> > department but I put off for a future where we would have a project to
> > work on a JVM.
> >
> > turns out we do have one now and turns out that APR[1] is a library
> > that is now very solid and reached API stability over years of work by
> > a lot of people.
> >
> > so, here it is, does it make sense to have harmony depend on APR and
> > therefore abstract away all those OS-specificities? (I'm talking about
> > both the VM and the native part of the class library).
> >
> > It also has a major social side effects: it would create the ultimate
> > social bridge between the HTTPD/APR side of the foundation and the
> > java side of the foundation, maybe allowing people from one side to
> > contribute to the other, or, at least to help out in the interface
> > between them which naturally is the JVM.
> >
> > What do you think?
> >
> > [1] http://apr.apache.org/
> >
> I haven't gone through the APR library therefore I don't know how many
> layers (i.e. function calls)
> it puts between Apache and the underlying OS.
>
I was looking into APR's part which is responsible for threading
(threadproc and locks). From what I've seen, I've got an impression
that the APR does almost exactly what I would do in order to find a
smallest "common denominator" between, for example, Win32 threading
API and pthreads. So in my opinion it is pretty much close to the
concept of thin portability layer we may need between VM/Classlib and
OS.
> As far as the the native code of the Classlib and the VM is concerned, I
> think that we should keep it
> as thinner as possible in order to:
>
> 1. have Java programs run fast
I suspect the performance could be a requirement for HTTPD as well.
> 2. ease portability to different OS's and platforms (embedded
> systems included)
Yes, this means some layer between VM/Classlib and OS is needed
anyways, and it might be good to reuse some of the existing "standard"
solutions, rather than try to create one more. It seems that HTTPD
mist be in the same position regarding the performance and portability
requirements. Therefore, I would agree with the point that having a
shared layer for two different projects, like HTTPD and Harmony, could
be beneficial for both of them.
Thank you,
Andrey Chernyshev
Intel Middleware Products Division
>
> The GNU/Classpath guys, for example, have defined a standard interface
> to underlying OS
> and that's it. Therefore I don't think we really need the APR layer.
>
> Enrico
>
>
>
>
>
>
>
Re: Using APR for Harmony's native link to the OS?
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Mladen Turk wrote:
> So at the end of the day, you have a simple question:
> Is Harmony a way to give a JVM to the GNU/Classpath,
> or is a Harmony a project that will some day have option
> to choose between different 'classpath' libraries.
> If it's the first, the entire thing has nothing to do
> with ASF, and if it's a second, then I don't understand why
> all the fuzz about a different perspective proposals.
Harmony is going to create a full, certified implementation of J2SE.
Right now, we're on our way to having a JVM and a class library. Great.
Many of us are also interested in ensuring that stuff is reusable. If
we have a great VM that people - on their own - wish to take and use
with Classpath, I say more power to them. Similarly, if someone wishes
to take our classlibrary and use it with Kaffe, have at it.
We want ubiquitous, open Java, and interchangeable parts is a step in
that direction.
Now lets get back to APR...
geir
Re: Using APR for Harmony's native link to the OS?
Posted by Stefano Mazzocchi <st...@apache.org>.
Mladen Turk wrote:
> Enrico Migliore wrote:
>>
>> I took a look at the documentation of the APR project:
> > 1. APR doesn't cover is the Windowing subsystem
>
> Sure, APR is something POSIX is meant to be.
>
> > 2. An APR port to the ARM embedded platform doesn't exist
>
> If someone wishes to build a GNU/Classpath like system
> under Apache license, with APR instead POSIX as OS
> abstraction layer (or any other), will you object?
>
> I think this is the ultimate question of the entire thread.
> Seems to me that when ever someone says something in the
> direction of replacing GNU/Classpath with something else,
> the voices are up.
>
> From ground up I'm opposed to this artificial synergy of
> ASF and GNU code, and until it gets resolved the Harmony
> project will never become a true ASF project.
>
> The reason is pretty simple, we are two different communities,
> and just like in the real world, it's hard to merge the
> things with different views.
>
> So at the end of the day, you have a simple question:
> Is Harmony a way to give a JVM to the GNU/Classpath,
> or is a Harmony a project that will some day have option
> to choose between different 'classpath' libraries.
> If it's the first, the entire thing has nothing to do
> with ASF, and if it's a second, then I don't understand why
> all the fuzz about a different perspective proposals.
Mladen,
keep your political/philosophical allergies out of here, please, there
is already enough to do without having to dissipate the negative energy
that you throw in the mix.
Enrico was airing his point of view, which I respected even when it
disagreed with mine, and the discussion was purely technical, as it
should be.
Licensing policies are *NOT* something that we talk about and discuss
overhere, unless they deal with your ability to participate in the
development.
If you disagree with the ASF licensing policies, I will be very glad to
listen to you with my ASF director hat on and even voice your concerns
in the appropriate places, but not here and not with that tone.
--
Stefano.
Re: Using APR for Harmony's native link to the OS?
Posted by Enrico Migliore <en...@fatti.com>.
Mladen Turk wrote:
> Enrico Migliore wrote:
>
>>
>> I took a look at the documentation of the APR project:
>
> > 1. APR doesn't cover is the Windowing subsystem
>
> Sure, APR is something POSIX is meant to be.
>
> > 2. An APR port to the ARM embedded platform doesn't exist
>
> If someone wishes to build a GNU/Classpath like system
> under Apache license, with APR instead POSIX as OS
> abstraction layer (or any other), will you object?
>
> I think this is the ultimate question of the entire thread.
> Seems to me that when ever someone says something in the
> direction of replacing GNU/Classpath with something else,
> the voices are up.
>
> From ground up I'm opposed to this artificial synergy of
> ASF and GNU code, and until it gets resolved the Harmony
> project will never become a true ASF project.
>
> The reason is pretty simple, we are two different communities,
> and just like in the real world, it's hard to merge the
> things with different views.
>
> So at the end of the day, you have a simple question:
> Is Harmony a way to give a JVM to the GNU/Classpath,
> or is a Harmony a project that will some day have option
> to choose between different 'classpath' libraries.
> If it's the first, the entire thing has nothing to do
> with ASF, and if it's a second, then I don't understand why
> all the fuzz about a different perspective proposals.
>
>
> Regards,
> Mladen.
>
Hi Mladen,
I'm not a fan of GNU/Classpath, in fact, after reading the documentation
of the APR project and understood the potential of it, I've changed my mind,
as said in my previous thread.
As far as the windowing system is concerned, I just pointed out that if
the APR
had the interface to the native windowing system, it would save quite a
bit of work to us.
Enrico
Re: Using APR for Harmony's native link to the OS?
Posted by Dalibor Topic <ro...@kaffe.org>.
Mladen Turk <mturk <at> apache.org> writes:
> I think this is the ultimate question of the entire thread.
> Seems to me that when ever someone says something in the
> direction of replacing GNU/Classpath with something else,
> the voices are up.
Given that GNU Classpath isn't used in Harmony, it can't be
replaced within Harmony. Harmony has its own class library,
and its own ways of doing things.
> From ground up I'm opposed to this artificial synergy of
> ASF and GNU code, and until it gets resolved the Harmony
> project will never become a true ASF project.
There is no GNU code in Harmony.
> The reason is pretty simple, we are two different communities,
> and just like in the real world, it's hard to merge the
> things with different views.
That's pretty easy, actually. You just chose one of them, at
whichever task they are better, and use that code, and throw away
the stuff you don't use. Been there, done that with Kaffe's old
class library.
It's just liberally licensed free software either way. Once GPL3
is released next year, the flow of code between the class libraries
will work in at least one direction, so the discussions are pretty
moot at this point anyway.
> So at the end of the day, you have a simple question:
> Is Harmony a way to give a JVM to the GNU/Classpath,
> or is a Harmony a project that will some day have option
> to choose between different 'classpath' libraries.
The latter.
> If it's the first, the entire thing has nothing to do
> with ASF, and if it's a second, then I don't understand why
> all the fuzz about a different perspective proposals.
I don't think the fuzz really matters, anyway. Just go for whatever
makes sense for you, and we'll merge things if we ever fix the
politics inside the ASF or FSF. If not, so be it, no harm done by
having more free code out there.
cheers,
dalibor topic
Re: Using APR for Harmony's native link to the OS?
Posted by Mladen Turk <mt...@apache.org>.
Enrico Migliore wrote:
>
> I took a look at the documentation of the APR project:
> 1. APR doesn't cover is the Windowing subsystem
Sure, APR is something POSIX is meant to be.
> 2. An APR port to the ARM embedded platform doesn't exist
If someone wishes to build a GNU/Classpath like system
under Apache license, with APR instead POSIX as OS
abstraction layer (or any other), will you object?
I think this is the ultimate question of the entire thread.
Seems to me that when ever someone says something in the
direction of replacing GNU/Classpath with something else,
the voices are up.
From ground up I'm opposed to this artificial synergy of
ASF and GNU code, and until it gets resolved the Harmony
project will never become a true ASF project.
The reason is pretty simple, we are two different communities,
and just like in the real world, it's hard to merge the
things with different views.
So at the end of the day, you have a simple question:
Is Harmony a way to give a JVM to the GNU/Classpath,
or is a Harmony a project that will some day have option
to choose between different 'classpath' libraries.
If it's the first, the entire thing has nothing to do
with ASF, and if it's a second, then I don't understand why
all the fuzz about a different perspective proposals.
Regards,
Mladen.
Re: Using APR for Harmony's native link to the OS?
Posted by Enrico Migliore <en...@fatti.com>.
Enrico Migliore wrote:
> 2. An APR port to the ARM embedded platform doesn't exist
Tom wrote:
> Thanks for checking that out! About (2): From what I am seeing these
> days it is important to support ARM. BTW, where did you get this
> information about ports not being available please? I did not find a
> "porting page".
Hi Tom,
if the Linux API's of the port to the ARM platform are 100% identical to
the ufficial Linux ones,
then APR can be GCC cross-built without problems.
Enrico
Re: Using APR for Harmony's native link to the OS?
Posted by Tom <ec...@gatewide.com>.
Thanks for checking that out! About (2): From what I am seeing these
days it is important to support ARM. BTW, where did you get this
information about ports not being available please? I did not find a
"porting page".
Enrico Migliore wrote:
>
>> Stefano wrote:
>> I think we would gain a lot of value by using APR instead of
>> reinventing something that 5 years from now will look just like it.
>>
>
> Hi Stefano,
>
> I took a look at the documentation of the APR project:
>
> http://apr.apache.org/docs/apr/modules.html
> http://apr.apache.org/docs/apr-util/modules.html
> http://apr.apache.org/docs/apr-iconv/files.html
>
> and this in an excerpt from the apr.h file, which shows the
> main features of APR:
>
> #define APR_HAS_SHARED_MEMORY 1
> #define APR_HAS_THREADS 1
> #define APR_HAS_MMAP 1
> #define APR_HAS_FORK 0
> #define APR_HAS_RANDOM 1
> #define APR_HAS_OTHER_CHILD 1
> #define APR_HAS_DSO 1
> #define APR_HAS_SO_ACCEPTFILTER 0
> #define APR_HAS_UNICODE_FS 1
> #define APR_HAS_PROC_INVOKED 1
> #ifndef _WIN32_WCE
> #define APR_HAS_SENDFILE 1
> #define APR_HAS_USER 1
> #define APR_HAS_LARGE_FILES 1
> #define APR_HAS_XTHREAD_FILES 1
> #else
> #define APR_HAS_SENDFILE 0
> #define APR_HAS_USER 0
> #define APR_HAS_LARGE_FILES 0
> #define APR_HAS_XTHREAD_FILES 0
> #endif
> #define APR_HAS_OS_UUID 1
>
>
> I noticed also that the following macros are present:
>
> WIN64, APR_HAVE_IPV6
>
> I downloaded the project and built on Win32 without warnings,
> and the footprint of apr-1.lib is 1 Mbyte.
>
> I think I'm leaning to your idea :-)
>
> The last 2 problems I see here are:
>
> 1. APR doesn't cover is the Windowing subsystem
> 2. An APR port to the ARM embedded platform doesn't exist
>
> Enrico
>
>
>
>
Re: Using APR for Harmony's native link to the OS?
Posted by Enrico Migliore <en...@fatti.com>.
> Stefano wrote:
> I think we would gain a lot of value by using APR instead of
> reinventing something that 5 years from now will look just like it.
>
Hi Stefano,
I took a look at the documentation of the APR project:
http://apr.apache.org/docs/apr/modules.html
http://apr.apache.org/docs/apr-util/modules.html
http://apr.apache.org/docs/apr-iconv/files.html
and this in an excerpt from the apr.h file, which shows the
main features of APR:
#define APR_HAS_SHARED_MEMORY 1
#define APR_HAS_THREADS 1
#define APR_HAS_MMAP 1
#define APR_HAS_FORK 0
#define APR_HAS_RANDOM 1
#define APR_HAS_OTHER_CHILD 1
#define APR_HAS_DSO 1
#define APR_HAS_SO_ACCEPTFILTER 0
#define APR_HAS_UNICODE_FS 1
#define APR_HAS_PROC_INVOKED 1
#ifndef _WIN32_WCE
#define APR_HAS_SENDFILE 1
#define APR_HAS_USER 1
#define APR_HAS_LARGE_FILES 1
#define APR_HAS_XTHREAD_FILES 1
#else
#define APR_HAS_SENDFILE 0
#define APR_HAS_USER 0
#define APR_HAS_LARGE_FILES 0
#define APR_HAS_XTHREAD_FILES 0
#endif
#define APR_HAS_OS_UUID 1
I noticed also that the following macros are present:
WIN64, APR_HAVE_IPV6
I downloaded the project and built on Win32 without warnings,
and the footprint of apr-1.lib is 1 Mbyte.
I think I'm leaning to your idea :-)
The last 2 problems I see here are:
1. APR doesn't cover is the Windowing subsystem
2. An APR port to the ARM embedded platform doesn't exist
Enrico
Re: Using APR for Harmony's native link to the OS?
Posted by Stefano Mazzocchi <st...@apache.org>.
Enrico Migliore wrote:
> Stefano Mazzocchi wrote:
>
>> tellison@apache.org wrote:
>>
>>> Author: tellison
>>> Date: Fri Feb 10 05:57:38 2006
>>> New Revision: 376690
>>>
>>> URL: http://svn.apache.org/viewcvs?rev=376690&view=rev
>>> Log:
>>> Applying patches received as HARMONY-42 (com.ibm.io.nio.FileChannel
>>> is not fully implemented)
>>> - refactoring of some java platform code
>>> - additional behavior on NIO file channels
>>> - refactoring of some IO code
>>> - work in progress on memory mapping
>>
>>
>> Tim's commits made me think about something that I thought about a
>> loooooong time ago (probably 1999) in the "would be awesome" kind of
>> department but I put off for a future where we would have a project to
>> work on a JVM.
>>
>> turns out we do have one now and turns out that APR[1] is a library
>> that is now very solid and reached API stability over years of work by
>> a lot of people.
>>
>> so, here it is, does it make sense to have harmony depend on APR and
>> therefore abstract away all those OS-specificities? (I'm talking about
>> both the VM and the native part of the class library).
>>
>> It also has a major social side effects: it would create the ultimate
>> social bridge between the HTTPD/APR side of the foundation and the
>> java side of the foundation, maybe allowing people from one side to
>> contribute to the other, or, at least to help out in the interface
>> between them which naturally is the JVM.
>>
>> What do you think?
>>
>> [1] http://apr.apache.org/
>>
> I haven't gone through the APR library therefore I don't know how many
> layers (i.e. function calls)
> it puts between Apache and the underlying OS.
>
> As far as the the native code of the Classlib and the VM is concerned, I
> think that we should keep it
> as thinner as possible in order to:
>
> 1. have Java programs run fast
I agree this is the goal, but since performance is *also* one of the
needs for the Apache HTTPD 2.x project, I doubt they went very light on
that front (especially after 5 years of development!)
> 2. ease portability to different OS's and platforms (embedded
> systems included)
APR was designed to ease OS portability.
> The GNU/Classpath guys, for example, have defined a standard interface
> to underlying OS
> and that's it. Therefore I don't think we really need the APR layer.
I disagree. I think we would gain a lot of value by using APR instead of
reinventing something that 5 years from now will look just like it.
--
Stefano.
Re: Using APR for Harmony's native link to the OS?
Posted by Mladen Turk <mt...@apache.org>.
Stefano Mazzocchi wrote:
> Mladen Turk wrote:
>> Enrico Migliore wrote:
>>> Stefano Mazzocchi wrote:
>>>
>>> The GNU/Classpath guys, for example, have defined a standard
>>> interface to underlying OS
>>> and that's it. Therefore I don't think we really need the APR layer.
>
> Clarification, I did *not* write the above.
>
> Mladen, please make sure your cuts don't apply text out of context.
>
Sorry, Mea culpa.
Seems I was lost in the vivid discussion :)
Regards,
Mladen.
Re: Using APR for Harmony's native link to the OS?
Posted by Stefano Mazzocchi <st...@apache.org>.
Mladen Turk wrote:
> Enrico Migliore wrote:
>> Stefano Mazzocchi wrote:
>>
>> The GNU/Classpath guys, for example, have defined a standard interface
>> to underlying OS
>> and that's it. Therefore I don't think we really need the APR layer.
Clarification, I did *not* write the above.
Mladen, please make sure your cuts don't apply text out of context.
--
Stefano.
Re: Using APR for Harmony's native link to the OS?
Posted by Mladen Turk <mt...@apache.org>.
Enrico Migliore wrote:
> Mladen Turk wrote:
>>
> I wouldn't mind at all using a rock solid library like APR between the
> JVM and the OS.
> The only problem I see here is: "performance, in terms of execution speed".
>
OTOH, I thought it's more about quality :)
You can have as fast library as you wish, but if
can not open a simple unicode file, what's the purpose?
Also, what's the purpose of any JVM project if it needs
a cygwin to open a file?
Do you still think it's faster?
Regards,
Mladen.
Re: Using APR for Harmony's native link to the OS?
Posted by Stefano Mazzocchi <st...@apache.org>.
Enrico Migliore wrote:
> Mladen Turk wrote:
>
>> Enrico Migliore wrote:
>>
>>> Stefano Mazzocchi wrote:
>>>
>>> The GNU/Classpath guys, for example, have defined a standard
>>> interface to underlying OS
>>> and that's it. Therefore I don't think we really need the APR layer.
>>>
>>
>> Well, perhaps some day, someone will just 'brake' and
>> instead of loosing hair decide simply to build a better
>> thing then GNU/Classpath is.
>>
>> The only reason why it's still there is because no one
>> wrote something different, but the same thing applies
>> to the JVM thought.
>>
>> Regards,
>> Mladen.
>>
> I wouldn't mind at all using a rock solid library like APR between the
> JVM and the OS.
> The only problem I see here is: "performance, in terms of execution speed".
early optimization is the root to all evil, and I think it clearly
applies here.
--
Stefano.
Re: Using APR for Harmony's native link to the OS?
Posted by Enrico Migliore <en...@fatti.com>.
Mladen Turk wrote:
> Enrico Migliore wrote:
>
>> Stefano Mazzocchi wrote:
>>
>> The GNU/Classpath guys, for example, have defined a standard
>> interface to underlying OS
>> and that's it. Therefore I don't think we really need the APR layer.
>>
>
> Well, perhaps some day, someone will just 'brake' and
> instead of loosing hair decide simply to build a better
> thing then GNU/Classpath is.
>
> The only reason why it's still there is because no one
> wrote something different, but the same thing applies
> to the JVM thought.
>
> Regards,
> Mladen.
>
I wouldn't mind at all using a rock solid library like APR between the
JVM and the OS.
The only problem I see here is: "performance, in terms of execution speed".
Enrico
Re: Using APR for Harmony's native link to the OS?
Posted by Mladen Turk <mt...@apache.org>.
Enrico Migliore wrote:
> Stefano Mazzocchi wrote:
>
> The GNU/Classpath guys, for example, have defined a standard interface
> to underlying OS
> and that's it. Therefore I don't think we really need the APR layer.
>
Well, perhaps some day, someone will just 'brake' and
instead of loosing hair decide simply to build a better
thing then GNU/Classpath is.
The only reason why it's still there is because no one
wrote something different, but the same thing applies
to the JVM thought.
Regards,
Mladen.
Re: Using APR for Harmony's native link to the OS?
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Enrico Migliore wrote:
>
> As far as the the native code of the Classlib and the VM is concerned, I
> think that we should keep it
> as thinner as possible in order to:
>
> 1. have Java programs run fast
> 2. ease portability to different OS's and platforms (embedded
> systems included)
>
> The GNU/Classpath guys, for example, have defined a standard interface
> to underlying OS
> and that's it. Therefore I don't think we really need the APR layer.
I think where APR will help is in *implementing* that standard interface
for various platforms....
geir
Re: Using APR for Harmony's native link to the OS?
Posted by Enrico Migliore <en...@fatti.com>.
Stefano Mazzocchi wrote:
> tellison@apache.org wrote:
>
>> Author: tellison
>> Date: Fri Feb 10 05:57:38 2006
>> New Revision: 376690
>>
>> URL: http://svn.apache.org/viewcvs?rev=376690&view=rev
>> Log:
>> Applying patches received as HARMONY-42 (com.ibm.io.nio.FileChannel
>> is not fully implemented)
>> - refactoring of some java platform code
>> - additional behavior on NIO file channels
>> - refactoring of some IO code
>> - work in progress on memory mapping
>
>
> Tim's commits made me think about something that I thought about a
> loooooong time ago (probably 1999) in the "would be awesome" kind of
> department but I put off for a future where we would have a project to
> work on a JVM.
>
> turns out we do have one now and turns out that APR[1] is a library
> that is now very solid and reached API stability over years of work by
> a lot of people.
>
> so, here it is, does it make sense to have harmony depend on APR and
> therefore abstract away all those OS-specificities? (I'm talking about
> both the VM and the native part of the class library).
>
> It also has a major social side effects: it would create the ultimate
> social bridge between the HTTPD/APR side of the foundation and the
> java side of the foundation, maybe allowing people from one side to
> contribute to the other, or, at least to help out in the interface
> between them which naturally is the JVM.
>
> What do you think?
>
> [1] http://apr.apache.org/
>
I haven't gone through the APR library therefore I don't know how many
layers (i.e. function calls)
it puts between Apache and the underlying OS.
As far as the the native code of the Classlib and the VM is concerned, I
think that we should keep it
as thinner as possible in order to:
1. have Java programs run fast
2. ease portability to different OS's and platforms (embedded
systems included)
The GNU/Classpath guys, for example, have defined a standard interface
to underlying OS
and that's it. Therefore I don't think we really need the APR layer.
Enrico
Re: Using APR for Harmony's native link to the OS?
Posted by Leo Simons <ma...@leosimons.com>.
On Fri, Feb 10, 2006 at 04:40:03PM +0100, Mladen Turk wrote:
> Geir Magnusson Jr wrote:
> >
> >I've thought about this a while, and while I'm personally committed to
> >using APR wherever and whenever we can, I don't think it's wise to let
> >the APR tail wag the VM internal architecture dog, so to speak.
>
> Already there :)
> http://cvs.apache.org/viewcvs.cgi/tomcat/connectors/trunk/jni/
>
> All that is needed for example for socket or file api
> is a wrapper over org.apache.tomcat.jni.*
> What is most important, it works :)
That is just *too* cool. At a glance it looks like rather decent JNI
wrappers around a lot of APR stuff. Having worked a little with APR
recently, I'd expect core networking performance is several times that
of anything native-java-based?
Is there any more "developer-like" information on this implementation?
This is just so cool. This code is begging for some more attention,
exposure, use outside tomcat, etc.
Did I mention yet how cool this is?
LSD
Re: Using APR for Harmony's native link to the OS?
Posted by Mladen Turk <mt...@apache.org>.
Geir Magnusson Jr wrote:
>
>
> I've thought about this a while, and while I'm personally committed to
> using APR wherever and whenever we can, I don't think it's wise to let
> the APR tail wag the VM internal architecture dog, so to speak.
>
Already there :)
http://cvs.apache.org/viewcvs.cgi/tomcat/connectors/trunk/jni/
All that is needed for example for socket or file api
is a wrapper over org.apache.tomcat.jni.*
What is most important, it works :)
Regards,
Mladen.
Re: Using APR for Harmony's native link to the OS?
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Archie Cobbs wrote:
> Geir Magnusson Jr wrote:
>> I think that doing our implementations using APR is a solid way to go.
>> A good place to start looking is JCHEVM and BootVM...
>
> I haven't looked at APR in detail, but the O/S requirements of the VM
> proper are not that involved and I'm sure APR could handle them. There's
> probably more "corner case" requirements from the class library's native
> code, as that stuff implements most of Java's I/O, networking, etc.
Which wouldn't have an APR dependency....
>
> -Archie
>
> __________________________________________________________________________
> Archie Cobbs * CTO, Awarix * http://www.awarix.com
>
>
Re: Using APR for Harmony's native link to the OS?
Posted by Archie Cobbs <ar...@dellroad.org>.
Geir Magnusson Jr wrote:
> I think that doing our implementations using APR is a solid way to go. A
> good place to start looking is JCHEVM and BootVM...
I haven't looked at APR in detail, but the O/S requirements of the VM
proper are not that involved and I'm sure APR could handle them. There's
probably more "corner case" requirements from the class library's native
code, as that stuff implements most of Java's I/O, networking, etc.
-Archie
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com
Re: Using APR for Harmony's native link to the OS?
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Stefano Mazzocchi wrote:
> tellison@apache.org wrote:
>> Author: tellison
>> Date: Fri Feb 10 05:57:38 2006
>> New Revision: 376690
>>
>> URL: http://svn.apache.org/viewcvs?rev=376690&view=rev
>> Log:
>> Applying patches received as HARMONY-42 (com.ibm.io.nio.FileChannel is
>> not fully implemented)
>> - refactoring of some java platform code
>> - additional behavior on NIO file channels
>> - refactoring of some IO code
>> - work in progress on memory mapping
>
> Tim's commits made me think about something that I thought about a
> loooooong time ago (probably 1999) in the "would be awesome" kind of
> department but I put off for a future where we would have a project to
> work on a JVM.
>
> turns out we do have one now and turns out that APR[1] is a library that
> is now very solid and reached API stability over years of work by a lot
> of people.
>
> so, here it is, does it make sense to have harmony depend on APR and
> therefore abstract away all those OS-specificities? (I'm talking about
> both the VM and the native part of the class library).
I've thought about this a while, and while I'm personally committed to
using APR wherever and whenever we can, I don't think it's wise to let
the APR tail wag the VM internal architecture dog, so to speak.
For example, the VM should have resource requirements that APR doesn't
have, and that make no sense for general APR usage. (For example,
coordinating memory use between APR and the VM...)
I think that we need a clear 'interface' between the VM and the "OS
Abstraction Component", which I expect will then be implemented using
APR for every platform APR supports.
However, where there is no APR support for a platform, or someone wants
to do something differently, they can just (re) implement the "OS
Abstraction Compoment" as they see fit.
>
> It also has a major social side effects: it would create the ultimate
> social bridge between the HTTPD/APR side of the foundation and the java
> side of the foundation, maybe allowing people from one side to
> contribute to the other, or, at least to help out in the interface
> between them which naturally is the JVM.
>
> What do you think?
I think that doing our implementations using APR is a solid way to go.
A good place to start looking is JCHEVM and BootVM...
geir
Re: Using APR for Harmony's native link to the OS?
Posted by Mladen Turk <mt...@apache.org>.
Geir Magnusson Jr wrote:
>
> IOW, my guess is that if the Sun JVM used APR, nothing would change,
> because the problem is the standard Java APIs, not the integration of
> the VM w/ the OS services. My understanding is that the Tomcat peeps
> just found a more optimal path to the OS services they needed for their
> specific problem.
>
Not to mention that the IO layer is not covered with SCSL license,
and that there is no need to have platform-specific JNI code ;)
Of course, the current code covers more then standard Java API does,
like sendfile, shared memory, unix domain sockets, NT pipes, etc,
but that doesn't mean it's 'mandatory'.
If you remember, I spoke about developing classpath with APR as OS
abstraction layer, from Harmony start-up :)
Regards,
Mladen.
Re: Using APR for Harmony's native link to the OS?
Posted by Tim Ellison <t....@gmail.com>.
Stefano Mazzocchi wrote:
<snip>
> therefore, my suggestion is: instead of hooking our native stuff to the
> OS directly (or to the standard C libraries) we should hook them up to
> something that is a little more abstract and therefore reduces the
> effort of porting across OSes.
Have you seen the classlib port layer code that is already in Harmony?
http://svn.apache.org/viewcvs.cgi/*checkout*/incubator/harmony/enhanced/classlib/trunk/doc/vm_doc/html/group__Port.html
The existing natives(*) use this layer for all OS interaction. There is
a portlib implementation for Windows and Linux on IA32 in Harmony.
I'm no expert on APR, but I would expect that implementing the portlib
on APR would be no more difficult than implementing it on any other
platform.
(*) modulo the security2 native code
For classlib developers who need to twiddle bits, there is a set of
pluggable Java interfaces (called I{File|Memory|Network}System.java) here:
http://svn.apache.org/viewcvs.cgi/incubator/harmony/enhanced/classlib/trunk/modules/nio/src/main/java/com/ibm/platform/
Regards,
Tim
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
Re: Using APR for Harmony's native link to the OS?
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Stefano Mazzocchi wrote:
> Geir Magnusson Jr wrote:
>>
>>
>> Jim Jagielski wrote:
>>>
>>> On Feb 10, 2006, at 9:54 AM, Stefano Mazzocchi wrote:
>>>>
>>>> It also has a major social side effects: it would create the
>>>> ultimate social bridge between the HTTPD/APR side of the foundation
>>>> and the java side of the foundation, maybe allowing people from one
>>>> side to contribute to the other, or, at least to help out in the
>>>> interface between them which naturally is the JVM.
>>>>
>>>> What do you think?
>>>>
>>>
>>> Tomcat is APR aware via JNI (for connectors), and when it uses APR
>>> has some *very* appreciable enhancements :)
>>
>> Heh. The reason is because they are taking a different approach to
>> IO, right?
>>
>> IOW, my guess is that if the Sun JVM used APR, nothing would change,
>> because the problem is the standard Java APIs, not the integration of
>> the VM w/ the OS services. My understanding is that the Tomcat peeps
>> just found a more optimal path to the OS services they needed for
>> their specific problem.
>
> Geir, I'm not proposed we expose a java APR API instead of the standard
> java API, that's not the point.
I know.
>
> My point is that a JVM has a lot of native hooks, by design. And that
> those native hooks will have to be ported across operating systems and
> that APR was designed to separate those OS dependencies from the Apache
> 2 codebase so that the web server could be built with some sort of 'OS
> abstraction' in mind.
>
> therefore, my suggestion is: instead of hooking our native stuff to the
> OS directly (or to the standard C libraries) we should hook them up to
> something that is a little more abstract and therefore reduces the
> effort of porting across OSes.
Yes - understood.
That's the notion of the "OS Portability Interface" as part of the
modularity story. "If you implement these calls/interfaces/whatever,
you can plug that into the VM"
So I don't imagine we'd ever tie the VM to any given OS, but rather let
it be a pluggable thing, and I'd imagine that the "pluggable things"
that we write and distribute would be APR-powered. This lets us
leverage APR (we're fundamentally lazy, after all) yet still allow
people who dont' want to use APR or can't because of some issue on the
platform they are porting to to do what they need to.
>
> As you note, if we do this right, the java users wouldn't be able to
> tell a difference (if not, maybe, performance), but the difference would
> be in lowing the costs of porting the native code across different OSes.
Right.
>
> But then again, since I'm not the one doing the coding, I'll be happy to
> let do-ocracy take place.. I just thought I mentioned it since others
> might not know of APR's existance and Apache HTTPD and Tomcat
> connectors's dependency on it (which means it's there to stay and it's
> heavily maintained and licensing compatible)
I think that you are right on the money (modulo the VM's interface) and
I'd bet real money that we will be heavily dependent on - and
contributors to - APR in the near future.
geir
>
Re: Using APR for Harmony's native link to the OS?
Posted by Stefano Mazzocchi <st...@apache.org>.
Geir Magnusson Jr wrote:
>
>
> Jim Jagielski wrote:
>>
>> On Feb 10, 2006, at 9:54 AM, Stefano Mazzocchi wrote:
>>>
>>> It also has a major social side effects: it would create the ultimate
>>> social bridge between the HTTPD/APR side of the foundation and the
>>> java side of the foundation, maybe allowing people from one side to
>>> contribute to the other, or, at least to help out in the interface
>>> between them which naturally is the JVM.
>>>
>>> What do you think?
>>>
>>
>> Tomcat is APR aware via JNI (for connectors), and when it uses APR
>> has some *very* appreciable enhancements :)
>
> Heh. The reason is because they are taking a different approach to IO,
> right?
>
> IOW, my guess is that if the Sun JVM used APR, nothing would change,
> because the problem is the standard Java APIs, not the integration of
> the VM w/ the OS services. My understanding is that the Tomcat peeps
> just found a more optimal path to the OS services they needed for their
> specific problem.
Geir, I'm not proposed we expose a java APR API instead of the standard
java API, that's not the point.
My point is that a JVM has a lot of native hooks, by design. And that
those native hooks will have to be ported across operating systems and
that APR was designed to separate those OS dependencies from the Apache
2 codebase so that the web server could be built with some sort of 'OS
abstraction' in mind.
therefore, my suggestion is: instead of hooking our native stuff to the
OS directly (or to the standard C libraries) we should hook them up to
something that is a little more abstract and therefore reduces the
effort of porting across OSes.
As you note, if we do this right, the java users wouldn't be able to
tell a difference (if not, maybe, performance), but the difference would
be in lowing the costs of porting the native code across different OSes.
But then again, since I'm not the one doing the coding, I'll be happy to
let do-ocracy take place.. I just thought I mentioned it since others
might not know of APR's existance and Apache HTTPD and Tomcat
connectors's dependency on it (which means it's there to stay and it's
heavily maintained and licensing compatible)
--
Stefano.
Re: Using APR for Harmony's native link to the OS?
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Jim Jagielski wrote:
>
> On Feb 10, 2006, at 9:54 AM, Stefano Mazzocchi wrote:
>>
>> It also has a major social side effects: it would create the ultimate
>> social bridge between the HTTPD/APR side of the foundation and the
>> java side of the foundation, maybe allowing people from one side to
>> contribute to the other, or, at least to help out in the interface
>> between them which naturally is the JVM.
>>
>> What do you think?
>>
>
> Tomcat is APR aware via JNI (for connectors), and when it uses APR
> has some *very* appreciable enhancements :)
Heh. The reason is because they are taking a different approach to IO,
right?
IOW, my guess is that if the Sun JVM used APR, nothing would change,
because the problem is the standard Java APIs, not the integration of
the VM w/ the OS services. My understanding is that the Tomcat peeps
just found a more optimal path to the OS services they needed for their
specific problem.
geir
Re: Using APR for Harmony's native link to the OS?
Posted by Stefano Mazzocchi <st...@apache.org>.
Jim Jagielski wrote:
>
> On Feb 10, 2006, at 9:54 AM, Stefano Mazzocchi wrote:
>>
>> It also has a major social side effects: it would create the ultimate
>> social bridge between the HTTPD/APR side of the foundation and the
>> java side of the foundation, maybe allowing people from one side to
>> contribute to the other, or, at least to help out in the interface
>> between them which naturally is the JVM.
>>
>> What do you think?
>>
>
> Tomcat is APR aware via JNI (for connectors), and when it uses APR
> has some *very* appreciable enhancements :)
like what? (curious)
--
Stefano.
Re: Using APR for Harmony's native link to the OS?
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Feb 10, 2006, at 9:54 AM, Stefano Mazzocchi wrote:
>
> It also has a major social side effects: it would create the
> ultimate social bridge between the HTTPD/APR side of the foundation
> and the java side of the foundation, maybe allowing people from one
> side to contribute to the other, or, at least to help out in the
> interface between them which naturally is the JVM.
>
> What do you think?
>
Tomcat is APR aware via JNI (for connectors), and when it uses APR
has some *very* appreciable enhancements :)
Re: Using APR for Harmony's native link to the OS?
Posted by Paulex Yang <pa...@gmail.com>.
Artem Aliev wrote:
> Hello,
>
> I did some experiments with developing harmony portlib over APR.
> The main problem for me is an APR memory model.
> It is well suitable only for transactions.
>
> There is no free() memory call. You could destroy only whole memory pool.
> This works well only for short living threads or tasks. This is
> typical for HTTP server, not Java application. (All apr_*_create
> functions require apr_pool_t* as argument)
> I tried to create sub-pool for each object as workaround. This hits
> memory footprint and performance.
> So APR memory model should be extended. For example portlib memory
> pools could be integrated into APR.
>
Is this what you need?
http://apr.apache.org/docs/apr/group__apr__allocator.html
I just skimmed over the APR document, seems APR provides two memory
related modules, one is based on apr_pool_t, the other uses
apr_allocator_t, they can be linked by set apr_pool_t as owner of
apr_allocator_t, but I have no idea what it means, anyone can help?
anyway, the internal memory allocation functions(the one using
apr_allocator_t) seems OK as a memory model.
> The second problem is ugly "Developing wrappers over wrappers".
> For example, a call stack for read() method will look like following,
> in case we will develop Portlib over APR:
>
> Java_java_io_FileInputStream_read() calls
> portlib->hyfile_read(portLib...) calls
> apr_file_read(apr_file, ...) calls
> read(....) system calls.
>
> If we change portlib interface to be apr compatible, call stack could
> be a little bit better:
>
> Java_java_io_FileInputStream_read(...) calls
> portLib->apr_file_read(portLib->files[fd], ...) calls
> read(...) system calls.
>
> And definitely we will need to add a lot of new functions into APR.
>
Agree with you that APR may need many new functions to fully support VM and class library, as an example, Java NIO supports async socket IO by Selector and SelectableChannel, Harmony portlib provides native support to the select operation, but I cannot find direct support from APR(maybe just because I missed it, after all I'm a newbie to APR ;-) , anyway, just an example). But after all, maybe we don't need to implement everything in APR as well as portlib, what we should do at first is to specify a reasonable portlib interfaces which is just fit for the our needs. The current portlib is a pretty good base for discussion I think. Comments?
> Thank you,
> Artem Aliev
> Intel Middleware Products Division
>
>
--
Paulex Yang
China Software Development Lab
IBM
Re: Using APR for Harmony's native link to the OS?
Posted by Artem Aliev <ar...@gmail.com>.
> > I tried to create sub-pool for each object as workaround. This hits
> > memory footprint and performance.
>
> You are correct about that. There is no free call. Memory can
> be either reused by calling apr_pool_clear or freed by calling
> apr_pool_destroy.
> Because for any IO system object (file, socket, mutex, etc.)
> you usually need some additional struct, the standard implementation
> look like:
> struct my_struct;
> my_struct = malloc(...);
> my_truct->fh = open(...)
> ... do something with object
> close(my_truct->fh);
> free(my_struct);
>
> With APR it would look like:
>
> struct my_struct;
> pool = apr_pool_create(...)
> my_struct = apr_palloc(pool, ...)
> my_truct->fh = apr_xxx_open(pool, ...)
> ... do something with object
> apr_xxx_close(my_truct->fh);
> apr_pool_destroy(pool);
>
> Since each created object has it's own cleanup function
> when calling apr_pool_destroyed all objects created with
> that pool will call it's cleanup functions, so there is
> no need to call the apr_xxx_close.
>
I tried to do as you recommended: create pool for each portLib object.
The only problem here is a memory footprint.
Each apr_pool_create(...) allocates 8k memory: #define MIN_ALLOC 8192
Thus each portLib object costs 8k.
I would be happy with at least SUGGGESTED_SIZE parameter in
apr_pool_create() function.
APR_DECLARE(apr_status_t) apr_pool_create_ex(apr_pool_t **newpool,
apr_pool_t *parent,
apr_abortfunc_t abort_fn,
apr_allocator_t *allocator
apr_size_t SUGGGESTED_SIZE
Thank you,
Artem Aliev
Intel Middleware Products Division
Re: Using APR for Harmony's native link to the OS?
Posted by Mladen Turk <mt...@apache.org>.
Artem Aliev wrote:
> Hello,
>
> I did some experiments with developing harmony portlib over APR.
> The main problem for me is an APR memory model.
> It is well suitable only for transactions.
>
> There is no free() memory call. You could destroy only whole memory pool.
> This works well only for short living threads or tasks. This is
> typical for HTTP server, not Java application. (All apr_*_create
> functions require apr_pool_t* as argument)
> I tried to create sub-pool for each object as workaround. This hits
> memory footprint and performance.
You are correct about that. There is no free call. Memory can
be either reused by calling apr_pool_clear or freed by calling
apr_pool_destroy.
Because for any IO system object (file, socket, mutex, etc.)
you usually need some additional struct, the standard implementation
look like:
struct my_struct;
my_struct = malloc(...);
my_truct->fh = open(...)
... do something with object
close(my_truct->fh);
free(my_struct);
With APR it would look like:
struct my_struct;
pool = apr_pool_create(...)
my_struct = apr_palloc(pool, ...)
my_truct->fh = apr_xxx_open(pool, ...)
... do something with object
apr_xxx_close(my_truct->fh);
apr_pool_destroy(pool);
Since each created object has it's own cleanup function
when calling apr_pool_destroyed all objects created with
that pool will call it's cleanup functions, so there is
no need to call the apr_xxx_close.
> So APR memory model should be extended. For example portlib memory
> pools could be integrated into APR.
>
Not needed.
For any Java object you are actually always doing what apr_pool does
anyhow, meaning that during the object lifecycle you allocate memory
and on GC you must free all allocated resources.
If there is a need for short lived memory standard malloc/free can
be used (of course except for apr_* objects).
> The second problem is ugly "Developing wrappers over wrappers".
> For example, a call stack for read() method will look like following,
> in case we will develop Portlib over APR:
>
> Java_java_io_FileInputStream_read() calls
> portlib->hyfile_read(portLib...) calls
> apr_file_read(apr_file, ...) calls
> read(....) system calls.
>
Right, but on most systems 'read' is not a system call.
If you look at the source code for MSVCRT read, you'll see it's
much more complex then APR implementation.
Anyhow since APR is portable across majority of platforms,
there is no need to have the portlib->hyfile_read thought.
Regards,
Mladen.
Re: Using APR for Harmony's native link to the OS?
Posted by Archie Cobbs <ar...@dellroad.org>.
Artem Aliev wrote:
>> You can always still use plain old malloc(), right?
>
> Unfortunately, all apr_*_create functions require apr_pool_t* as argument.
I meant, if you have some function that just needs to allocate some
heap memory temporarily, you can use malloc() directly .. as if APR
were not even present. I.e., you don't have to use APR for *everything*.
-Archie
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com
Re: Using APR for Harmony's native link to the OS?
Posted by Artem Aliev <ar...@gmail.com>.
> You can always still use plain old malloc(), right?
Unfortunately, all apr_*_create functions require apr_pool_t* as argument.
For example:
APR_DECLARE(apr_status_t) apr_file_open(apr_file_t **newf, const char *fname,
apr_int32_t flag, apr_fileperms_t perm,
apr_pool_t *pool);
APR_DECLARE(apr_status_t) apr_mmap_create(apr_mmap_t **newmmap,
apr_file_t *file, apr_off_t offset,
apr_size_t size, apr_int32_t flag,
apr_pool_t *cntxt);
APR_DECLARE(apr_status_t) apr_thread_mutex_create(apr_thread_mutex_t **mutex,
unsigned int flags,
apr_pool_t *pool);
Thank you,
Artem Aliev
Intel Middleware Products Division
Re: Using APR for Harmony's native link to the OS?
Posted by Archie Cobbs <ar...@dellroad.org>.
Artem Aliev wrote:
> There is no free() memory call. You could destroy only whole memory pool.
> This works well only for short living threads or tasks. This is
> typical for HTTP server, not Java application. (All apr_*_create
> functions require apr_pool_t* as argument)
> I tried to create sub-pool for each object as workaround. This hits
> memory footprint and performance.
> So APR memory model should be extended. For example portlib memory
> pools could be integrated into APR.
You can always still use plain old malloc(), right?
-Archie
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com
Re: Using APR for Harmony's native link to the OS?
Posted by Artem Aliev <ar...@gmail.com>.
Hello,
I did some experiments with developing harmony portlib over APR.
The main problem for me is an APR memory model.
It is well suitable only for transactions.
There is no free() memory call. You could destroy only whole memory pool.
This works well only for short living threads or tasks. This is
typical for HTTP server, not Java application. (All apr_*_create
functions require apr_pool_t* as argument)
I tried to create sub-pool for each object as workaround. This hits
memory footprint and performance.
So APR memory model should be extended. For example portlib memory
pools could be integrated into APR.
The second problem is ugly "Developing wrappers over wrappers".
For example, a call stack for read() method will look like following,
in case we will develop Portlib over APR:
Java_java_io_FileInputStream_read() calls
portlib->hyfile_read(portLib...) calls
apr_file_read(apr_file, ...) calls
read(....) system calls.
If we change portlib interface to be apr compatible, call stack could
be a little bit better:
Java_java_io_FileInputStream_read(...) calls
portLib->apr_file_read(portLib->files[fd], ...) calls
read(...) system calls.
And definitely we will need to add a lot of new functions into APR.
Thank you,
Artem Aliev
Intel Middleware Products Division
Re: Using APR for Harmony's native link to the OS?
Posted by Paulex Yang <pa...@gmail.com>.
Another advantages of portlib is that its function implementation can be
easily replaced without recompiling the entire JVM, copied its document
from [1] below:
<quote>
The port library is implemented as a table of function pointers. One
advantage of a function pointer based table is the ability to replace
any functionality without recompiling the entire Java virtual machine.
For example if an application is experiencing a memory leak, the memory
management functions of the port library can be replaced to help
determine the root cause of this leak. Alternatively applications
wishing to control all memory allocation can provide their own routines
to override the platform specific allocation and deallocation of memory.
Various implementations of the port library may choose not to implement
all functionality contained in the port library table. If a platform
does not support sockets, and thus the Java virtual machine does not
utilize sockets, the port library does not need to provide a valid
socket behavior. The port library contains version control information
that enables applications to determine if required functionality is
supported. In addition the version control information allows
applications to determine if the port library provided is compatible
with the one which they were compiled against.
</quote>
Tim Ellison wrote:
> As I wrote earlier, I agree. Implementing the Harmony portability layer
> to run on APR is a good idea (volunteers?).
>
> The Harmony portlib [1] itself has some interesting characteristics that
> I would not want to loose by programming Java natives straight to APR.
>
> The portlib is a table of function pointers that is linked to a
> particular VM instance. Each function in turn has a parameter that is
> the function table it should use; and all this is wrapped up in some
> syntactic sugar to make palatable to the programmer.
>
> This means that an application that creates multiple VM's in the same
> process (i.e. repeated calls to JNI_CreateJavaVM) has the option to keep
> the resource management separated. It can ensure that one VM does not
> grab the entire OS heap, or that the resources are allocated a given
> security sandbox, or (heaven-forbid) if the VM abends it can clean-up
> just that VM's resources. It also makes things like tracing much
> easier, since you can augment a function at any given point by replacing
> it in the function table, and have that augmented function used by all
> downstream callers. This scenario will be familiar to the app server
> crowd, who want to run multiple VMs inside a webserver for example.
>
>
> Here's how it looks from a JNI programmer's pov [2]:
> ================================================
> void JNICALL
> Java_java_net_Socket_socketCloseImpl (JNIEnv * env,
> jclass thisClz,
> jobject fileDescriptor)
> {
> PORT_ACCESS_FROM_ENV (env);
> hysocket_t socketP;
>
> socketP = getJavaIoFileDescriptorContentsAsPointer (env,
> fileDescriptor);
> if (hysock_socketIsValid (socketP))
> {
> /* Set the file descriptor before closing so the select
> polling loop will terminate. */
> /* Some platforms wait in the socket close. */
> setJavaIoFileDescriptorContentsAsPointer (env, fileDescriptor,
> (void *) -1);
> hysock_close (&socketP);
> }
> }
> ================================================
>
>
> The "PORT_ACCESS_FROM_ENV(env)" is a macro that reaches into the JNIEnv
> and gets the table of function pointers[3].
>
> #define PORT_ACCESS_FROM_ENV(jniEnv) \
> VMInterface *portPrivateVMI = VMI_GetVMIFromJNIEnv(jniEnv); \
> HyPortLibrary *privatePortLibrary = \
> (*portPrivateVMI)->GetPortLibrary(portPrivateVMI)
>
> After that you could tweak it if you choose, but this function doesn't.
> Then calls to 'functions' like "hysock_socketIsValid" and
> "hysock_close" are actually macros that expand out into offsets into the
> function table, and passing the function table down;
> i.e.
> hysock_socketIsValid (socketP)
>
> expands as follows [3]
>
> #define hysock_socketIsValid(param1) \
> privatePortLibrary->sock_socketIsValid(privatePortLibrary,param1)
>
>
> You can see where this is going. The implementation of
> sock_socketIsValid inherits the caller's view of the portlib, and so on.
> The on-line doc describes it here [1]. While we would normally also
> use the portlayer as the OS porting layer, implementing this on APR
> would be a GoodThing too.
>
>
> [1]
> http://svn.apache.org/viewcvs.cgi/*checkout*/incubator/harmony/enhanced/classlib/trunk/doc/vm_doc/html/group__Port.html
> [2] taken from
> http://svn.apache.org/viewcvs.cgi/incubator/harmony/enhanced/classlib/trunk/native-src/linux.IA32/luni/socket.c?view=markup
> [3] look in
> http://svn.apache.org/viewcvs.cgi/incubator/harmony/enhanced/classlib/trunk/native-src/linux.IA32/include/hyport.h?view=markup
>
>
> Regards,
> Tim
>
> Alexey Petrenko wrote:
>
>>> What do you think?
>>>
>> I think that's using Apache Portable Runtime in Apache Harmony is
>> natural and good idea.
>>
>> However we should understand that APR does not have ALL the needed
>> functionality. For example APR does not have graphical and window
>> management functions. So at least awt will need to use OS dependent
>> native code.
>>
>> --
>> Alexey A. Petrenko
>> Intel Middleware Products Division
>>
>
>
--
Paulex Yang
China Software Development Lab
IBM
Re: Using APR for Harmony's native link to the OS?
Posted by Tim Ellison <t....@gmail.com>.
As I wrote earlier, I agree. Implementing the Harmony portability layer
to run on APR is a good idea (volunteers?).
The Harmony portlib [1] itself has some interesting characteristics that
I would not want to loose by programming Java natives straight to APR.
The portlib is a table of function pointers that is linked to a
particular VM instance. Each function in turn has a parameter that is
the function table it should use; and all this is wrapped up in some
syntactic sugar to make palatable to the programmer.
This means that an application that creates multiple VM's in the same
process (i.e. repeated calls to JNI_CreateJavaVM) has the option to keep
the resource management separated. It can ensure that one VM does not
grab the entire OS heap, or that the resources are allocated a given
security sandbox, or (heaven-forbid) if the VM abends it can clean-up
just that VM's resources. It also makes things like tracing much
easier, since you can augment a function at any given point by replacing
it in the function table, and have that augmented function used by all
downstream callers. This scenario will be familiar to the app server
crowd, who want to run multiple VMs inside a webserver for example.
Here's how it looks from a JNI programmer's pov [2]:
================================================
void JNICALL
Java_java_net_Socket_socketCloseImpl (JNIEnv * env,
jclass thisClz,
jobject fileDescriptor)
{
PORT_ACCESS_FROM_ENV (env);
hysocket_t socketP;
socketP = getJavaIoFileDescriptorContentsAsPointer (env,
fileDescriptor);
if (hysock_socketIsValid (socketP))
{
/* Set the file descriptor before closing so the select
polling loop will terminate. */
/* Some platforms wait in the socket close. */
setJavaIoFileDescriptorContentsAsPointer (env, fileDescriptor,
(void *) -1);
hysock_close (&socketP);
}
}
================================================
The "PORT_ACCESS_FROM_ENV(env)" is a macro that reaches into the JNIEnv
and gets the table of function pointers[3].
#define PORT_ACCESS_FROM_ENV(jniEnv) \
VMInterface *portPrivateVMI = VMI_GetVMIFromJNIEnv(jniEnv); \
HyPortLibrary *privatePortLibrary = \
(*portPrivateVMI)->GetPortLibrary(portPrivateVMI)
After that you could tweak it if you choose, but this function doesn't.
Then calls to 'functions' like "hysock_socketIsValid" and
"hysock_close" are actually macros that expand out into offsets into the
function table, and passing the function table down;
i.e.
hysock_socketIsValid (socketP)
expands as follows [3]
#define hysock_socketIsValid(param1) \
privatePortLibrary->sock_socketIsValid(privatePortLibrary,param1)
You can see where this is going. The implementation of
sock_socketIsValid inherits the caller's view of the portlib, and so on.
The on-line doc describes it here [1]. While we would normally also
use the portlayer as the OS porting layer, implementing this on APR
would be a GoodThing too.
[1]
http://svn.apache.org/viewcvs.cgi/*checkout*/incubator/harmony/enhanced/classlib/trunk/doc/vm_doc/html/group__Port.html
[2] taken from
http://svn.apache.org/viewcvs.cgi/incubator/harmony/enhanced/classlib/trunk/native-src/linux.IA32/luni/socket.c?view=markup
[3] look in
http://svn.apache.org/viewcvs.cgi/incubator/harmony/enhanced/classlib/trunk/native-src/linux.IA32/include/hyport.h?view=markup
Regards,
Tim
Alexey Petrenko wrote:
>> What do you think?
> I think that's using Apache Portable Runtime in Apache Harmony is
> natural and good idea.
>
> However we should understand that APR does not have ALL the needed
> functionality. For example APR does not have graphical and window
> management functions. So at least awt will need to use OS dependent
> native code.
>
> --
> Alexey A. Petrenko
> Intel Middleware Products Division
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
Re: Using Cairo for Harmony graphic stuff?
Posted by Leo Simons <ma...@leosimons.com>.
On Sat, Feb 11, 2006 at 12:08:55PM -0500, Stefano Mazzocchi wrote:
> Ryan Bloom wrote:
> >As one of the original authors of APR, I would like to suggest that
> >instead of using OS dependant native code, when we get to the point of
> >writing awt, we should create an apr-window project, and create the
> >library for the abstraction layer. I have had enough conversations
> >with other APR developers to be relatively certain that this idea
> >would be well received.
Whoah, that's a load of work you're describing there! :-)
> Hi Ryan, nice to see you around here.
>
> I'm happy that Enrico has changed his mind about APR and I would also be
> in favor of harmony committing back code to APR.
>
> Another think that I wonder, for the windowing stuff, why don't we use
> Cairo[1]?
>
> Firefox 2.0 is going to be based on it, so you would expect lots of
> polishing/fixing/profiling/OS-portability going on on that front that we
> would just reuse and it's dual-licensed under LGPL or MPL 1.1, so if we
> release it under the MPL 1.1 license it's also compatible.
>
> What do you think?
Thought about it. I would've mention that the Java-GNOME people are
working on an AWT peer for Cairo and have a sizeable amount of the
java bindings already done (http://cvs.cairographics.org/cairo-java/),
but I don't wan't to cause more mudslinging...
- LSD
Re: Using Cairo for Harmony graphic stuff?
Posted by Stefano Mazzocchi <st...@apache.org>.
Tim Ellison wrote:
> ... or the sound a user makes when they see a Swing app start up.
ROTFL :-)
> Tim
>
> Davanum Srinivas wrote:
>> Pluggable look and feel
>> (http://java.sun.com/j2se/1.4.2/docs/api/javax/swing/plaf/package-summary.html)
>>
>> -- dims
>>
>> On 2/14/06, Stefano Mazzocchi <st...@apache.org> wrote:
>>> Anton Avtamonov wrote:
>>>> Yeah, thank you Tim.
>>>>
>>>> I also thought about SwingWT when saw Stefano's letter.
>>>> Unfortunately such approach have serious problem with supporting PLAF
>>>> concept, as I know :-(, but really very fast (thanks to swt :-))
>>> what's PLAF?
>>>
>>>> --
>>>> Anton Avtamonov,
>>>> Intel Middleware Products Division
>>>>
>>>>
>>>> On 2/13/06, Tim Ellison <t....@gmail.com> wrote:
>>>>> http://swingwt.sourceforge.net/
>>>>>
>>>>> (I merely mention it, not recommending it)
>>>>>
>>>>> Regards,
>>>>> Tim
>>>>>
>>>>> Stefano Mazzocchi wrote:
>>>>>> Anton Avtamonov wrote:
>>>>>>> On 2/13/06, Stefano Mazzocchi <st...@apache.org> wrote:
>>>>>>> [snip]
>>>>>>>> The other thing to consider is to follow apple's advice and implement
>>>>>>>> Swing using native widgets. I don't know what this entails in terms of
>>>>>>>> complexity but I always found stupid that swing is barely scratching the
>>>>>>>> surface of what my GPU accelerator could do for me.
>>>>>>>>
>>>>>>> [snip]
>>>>>>>> --
>>>>>>>> Stefano.
>>>>>>>>
>>>>>>> Hi Stefano,
>>>>>>>
>>>>>>> Am I right you propose to implement Swing on native widgets? I mean
>>>>>>> using real native push buttons, etc. and get rid of 'standard' Swing
>>>>>>> approach to have lightweight platform-independent stuff? Sorry if I
>>>>>>> caught you wrong...
>>>>>> I don't even know what I'm saying myself :-)
>>>>>>
>>>>>> All I know is that I want something fast that feels as solid as SWT on
>>>>>> windows or swing/java2d on macosx.
>>>>>>
>>>>>> Unfortunately, I don't think I know enough how to figure out how to get
>>>>>> there though, but I suspect you guys do ;-)
>>>>>>
>>>>> --
>>>>>
>>>>> Tim Ellison (t.p.ellison@gmail.com)
>>>>> IBM Java technology centre, UK.
>>>>>
>>> --
>>> Stefano.
>>>
>>>
>>
>> --
>> Davanum Srinivas : http://wso2.com/blogs/
>>
>
--
Stefano.
Re: Using Cairo for Harmony graphic stuff?
Posted by Tim Ellison <t....@gmail.com>.
... or the sound a user makes when they see a Swing app start up.
Tim
Davanum Srinivas wrote:
> Pluggable look and feel
> (http://java.sun.com/j2se/1.4.2/docs/api/javax/swing/plaf/package-summary.html)
>
> -- dims
>
> On 2/14/06, Stefano Mazzocchi <st...@apache.org> wrote:
>> Anton Avtamonov wrote:
>>> Yeah, thank you Tim.
>>>
>>> I also thought about SwingWT when saw Stefano's letter.
>>> Unfortunately such approach have serious problem with supporting PLAF
>>> concept, as I know :-(, but really very fast (thanks to swt :-))
>> what's PLAF?
>>
>>> --
>>> Anton Avtamonov,
>>> Intel Middleware Products Division
>>>
>>>
>>> On 2/13/06, Tim Ellison <t....@gmail.com> wrote:
>>>> http://swingwt.sourceforge.net/
>>>>
>>>> (I merely mention it, not recommending it)
>>>>
>>>> Regards,
>>>> Tim
>>>>
>>>> Stefano Mazzocchi wrote:
>>>>> Anton Avtamonov wrote:
>>>>>> On 2/13/06, Stefano Mazzocchi <st...@apache.org> wrote:
>>>>>> [snip]
>>>>>>> The other thing to consider is to follow apple's advice and implement
>>>>>>> Swing using native widgets. I don't know what this entails in terms of
>>>>>>> complexity but I always found stupid that swing is barely scratching the
>>>>>>> surface of what my GPU accelerator could do for me.
>>>>>>>
>>>>>> [snip]
>>>>>>> --
>>>>>>> Stefano.
>>>>>>>
>>>>>> Hi Stefano,
>>>>>>
>>>>>> Am I right you propose to implement Swing on native widgets? I mean
>>>>>> using real native push buttons, etc. and get rid of 'standard' Swing
>>>>>> approach to have lightweight platform-independent stuff? Sorry if I
>>>>>> caught you wrong...
>>>>> I don't even know what I'm saying myself :-)
>>>>>
>>>>> All I know is that I want something fast that feels as solid as SWT on
>>>>> windows or swing/java2d on macosx.
>>>>>
>>>>> Unfortunately, I don't think I know enough how to figure out how to get
>>>>> there though, but I suspect you guys do ;-)
>>>>>
>>>> --
>>>>
>>>> Tim Ellison (t.p.ellison@gmail.com)
>>>> IBM Java technology centre, UK.
>>>>
>>
>> --
>> Stefano.
>>
>>
>
>
> --
> Davanum Srinivas : http://wso2.com/blogs/
>
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
Re: Using Cairo for Harmony graphic stuff?
Posted by Davanum Srinivas <da...@gmail.com>.
Pluggable look and feel
(http://java.sun.com/j2se/1.4.2/docs/api/javax/swing/plaf/package-summary.html)
-- dims
On 2/14/06, Stefano Mazzocchi <st...@apache.org> wrote:
> Anton Avtamonov wrote:
> > Yeah, thank you Tim.
> >
> > I also thought about SwingWT when saw Stefano's letter.
> > Unfortunately such approach have serious problem with supporting PLAF
> > concept, as I know :-(, but really very fast (thanks to swt :-))
>
> what's PLAF?
>
> >
> > --
> > Anton Avtamonov,
> > Intel Middleware Products Division
> >
> >
> > On 2/13/06, Tim Ellison <t....@gmail.com> wrote:
> >> http://swingwt.sourceforge.net/
> >>
> >> (I merely mention it, not recommending it)
> >>
> >> Regards,
> >> Tim
> >>
> >> Stefano Mazzocchi wrote:
> >>> Anton Avtamonov wrote:
> >>>> On 2/13/06, Stefano Mazzocchi <st...@apache.org> wrote:
> >>>> [snip]
> >>>>> The other thing to consider is to follow apple's advice and implement
> >>>>> Swing using native widgets. I don't know what this entails in terms of
> >>>>> complexity but I always found stupid that swing is barely scratching the
> >>>>> surface of what my GPU accelerator could do for me.
> >>>>>
> >>>> [snip]
> >>>>> --
> >>>>> Stefano.
> >>>>>
> >>>> Hi Stefano,
> >>>>
> >>>> Am I right you propose to implement Swing on native widgets? I mean
> >>>> using real native push buttons, etc. and get rid of 'standard' Swing
> >>>> approach to have lightweight platform-independent stuff? Sorry if I
> >>>> caught you wrong...
> >>> I don't even know what I'm saying myself :-)
> >>>
> >>> All I know is that I want something fast that feels as solid as SWT on
> >>> windows or swing/java2d on macosx.
> >>>
> >>> Unfortunately, I don't think I know enough how to figure out how to get
> >>> there though, but I suspect you guys do ;-)
> >>>
> >> --
> >>
> >> Tim Ellison (t.p.ellison@gmail.com)
> >> IBM Java technology centre, UK.
> >>
>
>
> --
> Stefano.
>
>
--
Davanum Srinivas : http://wso2.com/blogs/
Re: Using Cairo for Harmony graphic stuff?
Posted by Davanum Srinivas <da...@gmail.com>.
hehe :) good one for those uninitiated...that's with an 'i' like so
(http://images.google.com/images?hl=en&q=pilaf)
-- dims
On 2/14/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
> Isn't it a rice dish?
>
> Stefano Mazzocchi wrote:
> > Anton Avtamonov wrote:
> >> Yeah, thank you Tim.
> >>
> >> I also thought about SwingWT when saw Stefano's letter.
> >> Unfortunately such approach have serious problem with supporting PLAF
> >> concept, as I know :-(, but really very fast (thanks to swt :-))
> >
> > what's PLAF?
> >
> >>
> >> --
> >> Anton Avtamonov,
> >> Intel Middleware Products Division
> >>
> >>
> >> On 2/13/06, Tim Ellison <t....@gmail.com> wrote:
> >>> http://swingwt.sourceforge.net/
> >>>
> >>> (I merely mention it, not recommending it)
> >>>
> >>> Regards,
> >>> Tim
> >>>
> >>> Stefano Mazzocchi wrote:
> >>>> Anton Avtamonov wrote:
> >>>>> On 2/13/06, Stefano Mazzocchi <st...@apache.org> wrote:
> >>>>> [snip]
> >>>>>> The other thing to consider is to follow apple's advice and implement
> >>>>>> Swing using native widgets. I don't know what this entails in
> >>>>>> terms of
> >>>>>> complexity but I always found stupid that swing is barely
> >>>>>> scratching the
> >>>>>> surface of what my GPU accelerator could do for me.
> >>>>>>
> >>>>> [snip]
> >>>>>> --
> >>>>>> Stefano.
> >>>>>>
> >>>>> Hi Stefano,
> >>>>>
> >>>>> Am I right you propose to implement Swing on native widgets? I mean
> >>>>> using real native push buttons, etc. and get rid of 'standard' Swing
> >>>>> approach to have lightweight platform-independent stuff? Sorry if I
> >>>>> caught you wrong...
> >>>> I don't even know what I'm saying myself :-)
> >>>>
> >>>> All I know is that I want something fast that feels as solid as SWT on
> >>>> windows or swing/java2d on macosx.
> >>>>
> >>>> Unfortunately, I don't think I know enough how to figure out how to get
> >>>> there though, but I suspect you guys do ;-)
> >>>>
> >>> --
> >>>
> >>> Tim Ellison (t.p.ellison@gmail.com)
> >>> IBM Java technology centre, UK.
> >>>
> >
> >
>
--
Davanum Srinivas : http://wso2.com/blogs/
Re: Using Cairo for Harmony graphic stuff?
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Isn't it a rice dish?
Stefano Mazzocchi wrote:
> Anton Avtamonov wrote:
>> Yeah, thank you Tim.
>>
>> I also thought about SwingWT when saw Stefano's letter.
>> Unfortunately such approach have serious problem with supporting PLAF
>> concept, as I know :-(, but really very fast (thanks to swt :-))
>
> what's PLAF?
>
>>
>> --
>> Anton Avtamonov,
>> Intel Middleware Products Division
>>
>>
>> On 2/13/06, Tim Ellison <t....@gmail.com> wrote:
>>> http://swingwt.sourceforge.net/
>>>
>>> (I merely mention it, not recommending it)
>>>
>>> Regards,
>>> Tim
>>>
>>> Stefano Mazzocchi wrote:
>>>> Anton Avtamonov wrote:
>>>>> On 2/13/06, Stefano Mazzocchi <st...@apache.org> wrote:
>>>>> [snip]
>>>>>> The other thing to consider is to follow apple's advice and implement
>>>>>> Swing using native widgets. I don't know what this entails in
>>>>>> terms of
>>>>>> complexity but I always found stupid that swing is barely
>>>>>> scratching the
>>>>>> surface of what my GPU accelerator could do for me.
>>>>>>
>>>>> [snip]
>>>>>> --
>>>>>> Stefano.
>>>>>>
>>>>> Hi Stefano,
>>>>>
>>>>> Am I right you propose to implement Swing on native widgets? I mean
>>>>> using real native push buttons, etc. and get rid of 'standard' Swing
>>>>> approach to have lightweight platform-independent stuff? Sorry if I
>>>>> caught you wrong...
>>>> I don't even know what I'm saying myself :-)
>>>>
>>>> All I know is that I want something fast that feels as solid as SWT on
>>>> windows or swing/java2d on macosx.
>>>>
>>>> Unfortunately, I don't think I know enough how to figure out how to get
>>>> there though, but I suspect you guys do ;-)
>>>>
>>> --
>>>
>>> Tim Ellison (t.p.ellison@gmail.com)
>>> IBM Java technology centre, UK.
>>>
>
>
Re: Using Cairo for Harmony graphic stuff?
Posted by Stefano Mazzocchi <st...@apache.org>.
Anton Avtamonov wrote:
> Yeah, thank you Tim.
>
> I also thought about SwingWT when saw Stefano's letter.
> Unfortunately such approach have serious problem with supporting PLAF
> concept, as I know :-(, but really very fast (thanks to swt :-))
what's PLAF?
>
> --
> Anton Avtamonov,
> Intel Middleware Products Division
>
>
> On 2/13/06, Tim Ellison <t....@gmail.com> wrote:
>> http://swingwt.sourceforge.net/
>>
>> (I merely mention it, not recommending it)
>>
>> Regards,
>> Tim
>>
>> Stefano Mazzocchi wrote:
>>> Anton Avtamonov wrote:
>>>> On 2/13/06, Stefano Mazzocchi <st...@apache.org> wrote:
>>>> [snip]
>>>>> The other thing to consider is to follow apple's advice and implement
>>>>> Swing using native widgets. I don't know what this entails in terms of
>>>>> complexity but I always found stupid that swing is barely scratching the
>>>>> surface of what my GPU accelerator could do for me.
>>>>>
>>>> [snip]
>>>>> --
>>>>> Stefano.
>>>>>
>>>> Hi Stefano,
>>>>
>>>> Am I right you propose to implement Swing on native widgets? I mean
>>>> using real native push buttons, etc. and get rid of 'standard' Swing
>>>> approach to have lightweight platform-independent stuff? Sorry if I
>>>> caught you wrong...
>>> I don't even know what I'm saying myself :-)
>>>
>>> All I know is that I want something fast that feels as solid as SWT on
>>> windows or swing/java2d on macosx.
>>>
>>> Unfortunately, I don't think I know enough how to figure out how to get
>>> there though, but I suspect you guys do ;-)
>>>
>> --
>>
>> Tim Ellison (t.p.ellison@gmail.com)
>> IBM Java technology centre, UK.
>>
--
Stefano.
Re: Using Cairo for Harmony graphic stuff?
Posted by Anton Avtamonov <an...@gmail.com>.
Yeah, thank you Tim.
I also thought about SwingWT when saw Stefano's letter.
Unfortunately such approach have serious problem with supporting PLAF
concept, as I know :-(, but really very fast (thanks to swt :-))
--
Anton Avtamonov,
Intel Middleware Products Division
On 2/13/06, Tim Ellison <t....@gmail.com> wrote:
> http://swingwt.sourceforge.net/
>
> (I merely mention it, not recommending it)
>
> Regards,
> Tim
>
> Stefano Mazzocchi wrote:
> > Anton Avtamonov wrote:
> >> On 2/13/06, Stefano Mazzocchi <st...@apache.org> wrote:
> >> [snip]
> >>> The other thing to consider is to follow apple's advice and implement
> >>> Swing using native widgets. I don't know what this entails in terms of
> >>> complexity but I always found stupid that swing is barely scratching the
> >>> surface of what my GPU accelerator could do for me.
> >>>
> >> [snip]
> >>> --
> >>> Stefano.
> >>>
> >>
> >> Hi Stefano,
> >>
> >> Am I right you propose to implement Swing on native widgets? I mean
> >> using real native push buttons, etc. and get rid of 'standard' Swing
> >> approach to have lightweight platform-independent stuff? Sorry if I
> >> caught you wrong...
> >
> > I don't even know what I'm saying myself :-)
> >
> > All I know is that I want something fast that feels as solid as SWT on
> > windows or swing/java2d on macosx.
> >
> > Unfortunately, I don't think I know enough how to figure out how to get
> > there though, but I suspect you guys do ;-)
> >
>
> --
>
> Tim Ellison (t.p.ellison@gmail.com)
> IBM Java technology centre, UK.
>
Re: Using Cairo for Harmony graphic stuff?
Posted by Tim Ellison <t....@gmail.com>.
http://swingwt.sourceforge.net/
(I merely mention it, not recommending it)
Regards,
Tim
Stefano Mazzocchi wrote:
> Anton Avtamonov wrote:
>> On 2/13/06, Stefano Mazzocchi <st...@apache.org> wrote:
>> [snip]
>>> The other thing to consider is to follow apple's advice and implement
>>> Swing using native widgets. I don't know what this entails in terms of
>>> complexity but I always found stupid that swing is barely scratching the
>>> surface of what my GPU accelerator could do for me.
>>>
>> [snip]
>>> --
>>> Stefano.
>>>
>>
>> Hi Stefano,
>>
>> Am I right you propose to implement Swing on native widgets? I mean
>> using real native push buttons, etc. and get rid of 'standard' Swing
>> approach to have lightweight platform-independent stuff? Sorry if I
>> caught you wrong...
>
> I don't even know what I'm saying myself :-)
>
> All I know is that I want something fast that feels as solid as SWT on
> windows or swing/java2d on macosx.
>
> Unfortunately, I don't think I know enough how to figure out how to get
> there though, but I suspect you guys do ;-)
>
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
Re: Using Cairo for Harmony graphic stuff?
Posted by Stefano Mazzocchi <st...@apache.org>.
Anton Avtamonov wrote:
> On 2/13/06, Stefano Mazzocchi <st...@apache.org> wrote:
> [snip]
>> The other thing to consider is to follow apple's advice and implement
>> Swing using native widgets. I don't know what this entails in terms of
>> complexity but I always found stupid that swing is barely scratching the
>> surface of what my GPU accelerator could do for me.
>>
> [snip]
>> --
>> Stefano.
>>
>
> Hi Stefano,
>
> Am I right you propose to implement Swing on native widgets? I mean
> using real native push buttons, etc. and get rid of 'standard' Swing
> approach to have lightweight platform-independent stuff? Sorry if I
> caught you wrong...
I don't even know what I'm saying myself :-)
All I know is that I want something fast that feels as solid as SWT on
windows or swing/java2d on macosx.
Unfortunately, I don't think I know enough how to figure out how to get
there though, but I suspect you guys do ;-)
--
Stefano.
Re: Using Cairo for Harmony graphic stuff?
Posted by Anton Avtamonov <an...@gmail.com>.
On 2/13/06, Stefano Mazzocchi <st...@apache.org> wrote:
[snip]
> The other thing to consider is to follow apple's advice and implement
> Swing using native widgets. I don't know what this entails in terms of
> complexity but I always found stupid that swing is barely scratching the
> surface of what my GPU accelerator could do for me.
>
[snip]
> --
> Stefano.
>
Hi Stefano,
Am I right you propose to implement Swing on native widgets? I mean
using real native push buttons, etc. and get rid of 'standard' Swing
approach to have lightweight platform-independent stuff? Sorry if I
caught you wrong...
--
Anton Avtamonov,
Intel Middleware Products Division
Re: Using Cairo for Harmony graphic stuff?
Posted by Stefano Mazzocchi <st...@apache.org>.
Alexey Petrenko wrote:
> I'll check the Cairo. Thanks for pointing...
my pleasure.
>> Well, that Graphics object at some points needs rendering to the screen
>> doesn't it? :-)
> Yep. :)
> But Graphics object is a small part of AWT...
agreed, yet having a solid and hardware accelerated graphics part (I'm
thinking java2d mostly) would make me *very* happy.
The other thing to consider is to follow apple's advice and implement
Swing using native widgets. I don't know what this entails in terms of
complexity but I always found stupid that swing is barely scratching the
surface of what my GPU accelerator could do for me.
Anyway, I suggest we focus on server side stuff first anyway.
--
Stefano.
Re: Using Cairo for Harmony graphic stuff?
Posted by Alexey Petrenko <al...@gmail.com>.
I'll check the Cairo. Thanks for pointing...
> Well, that Graphics object at some points needs rendering to the screen
> doesn't it? :-)
Yep. :)
But Graphics object is a small part of AWT...
--
Alexey A. Petrenko
Intel Middleware Products Division
Re: Using Cairo for Harmony graphic stuff?
Posted by Dalibor Topic <ro...@kaffe.org>.
Sergey Soldatov wrote:
> In my opinion the only area to use Cairo is the Java2D part of AWT.
> Unfortunately any additional layer between 2D and native calls may
> dramatically affect the performance of UI, especially Swing.
>
Yes, that's what GNU Classpath does. Using Cairo for other things means
emulating native widgets, or defining one's own widget set. Both are
choices with their own tradeoffs.
cheers,
dalibor topic
Re: Using Cairo for Harmony graphic stuff?
Posted by Stefano Mazzocchi <st...@apache.org>.
Anthony Green wrote:
> On Mon, 2006-02-13 at 13:38 +0300, Sergey Soldatov wrote:
>> In my opinion the only area to use Cairo is the Java2D part of AWT.
>> Unfortunately any additional layer between 2D and native calls may
>> dramatically affect the performance of UI, especially Swing.
>
> GNU Classpath is using Cairo, but I think a better plan now would be to
> use jogl (JSR231, whose reference implementation has a very liberal
> license). Sun has done some interesting work with their OpenGL single
> threaded rendering backend to address the JNI overhead issue. You get
> nice 2d/3d integration as well.
Good point!
--
Stefano.
Re: Using Cairo for Harmony graphic stuff?
Posted by Anthony Green <gr...@redhat.com>.
On Mon, 2006-02-13 at 13:38 +0300, Sergey Soldatov wrote:
> In my opinion the only area to use Cairo is the Java2D part of AWT.
> Unfortunately any additional layer between 2D and native calls may
> dramatically affect the performance of UI, especially Swing.
GNU Classpath is using Cairo, but I think a better plan now would be to
use jogl (JSR231, whose reference implementation has a very liberal
license). Sun has done some interesting work with their OpenGL single
threaded rendering backend to address the JNI overhead issue. You get
nice 2d/3d integration as well.
AG
Re: Using Cairo for Harmony graphic stuff?
Posted by Sergey Soldatov <se...@gmail.com>.
In my opinion the only area to use Cairo is the Java2D part of AWT.
Unfortunately any additional layer between 2D and native calls may
dramatically affect the performance of UI, especially Swing.
On 2/13/06, Leo Simons <ma...@leosimons.com> wrote:
>
> On Mon, Feb 13, 2006 at 02:04:18AM +0100, Tor-Einar Jarnbjo wrote:
> > Stefano Mazzocchi wrote:
> >
> > >Another think that I wonder, for the windowing stuff, why don't we use
> > >Cairo[1]?
> >
> > Isn't Cairo just a rendering library?
>
> Err, yes...it offers drawing primitives for things such as lines and
> points
> and glyphs, on top of other platforms such as X11 and win32.
>
> > AFAIK, it does not offer any kind
> > of e.g. portable widget access,
>
> Aye, I think not.
>
> > which is probably the most tricky thing
> > to implement for AWT.
>
> I wouldn't know. I can imagine its less work to build on top of Cairo than
> to build on top of X11/win32/etc directly, since Cairo is precisely
> designed
> to fulfill the gap between something like AWT (or GTK or wxWindows or ...)
> and the underlying system.
>
> But even then a windowing toolkit is always a whole lot of work.
>
> > Swing can be implemented in pure Java, based on
> > some simple native support by AWT (open window and supply a Graphics
> > object into which the content can be rendered). I don't see where Cairo
> > can offer much help in that area?
>
> Well, that Graphics object at some points needs rendering to the screen
> doesn't it? :-)
>
> cheers!
>
> LSD
>
>
--
Sergey Soldatov
Intel Middleware Products Division
Re: Using Cairo for Harmony graphic stuff?
Posted by Leo Simons <ma...@leosimons.com>.
On Mon, Feb 13, 2006 at 02:04:18AM +0100, Tor-Einar Jarnbjo wrote:
> Stefano Mazzocchi wrote:
>
> >Another think that I wonder, for the windowing stuff, why don't we use
> >Cairo[1]?
>
> Isn't Cairo just a rendering library?
Err, yes...it offers drawing primitives for things such as lines and points
and glyphs, on top of other platforms such as X11 and win32.
> AFAIK, it does not offer any kind
> of e.g. portable widget access,
Aye, I think not.
> which is probably the most tricky thing
> to implement for AWT.
I wouldn't know. I can imagine its less work to build on top of Cairo than
to build on top of X11/win32/etc directly, since Cairo is precisely designed
to fulfill the gap between something like AWT (or GTK or wxWindows or ...)
and the underlying system.
But even then a windowing toolkit is always a whole lot of work.
> Swing can be implemented in pure Java, based on
> some simple native support by AWT (open window and supply a Graphics
> object into which the content can be rendered). I don't see where Cairo
> can offer much help in that area?
Well, that Graphics object at some points needs rendering to the screen
doesn't it? :-)
cheers!
LSD
Re: Using Cairo for Harmony graphic stuff? [was Re: Using APR for
Harmony's native link to the OS?]
Posted by André Luis Ferreira da Silva Bacci <an...@gmail.com>.
Tor-Einar Jarnbjo escreveu:
> Stefano Mazzocchi wrote:
>
>> Another think that I wonder, for the windowing stuff, why don't we use
>> Cairo[1]?
>
> Isn't Cairo just a rendering library? AFAIK, it does not offer any kind
> of e.g. portable widget access, which is probably the most tricky thing
> to implement for AWT. Swing can be implemented in pure Java, based on
> some simple native support by AWT (open window and supply a Graphics
> object into which the content can be rendered). I don't see where Cairo
> can offer much help in that area?
http://www.mono-project.com/Windows_Forms#History
Re: Using Cairo for Harmony graphic stuff? [was Re: Using APR for
Harmony's native link to the OS?]
Posted by Tor-Einar Jarnbjo <To...@Jarnbjo.de>.
Stefano Mazzocchi wrote:
> Another think that I wonder, for the windowing stuff, why don't we use
> Cairo[1]?
Isn't Cairo just a rendering library? AFAIK, it does not offer any kind
of e.g. portable widget access, which is probably the most tricky thing
to implement for AWT. Swing can be implemented in pure Java, based on
some simple native support by AWT (open window and supply a Graphics
object into which the content can be rendered). I don't see where Cairo
can offer much help in that area?
Tor
Using Cairo for Harmony graphic stuff? [was Re: Using APR for Harmony's
native link to the OS?]
Posted by Stefano Mazzocchi <st...@apache.org>.
Ryan Bloom wrote:
> As one of the original authors of APR, I would like to suggest that
> instead of using OS dependant native code, when we get to the point of
> writing awt, we should create an apr-window project, and create the
> library for the abstraction layer. I have had enough conversations
> with other APR developers to be relatively certain that this idea
> would be well received.
Hi Ryan, nice to see you around here.
I'm happy that Enrico has changed his mind about APR and I would also be
in favor of harmony committing back code to APR.
Another think that I wonder, for the windowing stuff, why don't we use
Cairo[1]?
Firefox 2.0 is going to be based on it, so you would expect lots of
polishing/fixing/profiling/OS-portability going on on that front that we
would just reuse and it's dual-licensed under LGPL or MPL 1.1, so if we
release it under the MPL 1.1 license it's also compatible.
What do you think?
[1] http://cairographics.org/
--
Stefano.
Re: Using APR for Harmony's native link to the OS?
Posted by Alexey Petrenko <al...@gmail.com>.
2006/2/11, Ryan Bloom <rb...@gmail.com>:
> As one of the original authors of APR, I would like to suggest that
> instead of using OS dependant native code, when we get to the point of
> writing awt, we should create an apr-window project, and create the
> library for the abstraction layer. I have had enough conversations
> with other APR developers to be relatively certain that this idea
> would be well received.
Yes, it is a possible decision. And interesting challenge.
But it should be carefully thought out librarary... to be abstract
enough and fast enough :)
I'll think about this...
--
Alexey A. Petrenko
Intel Middleware Products Division
Re: Using APR for Harmony's native link to the OS?
Posted by Enrico Migliore <en...@fatti.com>.
Ryan Bloom wrote:
>As one of the original authors of APR, I would like to suggest that
>instead of using OS dependant native code, when we get to the point of
>writing awt, we should create an apr-window project, and create the
>library for the abstraction layer. I have had enough conversations
>with other APR developers to be relatively certain that this idea
>would be well received.
>
>Ryan
>
>
>
Hi Ryan,
that would be nice! Especially if it could run on top of the most used
windows manager like GTK+,
Windows, etc.
Enrico
Re: Using APR for Harmony's native link to the OS?
Posted by Ryan Bloom <rb...@gmail.com>.
As one of the original authors of APR, I would like to suggest that
instead of using OS dependant native code, when we get to the point of
writing awt, we should create an apr-window project, and create the
library for the abstraction layer. I have had enough conversations
with other APR developers to be relatively certain that this idea
would be well received.
Ryan
On 2/11/06, Alexey Petrenko <al...@gmail.com> wrote:
> > What do you think?
> I think that's using Apache Portable Runtime in Apache Harmony is
> natural and good idea.
>
> However we should understand that APR does not have ALL the needed
> functionality. For example APR does not have graphical and window
> management functions. So at least awt will need to use OS dependent
> native code.
>
> --
> Alexey A. Petrenko
> Intel Middleware Products Division
>
--
Ryan Bloom
rbb@apache.org
rbb@rkbloom.net
rbloom@gmail.com
Re: Using APR for Harmony's native link to the OS?
Posted by Alexey Petrenko <al...@gmail.com>.
> What do you think?
I think that's using Apache Portable Runtime in Apache Harmony is
natural and good idea.
However we should understand that APR does not have ALL the needed
functionality. For example APR does not have graphical and window
management functions. So at least awt will need to use OS dependent
native code.
--
Alexey A. Petrenko
Intel Middleware Products Division