Etienne,
I didn't mean that every Harmony JVM should follow OPEN interface. It
is not necessary to implement but maybe JVMs can benefit from
following it (or any kind of standard interface accepted by the
community). It is just a proposal with some simple ideas behind it:
First, JVM should be
Etienne,
Some words about your example.
OPEN doesn't rely on any particular object layout, but tries to define
functional interface for object access purposes.
Open_Managed_Object_Handle is used to access this functionality from
the components other than VM Core.
In order to eliminate
On 5/30/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote:
Etienne Gagnon wrote:
Hi Anton,
Are you proposing that all Harmony JVMs must abide by the OPEN proposal?
I won't attempt to speak for Anton, but IMO, no.
Right now, any JVM that works w/ Harmony classlib must simply support
the class
Hello,
I would like to try to draw attention to the OPEN proposal again. It
was published about two weeks ago and produced a very small response
in the community. This interface is very important, because if it is
accepted, it will become a base of (many?) Harmony VMs.
For example, one of the
Hi Anton,
Are you proposing that all Harmony JVMs must abide by the OPEN proposal?
If yes, I think that some process has to be put in place to present and
discuss each of this proposal's part, and dedicate time to do so. IMO,
I don't think that everyone (in the JVM sub-communityof Harmony) can
Hi Tim,
On 5/14/06, Tim Ellison [EMAIL PROTECTED] wrote:
First a caveat that I have only read the OPEN document through quickly
so far, so apologies if this is off-base. I do intend to go back an
read more thoroughly.
Is it fair to generalize the Accessors proposal to say that there should
be
Hello, Rana,
Thanks a lot for your comments to make me clear.
On 5/14/06, Rana Dasgupta [EMAIL PROTECTED] wrote:
If I'm right, I think it's very hard for VM to provide so many
native-related
APIs for classlib programmer. For example, java.net.Socketimplementation.
Classlib programmer still
Hi Andrew,
Thanks for your comments and interesting feedback. The ideas in this spec
are certainly open to debate and input from everyone. As we well know,
modularity is a great goal which has many merits...testability, ease of
development, plug and play etc. However it is less easy to achieve
Hello, Rana
I took a quick view on the document, and I have some questions on Chapter 6.
Let's take 6.9.1 A.NM ACCESS TO NATIVE MEMORY as example:
citeThe MemoryAccessor interface includes the following function groups:
1.Memory allocation and de-allocation: malloc, realloc, free
2.Operations
