[classlib] Layout of tests in crypto module
Hello I would like to make some changes in the crypto module: - Separate implemetation-independent tests from implementation specific ones. - Fix layout according to the proposed scheme [1] Please let me know if you do any changes in that module then I'll delay restruct. Thanks, Mikhail [1] http://incubator.apache.org/harmony/subcomponents/classlibrary/testing.html - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] exception messages
Hi Andrew
The problem with this test is that it will not catch the change
of the message for the given key.
For example if we throw some message from 3 points in the code
and we do some change in the property file that is acceptable for
two points but not acceptable for the 3rd one, we will not catch this
regression by the test you propose.
Thanks,
Mikhail
2006/5/13, Andrew Zhang <[EMAIL PROTECTED]>:
Hello, Mikhail
org.apache.harmony.luni.util.Msg has already handled locale issue.
So it's not neccessary to get locale inforamtion again in test case, and
then get i18n message.
For example, following code is from java.net.HttpURLConnection.java
method setRequestMethod:
if (connected)
throw new ProtocolException(org.apache.harmony.luni.util.Msg.getString
("K0037"));
Correspondingly, we could write a test case:
public void test_setRequestMethod(){
try{
... // make the exception happen
}catch(ProtocolException e){
assertEquals(Msg.getString("K0037"), e.getMessage());
}
Since source code and test code are running in the same runtime, they use
the same locale information, which is used to initialize ResourceBundle in
class Msg.
static {
// Attempt to load the messages.
try {
bundle = MsgHelp.setLocale(Locale.getDefault(),
"org.apache.harmony.luni.util.ExternalMessages");
}
...
}
Finally, I don't think we need test exception message in most cases,
unless there're some speical reasons, e.g, the exception message format is
metioned in spec.
Any comment? Thanks!
On 5/13/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote:
>
> Another (more preferable for me) way could be set a specific locale and
> compare to the message for this locale
>
> Thanks,
> Mikhail.
>
> 2006/5/13, Andrew Zhang <[EMAIL PROTECTED]>:
> > Hello,
> >
> > If we really decide to test exception message, I think we could write
> test
> > case as follows:
> >
> > public void test_f(){
> >.
> >catch(SomeException e){
> > assertEquals(org.apache.util.Msg.getString("K508C"),e.getMessage
> > ());
> >}
> > }
> >
> > Does it work? Because what we want to make sure it that "SomeException"
> is
> > really thrown with message K508C. So that's another reason that we
> should
> > use Msg.getString rather than explicit string to fill exception
> > information.
> >
> > On 5/13/06, Tim Ellison <[EMAIL PROTECTED]> wrote:
> > >
> > > Loenko, Mikhail Y wrote:
> > > > From: Tim Ellison [mailto:[EMAIL PROTECTED]
> > > >> So let me refine my position to say, "our API tests shouldn't be
> > > >> asserting the value of unspecified parts of an exception message".
> > > >> Does that make sense?
> > > >
> > > > Yes, it does. But we might have impl tests that check for exception
> > > > messages.
> > >
> > > Ok, provided they still pass when I translate the message catalog to
> > > Klingon ;-)
> > >
> > > Regards,
> > > Tim
> > >
> > > --
> > >
> > > Tim Ellison ([EMAIL PROTECTED])
> > > IBM Java technology centre, UK.
> > >
> > > -
> > > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> >
> >
> > --
> > Andrew Zhang
> > China Software Development Lab, IBM
> >
> >
>
> -
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
Andrew Zhang
China Software Development Lab, IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: jchevm status?
Ivan, It is great you are spending time on gnuclasspathadapter. As you have discovered, there is a lot of work remaining to be done. It would be really good if you can document the problems you had in when following my directions. How much time will you be able to work on gnuclasspathadapter? It would be good to know so that we can figure out how to split the project efficiently. I gave up on specJVM98 for now because JCHEVM/SableVM eagerly resolves classes. It keeps trying to pull in a bunch of specJVM98 AWT classes. I tried hacking awt out of specJVM98 source code but it got way too convoluted. My current plan is to try to get Mauve's gnu/testlet/java/io/File test to run. I hope to post mods to the native methods that are needed to support gnu/testlet/java/io/File fairly soon. On 5/14/06, Ivan Volosyuk <[EMAIL PROTECTED]> wrote: Sure, if I have some outstanding results I'll share it. As for now... It was quite challenging to run "hello world" using glue layer from Harmony-318. Some changes was made to the classes layout, patched classes are a bit outdated. I didn't found libvmi.so for jchevm, so I've taken modified version from drlvm. There is no documentation about HyVMLSFunctionTable functions used by I was also thinking of stealing pieces of DRLVM. I started this project before DRLVM had been donated. Thus there were no pieces to steal. But now things have changed. Thus time to reassess how to move forward. harmony classlib, and it is used quite strange way. Helpfully, Weldon has commented out its usage. Interesting. Do you really mean, "helpfully"? Perhaps you mean, "hopefully"?? Hello world passed, by specjvm98 _200_check gives me: java.lang.ClassFormatError: invalid interface access flags 0x0201 (for spec/harness/BenchmarkDone and spec/harness/SpecBenchmark) The same is reproducible on jchevm with classpath. When comment out this too stict check: on classpath it works. on harmony classes adapter there is a fatal error, which is strange: spec.benchmarks._200_check.Main does not implement the SpecBenchmark interface - Eclipse on jchevm with classpath throw following (didn't spent much time investigating): ... Caused by: java.lang.NullPointerException at java.lang.VMThrowable.fillInStackTrace (VMThrowable.java) at java.lang.Throwable.fillInStackTrace (Throwable.java:498) at java.lang.Throwable. (Throwable.java:159) at java.lang.Exception. (Exception.java:78) at java.lang.RuntimeException. (RuntimeException.java:76) at java.lang.NullPointerException. (NullPointerException.java:80) at org.eclipse.ui.internal.WorkbenchPage.restoreState (WorkbenchPage.java:2644) at org.eclipse.ui.internal.WorkbenchWindow.restoreState (WorkbenchWindow.java:1819) at org.eclipse.ui.internal.Workbench.doRestoreState (Workbench.java:2566) at org.eclipse.ui.internal.Workbench.access$14 (Workbench.java:2515) at org.eclipse.ui.internal.Workbench$19.run (Workbench.java:1514) at org.eclipse.ui.internal.Workbench$16.run (Workbench.java:1263) at org.eclipse.jface.operation.ModalContext.runInCurrentThread (ModalContext.java:346) activePerspective is null, the roots of the null reference is difficult to track down at first glance. -- Ivan 2006/5/14, Geir Magnusson Jr <[EMAIL PROTECTED]>: > > > Ivan Volosyuk wrote: > > I have recently built jchevm and tried to run eclipse with it. When > > loading a error window appeared. It looks like a bug or unimplemented > > functionality. > > > > I have taken a look at list of loaded native libraries. It looks > > classpath is used for system classes instead of harmony classlib. I > > remember, there was some discussion about porting jchevm to harmony > > classlib, what is the status of this work? Harmony classes prooved to > > work in drlvm. So I think once the porting is done it could be > > possible to get eclipse working on jchevm soon. > > > > There's work going on making a "glue layer" between any GNU > Classpath-using VM and the Harmony Classlib. > > It's not complete yet. Are you interested in helping? We're always > looking for new volunteers. > > geir > > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Weldon Washburn Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jchevm status?
Ivan Volosyuk wrote: Sure, if I have some outstanding results I'll share it. As for now... The classpath adapter is very primordial at this point. On the other hand JCHEVM on Classpath's class library should be fairly mature (limited mainly by Classpath itself). By comparing the two, as well as JCHEVM vs. other JVMs that use Classpath, and eventually other Classpath-based JVM's using the adpater, we'll be able to pinpoint which parts are (mis)behaving, etc. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jchevm status?
Sure, if I have some outstanding results I'll share it. As for now... It was quite challenging to run "hello world" using glue layer from Harmony-318. Some changes was made to the classes layout, patched classes are a bit outdated. I didn't found libvmi.so for jchevm, so I've taken modified version from drlvm. There is no documentation about HyVMLSFunctionTable functions used by harmony classlib, and it is used quite strange way. Helpfully, Weldon has commented out its usage. Hello world passed, by specjvm98 _200_check gives me: java.lang.ClassFormatError: invalid interface access flags 0x0201 (for spec/harness/BenchmarkDone and spec/harness/SpecBenchmark) The same is reproducible on jchevm with classpath. When comment out this too stict check: on classpath it works. on harmony classes adapter there is a fatal error, which is strange: spec.benchmarks._200_check.Main does not implement the SpecBenchmark interface - Eclipse on jchevm with classpath throw following (didn't spent much time investigating): ... Caused by: java.lang.NullPointerException at java.lang.VMThrowable.fillInStackTrace (VMThrowable.java) at java.lang.Throwable.fillInStackTrace (Throwable.java:498) at java.lang.Throwable. (Throwable.java:159) at java.lang.Exception. (Exception.java:78) at java.lang.RuntimeException. (RuntimeException.java:76) at java.lang.NullPointerException. (NullPointerException.java:80) at org.eclipse.ui.internal.WorkbenchPage.restoreState (WorkbenchPage.java:2644) at org.eclipse.ui.internal.WorkbenchWindow.restoreState (WorkbenchWindow.java:1819) at org.eclipse.ui.internal.Workbench.doRestoreState (Workbench.java:2566) at org.eclipse.ui.internal.Workbench.access$14 (Workbench.java:2515) at org.eclipse.ui.internal.Workbench$19.run (Workbench.java:1514) at org.eclipse.ui.internal.Workbench$16.run (Workbench.java:1263) at org.eclipse.jface.operation.ModalContext.runInCurrentThread (ModalContext.java:346) activePerspective is null, the roots of the null reference is difficult to track down at first glance. -- Ivan 2006/5/14, Geir Magnusson Jr <[EMAIL PROTECTED]>: Ivan Volosyuk wrote: > I have recently built jchevm and tried to run eclipse with it. When > loading a error window appeared. It looks like a bug or unimplemented > functionality. > > I have taken a look at list of loaded native libraries. It looks > classpath is used for system classes instead of harmony classlib. I > remember, there was some discussion about porting jchevm to harmony > classlib, what is the status of this work? Harmony classes prooved to > work in drlvm. So I think once the porting is done it could be > possible to get eclipse working on jchevm soon. > There's work going on making a "glue layer" between any GNU Classpath-using VM and the Harmony Classlib. It's not complete yet. Are you interested in helping? We're always looking for new volunteers. geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jchevm status?
Ivan Volosyuk wrote: I have recently built jchevm and tried to run eclipse with it. When loading a error window appeared. It looks like a bug or unimplemented functionality. Yes, this is a bug I haven't been able to track down yet. Any insights appreciated. Also check out: http://sablevm.org/wiki/Eclipse for some command line flags that may help. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] Request for golden ticket to update String class
All opinions are welcome. And in the future, fix your mailer so that it doesn't take the message you are responding to as an attachment... see... nothing below your statement of support... geir Ivan Volosyuk wrote: I like this solution. If my opinion is counted: +1 from me. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] Request for golden ticket to update String class
I think that at this point, since Tim has nodded in agreement, and no
one has objected, go forward.
I'm stating this so we don't turn this into a formal vote - you posted a
note about something we agreed to take special care with, a reasonable
amount of time has gone by, there is knowledgeable assent, and no
complaints...
Tim Ellison wrote:
I agree with your analysis. +1 from me.
Regards,
Tim
Stepan Mishura wrote:
On 5/12/06, *Jimmy, Jing Lv* wrote:
>> In this case, though replace StringIndexOutOfBoundsException with
>> ArrayIndexOutOfBoundsException is surely better, it seems it is
internal
>> implementation what cause the problem. According to the code it use
>> String.valueof(str), which writes:
>> try {
>>System.arraycopy(data, start, value, 0, count);
>> } catch (IndexOutOfBoundsException e) {
>>throw new StringIndexOutOfBoundsException();
>> }
>
>
> IMHO this try-catch block is redandunt - the method code already
contains
> checks to verify that all parameters are valid:
> if (start >= 0 && 0 <= length && length <= data.length - start) {
>
> else
>throw new StringIndexOutOfBoundsException();
>
I believe you are right, but there may be some reasons for the author
to write such try{...}catch(){}, perhaps he do follow RI's exception in
the class String.
Hi,
I'd like to acquire golden ticket for updating String.java file. Please
review my request.
Description:
Constructor: public String(char[] data, int start, int length) contains
redundant try-catch block that should be removed:
try {
System.arraycopy(data, start, value, 0, count);
} catch (IndexOutOfBoundsException e) {
throw new StringIndexOutOfBoundsException();
}
Basis:
According to the spec. method
System.arraycopy(Object src, int srcPos, Object dest, int destPos, int
length)
throws IndexOutOfBoundsException in the following cases:
1) srcPos < 0
2) destPos < 0
3) length <0
4) srcPos+length > src.length
5) destPos+length > dest.length
In our case: destPos is passed as 0 value and dest array is allocated
as: value = new char[length]. So in 2 and 5 cases IOOBE cannot be thrown
by arraycopy method. For other cases (1,3,4) the constructor contains
explicit check and throws SIOOBE if passed parameters are invalid:
if (start >= 0 && 0 <= length && length <= data.length - start) {
} else {
throw new StringIndexOutOfBoundsException();
So System.arraycopy(...) method MUST not throw IOOBE in the the
constructor and try-catch block is redundant in this case.
Patch file is attached.
Thanks,
Stepan Mishura
Intel Middleware Products Division
--
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Index: modules/luni/src/main/java/java/lang/String.java
===
--- modules/luni/src/main/java/java/lang/String.java(revision 405602)
+++ modules/luni/src/main/java/java/lang/String.java(working copy)
@@ -434,11 +434,8 @@
offset = 0;
value = new char[length];
count = length;
- try {
- System.arraycopy(data, start, value, 0, count);
- } catch (IndexOutOfBoundsException e) {
- throw new StringIndexOutOfBoundsException();
- }
+
+ System.arraycopy(data, start, value, 0, count);
} else
throw new StringIndexOutOfBoundsException();
}
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: jchevm status?
Ivan Volosyuk wrote: I have recently built jchevm and tried to run eclipse with it. When loading a error window appeared. It looks like a bug or unimplemented functionality. I have taken a look at list of loaded native libraries. It looks classpath is used for system classes instead of harmony classlib. I remember, there was some discussion about porting jchevm to harmony classlib, what is the status of this work? Harmony classes prooved to work in drlvm. So I think once the porting is done it could be possible to get eclipse working on jchevm soon. There's work going on making a "glue layer" between any GNU Classpath-using VM and the Harmony Classlib. It's not complete yet. Are you interested in helping? We're always looking for new volunteers. geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] Request for golden ticket to update String class (was: Re: [classlib] Exception throwing compatibility)
I like this solution. If my opinion is counted:
+1 from me.
--
Ivan
Intel Middleware Products Division
2006/5/14, Tim Ellison <[EMAIL PROTECTED]>:
I agree with your analysis. +1 from me.
Regards,
Tim
Stepan Mishura wrote:
> On 5/12/06, *Jimmy, Jing Lv* wrote:
>
>
> >> In this case, though replace StringIndexOutOfBoundsException with
> >> ArrayIndexOutOfBoundsException is surely better, it seems it is
> internal
> >> implementation what cause the problem. According to the code it use
> >> String.valueof(str), which writes:
> >> try {
> >>System.arraycopy(data, start, value, 0, count);
> >> } catch (IndexOutOfBoundsException e) {
> >>throw new StringIndexOutOfBoundsException();
> >> }
> >
> >
> > IMHO this try-catch block is redandunt - the method code already
> contains
> > checks to verify that all parameters are valid:
> > if (start >= 0 && 0 <= length && length <= data.length - start) {
> >
> > else
> >throw new StringIndexOutOfBoundsException();
> >
>
> I believe you are right, but there may be some reasons for the author
> to write such try{...}catch(){}, perhaps he do follow RI's exception in
> the class String.
>
>
> Hi,
>
> I'd like to acquire golden ticket for updating String.java file. Please
> review my request.
>
> Description:
> Constructor: public String(char[] data, int start, int length) contains
> redundant try-catch block that should be removed:
> try {
> System.arraycopy(data, start, value, 0, count);
> } catch (IndexOutOfBoundsException e) {
> throw new StringIndexOutOfBoundsException();
> }
>
> Basis:
> According to the spec. method
> System.arraycopy(Object src, int srcPos, Object dest, int destPos, int
> length)
>
> throws IndexOutOfBoundsException in the following cases:
> 1) srcPos < 0
> 2) destPos < 0
> 3) length <0
> 4) srcPos+length > src.length
> 5) destPos+length > dest.length
>
> In our case: destPos is passed as 0 value and dest array is allocated
> as: value = new char[length]. So in 2 and 5 cases IOOBE cannot be thrown
> by arraycopy method. For other cases (1,3,4) the constructor contains
> explicit check and throws SIOOBE if passed parameters are invalid:
> if (start >= 0 && 0 <= length && length <= data.length - start) {
>
> } else {
> throw new StringIndexOutOfBoundsException();
>
> So System.arraycopy(...) method MUST not throw IOOBE in the the
> constructor and try-catch block is redundant in this case.
>
> Patch file is attached.
>
> Thanks,
> Stepan Mishura
> Intel Middleware Products Division
>
> --
> Terms of use : http://incubator.apache.org/harmony/mailing.html
>
> To unsubscribe, e-mail: [EMAIL PROTECTED]
>
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
>
>
> Index: modules/luni/src/main/java/java/lang/String.java
> ===
> --- modules/luni/src/main/java/java/lang/String.java (revision 405602)
> +++ modules/luni/src/main/java/java/lang/String.java (working copy)
> @@ -434,11 +434,8 @@
> offset = 0;
> value = new char[length];
> count = length;
> - try {
> - System.arraycopy(data, start, value, 0, count);
> - } catch (IndexOutOfBoundsException e) {
> - throw new StringIndexOutOfBoundsException();
> - }
> +
> + System.arraycopy(data, start, value, 0, count);
> } else
> throw new StringIndexOutOfBoundsException();
> }
>
>
>
>
> -
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
--
Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: OPEN Specification
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 has to write native code to implement Socket function. And I also think it's >classlib programmer's responsibility The idea is that the VM provides some standardized functionality through VM and Platform accessors. How much that is, is part of the standard definition that we need. Agree, and I'm also interested in the standard API definition criterias. :) I am not completely sure what you mean by the "classlib programmer's responsibility". It is true that the classlib programmer will need to implement whatever is not provided by the standardised accessor components. Understood. Thanks, Rana On 5/12/06, Andrew Zhang <[EMAIL PROTECTED]> wrote: > > 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: > > The MemoryAccessor interface includes the following function groups: > 1.Memory allocation and de-allocation: malloc, realloc, free > 2.Operations over primitive types: getByte, getDouble,setBoolean > 3.Operations over arrays of primitive types: getChar(char[] buf,..) > 4.Search operations: findFirstDiff, findFirstDiffReorder > > For full description, please refer to " > http://issues.apache.org/jira/browse/HARMONY-459"; or [1]. > > I wonder who has the responsibility to provide such native-related and > platform-independent interfaces to java classlib programmer? > > No doubt "OS Portability Layer" provides platform-independent interfaces, > e.g, portable_malloc or portable_free. Then shall classlib > programmer write native code to implement high-level functions such as > "findFirstDiff" and invoke them via JNI mode? or shall VM provide such > high-level functions and classlib programmer only need call mem.findFirst? > > I think Harmony classlib follows the former way currently. > As my understanding of the document, classlib programmer will avoid > writing > native code directly, and invoke corresponding interfaces defined in VM. > 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.Socket implementation. Classlib programmer still has > to write native code to implement Socket function. And I also think it's > classlib programmer's responsibility. I don't know whether OPEN spec would > > plan to provide such interfaces? IMO, ByteBuffer example and Socket > example > is on the same level programming, and the real implemenation native > code should exist on the same level code repository, e.g, both in VM or > classlib native-src. Am I missing something? Would anyone clarify my > confusion? > > Thanks a lot! > > [1] > The java.nio package defines the buffer classes, which are used throughout > the native input and output (NIO) APIs. Buffers can be *direct* or * > non-direct*. Given a direct buffer, the system performs native I/O > operations directly without copying the buffer content from the native to > the Java* layer, > Java*arrays. A direct byte buffer > is created by using the > allocateDirect() factory method, which is often mapped directly to the > system or the C library allocation methods, such as malloc() and > VirtualAlloc(). Direct access is provided by using native methods, which > increases the overall cost of accessing such data from the > Java*< file:///F:/clear/opendoc/HLD.html#*>layer. The memory accessor > mechanism encapsulates all required operations on > the native heap, and provides room for future optimizations by using > in-lining or other JIT techniques. The MemoryAccessor interface includes > the > following function groups: > > - Memory allocation and de-allocation: malloc, realloc, free > - Operations over primitive types: getByte, getDouble,setBoolean > - Operations over arrays of primitive types: getChar(char[] buf,..) > - Search operations: findFirstDiff, findFirstDiffReorder > > > On 5/13/06, Rana Dasgupta <[EMAIL PROTECTED]> wrote: > > > > Hi, > > Alongside the DRLVM codebase, here is a contribution from Intel of an > OPEN > > ( Open Pluggable Extensible Interface ) specification for JVM and > > Classlibrary-VM Interface development. > > > > URL: http://issues.apache.org/jira/browse/HARMONY-459 > > > > > > We hope that this spec will promote modular component oriented > development > > of core pieces eg., the garbage collector, core VM, Just In Time > compiler, > > ClassLibrary-VM Interface etc. That it will provide a framework for > > developing and interconnecting alternate component implementations > through > > standardized interfaces. > > The DRLVM codebase does not quite confirm to the OPEN spec at this > point, > > though that is the final intent. The OPEN spe
