You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by "Richard Liang (JIRA)" <ji...@apache.org> on 2006/01/10 14:41:22 UTC
[jira] Created: (HARMONY-26) The API of buffer classes in java.nio
are not compliant with the specification of Java 5.0
The API of buffer classes in java.nio are not compliant with the specification of Java 5.0
------------------------------------------------------------------------------------------
Key: HARMONY-26
URL: http://issues.apache.org/jira/browse/HARMONY-26
Project: Harmony
Type: Bug
Components: Classlib
Reporter: Richard Liang
Assigned to: Geir Magnusson Jr
1. java.nio.CharBuffer
1.1) java.nio.CharBuffer needs to implement two new interface java.lang.Appendable and java.lang.Readable
1.2) The following methods should NOT be "protected":
protected CharBuffer(int capacity)
protected abstract char[] protectedArray();
protected abstract int protectedArrayOffset();
protected abstract boolean protectedHasArray();
1.3) The following method should be "final":
public CharBuffer put(char[] src)
2. java.nio.Buffer
2.1) The following fields should NOT be "protected":
int UNSET_MARK
int capacity
int limit
int mark should
int position
2.3) The following method should NOT be "protected":
protected Buffer(int capacity)
3. java.nio.ByteBuffer, DoubleBuffer, FloatBuffer, IntBuffer, LongBuffer, ShortBuffer
3.1) The following field should NOT be "protected":
com.ibm.platform.Endianness order
3.2) The following methods should NOT be "protected":
protected ByteBuffer(int capacity)
protected abstract byte[] protectedArray();
protected abstract int protectedArrayOffset();
protected abstract boolean protectedHasArray();
3.3) The following method should be "final":
public ByteBuffer order(ByteOrder byteOrder)
4. The implementation of bulk put/get methods of all the buffer classes are low-efficiency
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
Re: compiling JCHEVM with GCC/Cygwin
Posted by Archie Cobbs <ar...@dellroad.org>.
Enrico Migliore wrote:
> After compiling some C source files, thoug, it stopped saying:
>
> jcjavah: can't load class 'gnu/classpath/VMStackWalker':
>
> java/io/IOException: error reading entry
> 'gnu/classpath/VMStackWalker.class'
> in ZIP file 'usr/local/classpath/share/classpath/glibj.zip': No error
>
> make[2]: *** [gnu_classpath_VMStackWalker.h] Error 1
>
> (Note that VMStackWalker.class is present in my zip file:
> /usr/local/classpath/share/classpath/glibj.zip)
Looks like the pread(3) function is not working properly under Cygwin.
This error occurs on line 373 of zip.c if you want to try to debug it
(sorry, I'm Windows illiterate).
-Archie
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com
Re: [jchevm] building jchevm on Cygwin
Posted by Enrico Migliore <en...@fatti.com>.
Archie Cobbs wrote:
> What does this program print?
>
> /*
> * Compile me from the top jchevm directory like this:
> *
> * cc -I libjc -I include -I libjc/native -I libjc/arch -o xx xx.c
> */
> #include "libjc.h"
> int
> main(int ac, char **av)
> {
> printf("_JC_FULL_ALIGNMENT=%u\n", _JC_FULL_ALIGNMENT);
> return 0;
> }
>
> -Archie
Hi Archie,
here are the messages and the value of ALIGNMENT.
As far as the Classpath problem is concerned, I posted a thread on
the Classpath mailing list.
Keep in mind that I haven't yet merged your latest pacth (replacement
of the ucontext functions with setjmp() - longjmp). with my source tree.
assertion failure 1
-----------------
vm.c - line 46
message = "assertion failure: _JC_FULL_ALIGNMENT <= (sizeof(_jc_word))"
When I add the following:
printf("_JC_FULL_ALIGNMENT=%u\n", _JC_FULL_ALIGNMENT);
jchevm prints: 8
assertion failure 2
-----------------
vm.c - line 176
message = "assertion failure: vm->threads.pro_min <= assertion
failure:vm->threads.pro_max"
assertion failure 3
-----------------
heap.c - line 238
message = "assertion failure: bs->hint == NULL || (((_jc_word) bs->hint
& (_JC_PAGE_SIZE - 1) %
bs->size) == _JC_HEAP_BLCOK_OFFSET)
assertion failure 4
-----------------
thread.c - line 1023
/* _JC_COND_SIGNAL(vm->vm_destruction);*/
message = "assertion failure: _r == 0"
Your comments are welcome :-)
Enrico
Re: [jchevm] building jchevm on Cygwin
Posted by Archie Cobbs <ar...@dellroad.org>.
Enrico Migliore wrote:
> The result is that the following assertions fail:
>
> 1. vm.c - line 46
What does this program print?
/*
* Compile me from the top jchevm directory like this:
*
* cc -I libjc -I include -I libjc/native -I libjc/arch -o xx xx.c
*/
#include "libjc.h"
int
main(int ac, char **av)
{
printf("_JC_FULL_ALIGNMENT=%u\n", _JC_FULL_ALIGNMENT);
return 0;
}
-Archie
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com
[jchevm] building jchevm on Cygwin
Posted by Enrico Migliore <en...@fatti.com>.
Hi Archie,
GNU/Classpath problem
-------------------------
at the moment, when I run:
$jc HelloWorld
I got the following exception:
java.lang.UnsatisfiedLinkError: failed to open native library:
'usr/local/classpath/lib/classpath/libjavanio.so'
The reason is simple: Classpath doesn't know it's running on Cygwin,
therefore it looks for "libjavanio.so" instead of "libjavanio.dll" (which
exists on the filesytem). I'll post a thread on the Classpath list in order
to fix this problem.
Assertion failures on Cygwin
-----------------------------
I compiled the distribution with all assertions enabled and ran:
$jc HelloWorld
The result is that the following assertions fail:
1. vm.c - line 46
2. vm.c - line 176
3. heap.c - line 238
4. thread.c - line 1023
Of course, to get to assertions 2 I had to comment assertion 1 and so on.
Segmentation fault problem on Cygwin
---------------------------------------
While debugging JCHEVM with DDD I noticed that the pthread library issues
a segmentation fault signal. In order to proceed, I instructed DDD to
ignore the signal.
To fix the problem, I'll have to compile the pthread library in debug
mode and sneak in
the source code.
Comment
----------
Even if I fix all of these problems, JCHEVM will always need Cygwin to
run on top
of Windows. That is acceptable for now, but someday, if we want JCHEVM to
became a fully fladged VM we'll have to make a native port to Windows.
Enrico
Re: JCHEVM built on GCC/Cygwin
Posted by Enrico Migliore <en...@fatti.com>.
Hi Geir,
>
> Now lets get JCHEVM to also use the Harmony Classlib :) It will be
> great for A/B testing.
It's a task that Archie and I would like to accomplish in the near
future, when time permits.
Enrico
Re: JCHEVM built on GCC/Cygwin
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Hey, that's great!
Now lets get JCHEVM to also use the Harmony Classlib :) It will be
great for A/B testing.
geir
Enrico Migliore wrote:
> Hi folks,
>
> I've finally built JCHEVM and Classpath 0.20 on GCC/Cygwin/Windows.
>
> There are still a few things to fix and port but the main job is done.
>
> At the moment, when calling:
>
> $jc HelloWorld.class
>
> jc throws an exception because it can't find a .so library in Classpath.
>
>
> ciao,
> Enrico
>
>
>
>
JCHEVM built on GCC/Cygwin
Posted by Enrico Migliore <en...@fatti.com>.
Hi folks,
I've finally built JCHEVM and Classpath 0.20 on GCC/Cygwin/Windows.
There are still a few things to fix and port but the main job is done.
At the moment, when calling:
$jc HelloWorld.class
jc throws an exception because it can't find a .so library in Classpath.
ciao,
Enrico
Re: compiling JCHEVM with GCC/Cygwin
Posted by Archie Cobbs <ar...@dellroad.org>.
Enrico Migliore wrote:
> I tried to debug it with DDD (Data display debugger) which is a GUI
> based debugger which,
> in turn, uses GDB. I was tired last night and wasn't able to take any
> step forward.
> What's your GUI front end for writing and debugging JC? Are you using
> xemacs?
Um, vi.. does that count? :-)
-Archie
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com
Re: compiling JCHEVM with GCC/Cygwin
Posted by Enrico Migliore <en...@fatti.com>.
Hi Archie,
> Enrico Migliore wrote:
>
>> pread() problem
>> -----------------
>> In the zip.c file, I temporarily substituted the pread() call
>> with the following two calls:
>>
>> lseek(fd,offset,SEEK_SET);
>> read(fd,buf,len);
>>
>> Those are perfectly equivalent to pread() except that
>> they are not atomic
>
>
> That is a reasonable workaround; it's not thread safe however.
> In practice is probably won't matter though. You'd have to be
> loading the same class at the same time from two different
> class loaders for that to matter (highly unlikely).
>
Let's use this workaround for now. I'll go through the pread() function,
on Cygwin.
>> problems
>> ----------
>> jc.exe enters the main function and crashes at the first call,
>> which is _jc_invoke();
>>
>> In order to investigate the problem I did the following thngs:
>>
>> 1. Commented _jc_invoke() and added a dummy poptGetContext() call.
>> It crashes
>>
>> 2. Commented _jc_invoke() and added a printf("Hello World!");
>> It doesn't crash and print the message to the stdandard output
>>
>> It seems to me that the problem is the calling convention.
>
>
> I don't know enough about Windows or Cygwin to help here.
> Can you run it under GDB?
>
> -Archie
I tried to debug it with DDD (Data display debugger) which is a GUI
based debugger which,
in turn, uses GDB. I was tired last night and wasn't able to take any
step forward.
What's your GUI front end for writing and debugging JC? Are you using
xemacs?
Enrico
Re: compiling JCHEVM with GCC/Cygwin
Posted by Archie Cobbs <ar...@dellroad.org>.
Enrico Migliore wrote:
> pread() problem
> -----------------
> In the zip.c file, I temporarily substituted the pread() call
> with the following two calls:
>
> lseek(fd,offset,SEEK_SET);
> read(fd,buf,len);
>
> Those are perfectly equivalent to pread() except that
> they are not atomic
That is a reasonable workaround; it's not thread safe however.
In practice is probably won't matter though. You'd have to be
loading the same class at the same time from two different
class loaders for that to matter (highly unlikely).
> problems
> ----------
> jc.exe enters the main function and crashes at the first call,
> which is _jc_invoke();
>
> In order to investigate the problem I did the following thngs:
>
> 1. Commented _jc_invoke() and added a dummy poptGetContext() call.
> It crashes
>
> 2. Commented _jc_invoke() and added a printf("Hello World!");
> It doesn't crash and print the message to the stdandard output
>
> It seems to me that the problem is the calling convention.
I don't know enough about Windows or Cygwin to help here.
Can you run it under GDB?
-Archie
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com
Re: compiling JCHEVM with GCC/Cygwin
Posted by Enrico Migliore <en...@fatti.com>.
Hi Archie,
I took some steps forward.
pread() problem
-----------------
In the zip.c file, I temporarily substituted the pread() call
with the following two calls:
lseek(fd,offset,SEEK_SET);
read(fd,buf,len);
Those are perfectly equivalent to pread() except that
they are not atomic
ucontext problem
-----------------
I commented out the code where there was any reference
to the ucontext library, in ordere GCC to continue compiling.
Fortunately, the number of references are very few and as
soon as I port the ucontext library to Cygwin, I will restore
the original code.
good news
-----------
I'm able to build JCHEVM with Cygwin and
the builder produces the following three executables:
jc.exe
jcjavah.exe
cfdump.exe
jcjavah.exe and cfdump.exe seem to work.
I called:
$jcjavah --help
$cfdump --help
and both show the command options
problems
----------
jc.exe enters the main function and crashes at the first call,
which is _jc_invoke();
In order to investigate the problem I did the following thngs:
1. Commented _jc_invoke() and added a dummy poptGetContext() call.
It crashes
2. Commented _jc_invoke() and added a printf("Hello World!");
It doesn't crash and print the message to the stdandard output
It seems to me that the problem is the calling convention.
Got any hints?
Enrico
P.S.
I'm reading the HTML documentation you wrote
Re: compiling JCHEVM with GCC/Cygwin
Posted by Archie Cobbs <ar...@dellroad.org>.
Enrico Migliore wrote:
> The bad news is that the RedHat guys hasn't ported ucontext library to
> Cygwin.
>
> The good one is that:
>
> 1. You call just one of the 4 ucontext library functions, and you call it
> in just one source file (stack.c)
>
> 2. I've found an example explaining how to port the ucontext library in
> Cygwin
> (Don't know if it works though)
Good, hopefully #2 will work. The use of ucontext is pretty critical,
because otherwise we could leak references and accidentally GC an object
still in use. Actually there could be an alternative implementation using
setjmp(), I'll look into that if time permits.
> zip problem
> ------------
> I downloaded the source code of zip-2.3 and,
> at line 373 of zip.c, I got this:
>
> #ifdef MACOS
Sorry, I meant JCHEVM's zip,c: jchevm/libjc/zip.c.
> > Looks like the pread(3) function is not working properly under Cygwin.
> > This error occurs on line 373 of zip.c if you want to try to debug it
> > (sorry, I'm Windows illiterate).
>
> Yet, I can't find, in the Zip source files, the the pread( ) function
> that you told me about
pread(3) is something that Cygwin would supply, not zip. I.e., it's
part of the standard C library (per Unix98).
-Archie
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com
Re: compiling JCHEVM with GCC/Cygwin
Posted by Enrico Migliore <en...@fatti.com>.
Hi Archie,
ucontext library
---------------
The ./configure script refuses to complete successfully if I don't put
the ucontext.h header file,
in the following places: /usr/include and /usr/include/sys
Therefore, the ucontext library must be present.
The bad news is that the RedHat guys hasn't ported ucontext library to
Cygwin.
The good one is that:
1. You call just one of the 4 ucontext library functions, and you call it
in just one source file (stack.c)
2. I've found an example explaining how to port the ucontext library in
Cygwin
(Don't know if it works though)
zip problem
------------
I downloaded the source code of zip-2.3 and,
at line 373 of zip.c, I got this:
#ifdef MACOS
> Looks like the pread(3) function is not working properly under Cygwin.
> This error occurs on line 373 of zip.c if you want to try to debug it
> (sorry, I'm Windows illiterate).
Yet, I can't find, in the Zip source files, the the pread( ) function
that you told me about
Any suggestions?
Enrico
Re: compiling JCHEVM with GCC/Cygwin
Posted by Enrico Migliore <en...@fatti.com>.
Hi Archie,
> Enrico Migliore wrote:
>
>> P.S.
>> During the compilation phase, that is, before stopping on the
>> mentioned error,
>> the compiler issues the following warning: gcc: unrecognized
>> option '-pthread'
>
>
> I've removed this configure hack, which is no longer needed.
>
ok!
>> P.S.
>> I put the ucontext.h file in the dirs: /include and /include/sys
>> at the moment they are empty
>
>
> That's a bad sign.. :-)
>
> -Archie
I don't know whether the Cygwin guys has ported the functions
included in the ucontext.h header file, to Win32. I'll check it tonight.
Enrico
Re: compiling JCHEVM with GCC/Cygwin
Posted by Archie Cobbs <ar...@dellroad.org>.
Enrico Migliore wrote:
> P.S.
> During the compilation phase, that is, before stopping on the mentioned
> error,
> the compiler issues the following warning: gcc: unrecognized option
> '-pthread'
I've removed this configure hack, which is no longer needed.
> P.S.
> I put the ucontext.h file in the dirs: /include and /include/sys
> at the moment they are empty
That's a bad sign.. :-)
-Archie
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com
compiling JCHEVM with GCC/Cygwin
Posted by Enrico Migliore <en...@fatti.com>.
Hi Archie
In order to build JCHEVM with Cygwin I took the following steps:
1. Built Classpath 0.20 with Cygwin, with the following options:
$./configure --with-jikes gtk-peer-enable
2. Downloaded JCHEVM and read Apache.README and INSTALL
3. Ran successfully the following script:
$sh autogen.sh
4. Ran the following command:
$make
After compiling some C source files, thoug, it stopped saying:
jcjavah: can't load class 'gnu/classpath/VMStackWalker':
java/io/IOException: error reading entry
'gnu/classpath/VMStackWalker.class'
in ZIP file 'usr/local/classpath/share/classpath/glibj.zip': No error
make[2]: *** [gnu_classpath_VMStackWalker.h] Error 1
(Note that VMStackWalker.class is present in my zip file:
/usr/local/classpath/share/classpath/glibj.zip)
Can anybody help me out?
ciao,
Enrico
P.S.
During the compilation phase, that is, before stopping on the
mentioned error,
the compiler issues the following warning: gcc: unrecognized option
'-pthread'
P.S.
I put the ucontext.h file in the dirs: /include and /include/sys
at the moment they are empty
[jira] Commented: (HARMONY-26) The API of buffer classes in
java.nio are not compliant with the specification of Java 5.0
Posted by "Tim Ellison (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/HARMONY-26?page=comments#action_12363229 ]
Tim Ellison commented on HARMONY-26:
------------------------------------
Gulp -- ok I'll start looking through this laundry list and fixing the NIO buffer code.
Do you have accompanying JUnit tests to go along with these defects? Since you have contributor paperwork on file I suggest you simply attach them to this issue (ensuring you mark them as granting ASF license).
> The API of buffer classes in java.nio are not compliant with the specification of Java 5.0
> ------------------------------------------------------------------------------------------
>
> Key: HARMONY-26
> URL: http://issues.apache.org/jira/browse/HARMONY-26
> Project: Harmony
> Type: Bug
> Components: Classlib
> Reporter: Richard Liang
> Assignee: Tim Ellison
> Attachments: DirectBuffer.java
>
> 1. java.nio.CharBuffer
> 1.1) java.nio.CharBuffer needs to implement two new interface java.lang.Appendable and java.lang.Readable
> 1.2) The following methods should NOT be "protected":
> protected CharBuffer(int capacity)
> protected abstract char[] protectedArray();
> protected abstract int protectedArrayOffset();
> protected abstract boolean protectedHasArray();
>
> 1.3) The following method should be "final":
> public CharBuffer put(char[] src)
>
> 2. java.nio.Buffer
> 2.1) The following fields should NOT be "protected":
> int UNSET_MARK
> int capacity
> int limit
> int mark should
> int position
> 2.3) The following method should NOT be "protected":
> protected Buffer(int capacity)
> 3. java.nio.ByteBuffer, DoubleBuffer, FloatBuffer, IntBuffer, LongBuffer, ShortBuffer
> 3.1) The following field should NOT be "protected":
> com.ibm.platform.Endianness order
> 3.2) The following methods should NOT be "protected":
> protected ByteBuffer(int capacity)
> protected abstract byte[] protectedArray();
> protected abstract int protectedArrayOffset();
> protected abstract boolean protectedHasArray();
> 3.3) The following method should be "final":
> public ByteBuffer order(ByteOrder byteOrder)
>
> 4. The implementation of bulk put/get methods of all the buffer classes are low-efficiency
>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Assigned: (HARMONY-26) The API of buffer classes in java.nio
are not compliant with the specification of Java 5.0
Posted by "Tim Ellison (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/HARMONY-26?page=all ]
Tim Ellison reassigned HARMONY-26:
----------------------------------
Assign To: Tim Ellison (was: Geir Magnusson Jr)
Wow - thanks for your thorough analysis Richard.
> The API of buffer classes in java.nio are not compliant with the specification of Java 5.0
> ------------------------------------------------------------------------------------------
>
> Key: HARMONY-26
> URL: http://issues.apache.org/jira/browse/HARMONY-26
> Project: Harmony
> Type: Bug
> Components: Classlib
> Reporter: Richard Liang
> Assignee: Tim Ellison
>
> 1. java.nio.CharBuffer
> 1.1) java.nio.CharBuffer needs to implement two new interface java.lang.Appendable and java.lang.Readable
> 1.2) The following methods should NOT be "protected":
> protected CharBuffer(int capacity)
> protected abstract char[] protectedArray();
> protected abstract int protectedArrayOffset();
> protected abstract boolean protectedHasArray();
>
> 1.3) The following method should be "final":
> public CharBuffer put(char[] src)
>
> 2. java.nio.Buffer
> 2.1) The following fields should NOT be "protected":
> int UNSET_MARK
> int capacity
> int limit
> int mark should
> int position
> 2.3) The following method should NOT be "protected":
> protected Buffer(int capacity)
> 3. java.nio.ByteBuffer, DoubleBuffer, FloatBuffer, IntBuffer, LongBuffer, ShortBuffer
> 3.1) The following field should NOT be "protected":
> com.ibm.platform.Endianness order
> 3.2) The following methods should NOT be "protected":
> protected ByteBuffer(int capacity)
> protected abstract byte[] protectedArray();
> protected abstract int protectedArrayOffset();
> protected abstract boolean protectedHasArray();
> 3.3) The following method should be "final":
> public ByteBuffer order(ByteOrder byteOrder)
>
> 4. The implementation of bulk put/get methods of all the buffer classes are low-efficiency
>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (HARMONY-26) The API of buffer classes in java.nio
are not compliant with the specification of Java 5.0
Posted by "Richard Liang (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/HARMONY-26?page=all ]
Richard Liang updated HARMONY-26:
---------------------------------
Attachment: DirectBuffer.java
This is the new interface added in com.ibm.io.nio
> The API of buffer classes in java.nio are not compliant with the specification of Java 5.0
> ------------------------------------------------------------------------------------------
>
> Key: HARMONY-26
> URL: http://issues.apache.org/jira/browse/HARMONY-26
> Project: Harmony
> Type: Bug
> Components: Classlib
> Reporter: Richard Liang
> Assignee: Tim Ellison
> Attachments: DirectBuffer.java
>
> 1. java.nio.CharBuffer
> 1.1) java.nio.CharBuffer needs to implement two new interface java.lang.Appendable and java.lang.Readable
> 1.2) The following methods should NOT be "protected":
> protected CharBuffer(int capacity)
> protected abstract char[] protectedArray();
> protected abstract int protectedArrayOffset();
> protected abstract boolean protectedHasArray();
>
> 1.3) The following method should be "final":
> public CharBuffer put(char[] src)
>
> 2. java.nio.Buffer
> 2.1) The following fields should NOT be "protected":
> int UNSET_MARK
> int capacity
> int limit
> int mark should
> int position
> 2.3) The following method should NOT be "protected":
> protected Buffer(int capacity)
> 3. java.nio.ByteBuffer, DoubleBuffer, FloatBuffer, IntBuffer, LongBuffer, ShortBuffer
> 3.1) The following field should NOT be "protected":
> com.ibm.platform.Endianness order
> 3.2) The following methods should NOT be "protected":
> protected ByteBuffer(int capacity)
> protected abstract byte[] protectedArray();
> protected abstract int protectedArrayOffset();
> protected abstract boolean protectedHasArray();
> 3.3) The following method should be "final":
> public ByteBuffer order(ByteOrder byteOrder)
>
> 4. The implementation of bulk put/get methods of all the buffer classes are low-efficiency
>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (HARMONY-26) The API of buffer classes in
java.nio are not compliant with the specification of Java 5.0
Posted by "Richard Liang (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/HARMONY-26?page=comments#action_12363202 ]
Richard Liang commented on HARMONY-26:
--------------------------------------
Hello Tim,
There are several unnecessary fields/methods caused by the implementation classes of NIO buffers being in a separate internal package com.ibm.io.nio. To solve this issue, we can just move the implementation classes back to java.nio and make them package private. I will describe details below. There are lots of steps required to keep the code building right, if you prefer I can just send the updated code. Let me know whether you are satisfied with our solution. Thanks a lot.
1. Move all classes in com.ibm.io.nio *except* FileChannelImpl, FileLockImpl and LockManager (total 35 classes) from com.ibm.io.nio into java.nio.
2. For the 35 moved classes, change their package statement from com.ibm.io.nio to java.nio
3. For the 35 moved classes, remove the *unnecessary* import statements of java.nio
4. For the 7 classes java.nio.ByteBuffer, CharBuffer, DoubleBuffer, FloatBuffer, IntBuffer, LongBuffer, and
ShortBuffer, Remove the *unnecessary* import statement "import com.ibm.io.nio.BufferFactory;"
**note** The above 4 steps can be conveniently achieved if you use "Refactor -> move" in Eclipse.
5. Add a new interface in com.ibm.io.nio called DirectBuffer (I will attach the file to JIRA)
6. Make java.nio.DirectByteBuffer to implement the new interface com.ibm.io.nio.DirectBuffer by:
6.1 Adding import statement: import com.ibm.io.nio.DirectBuffer
6.2 Changing Class declaration from
"abstract class DirectByteBuffer extends BaseByteBuffer"
to
"abstract class DirectByteBuffer extends BaseByteBuffer implements DirectBuffer"
7. Change the following "protected" methods of java.nio.DirectByteBuffer to "public"
7.1 isAddressValid()
7.2 addressValidityCheck()
7.3 PlatformAddress getBaseAddress()
7.4 PlatformAddress getEffectiveAddress()
7.5 free()
8. In com.ibm.io.nio.FileChannelImpl:
8.1 Add import statement: "import java.nio.Buffer"
8.2 In method "public int read(ByteBuffer buffer)",
8.2.1 Change the line 270:
"DirectByteBuffer directBuffer = (DirectByteBuffer) buffer;"
to "DirectBuffer directBuffer = (DirectBuffer) buffer;"
8.2.2 Remove line 275:
"HeapByteBuffer heapBuffer = (HeapByteBuffer) buffer;"
8.2.3 Change the line 275 & 276:
"bytesRead = (int) fileSystem.read(handle, heapBuffer.array(),
heapBuffer.arrayOffset(), buffer.remaining());"
to "bytesRead = (int) fileSystem.read(handle, buffer.array(),
buffer.arrayOffset(), buffer.remaining());"
8.3 We do the same for the method "public int write(ByteBuffer buffer)",
8.3.1 Change the line 348:
"DirectByteBuffer directBuffer = (DirectByteBuffer) buffer;"
to "DirectBuffer directBuffer = (DirectBuffer) buffer;"
8.3.2 Remove line 353:
"HeapByteBuffer heapBuffer = (HeapByteBuffer) buffer;"
8.3.3 Change the line 353 & 354:
"bytesWritten = (int) fileSystem.write(handle, heapBuffer
.array(), heapBuffer.arrayOffset(), buffer.remaining());"
to "bytesWritten = (int) fileSystem.write(handle, buffer
.array(), buffer.arrayOffset(), buffer.remaining());"
9. Make java.nio.BufferFactory as package private by removing "public" at line 31
10. Make java.nio.DirectByteBuffer.SafeAddress as package private by removing "protected" at line 39.
11. Make java.nio.DirectByteBuffers as package private by removing "public" at line 27
12. Remove the "protected" modifier of the following fields:
java.nio.Buffer.UNSET_MARK
java.nio.Buffer.capacity
java.nio.Buffer.limit
java.nio.Buffer.mark
java.nio.Buffer.position
java.nio.ByteBuffer.order
java.nio.MappedByteBuffer.mapMode
java.nio.MappedByteBuffer.mappedFile
java.nio.MappedByteBuffer.offset
java.nio.MappedByteBuffer.wrappedBuffer
12. Remove the "protected" modifier of the constructor of java.nio.Buffer: "protected Buffer(int capacity)"
13. For the classes java.nio.ByteBuffer, CharBuffer, DoubleBuffer, FloatBuffer, IntBuffer, LongBuffer, ShortBuffer, remove the "protected" modifier of:
13.1 protected constructor
13.2 protected abstract byte[] protectedArray()
13.3 protected abstract int protectedArrayOffset()
13.4 protected abstract boolean protectedHasArray()
14. Remove the "protected" modifier of the following methods in java.nio.MappedByteBuffer
protected MappedByteBuffer(File mappedFile, long offset, int size, MapMode mapMode)
protected MappedByteBuffer(File mappedFile, long offset, int size, MapMode mapMode, ByteBuffer wrappedBuffer)
15. Make the following field "final"
public ByteBuffer order(ByteOrder byteOrder) in java.nio.ByteBuffer
public CharBuffer put(char[] src) in java.nio.CharBuffer
16. Remove method "public ByteBuffer order(ByteOrder byteOrder)" in java.nio.MappedToByteBufferAdapter (because this method is defined as "final" in its super class java.nio.ByteBuffer)
> The API of buffer classes in java.nio are not compliant with the specification of Java 5.0
> ------------------------------------------------------------------------------------------
>
> Key: HARMONY-26
> URL: http://issues.apache.org/jira/browse/HARMONY-26
> Project: Harmony
> Type: Bug
> Components: Classlib
> Reporter: Richard Liang
> Assignee: Tim Ellison
>
> 1. java.nio.CharBuffer
> 1.1) java.nio.CharBuffer needs to implement two new interface java.lang.Appendable and java.lang.Readable
> 1.2) The following methods should NOT be "protected":
> protected CharBuffer(int capacity)
> protected abstract char[] protectedArray();
> protected abstract int protectedArrayOffset();
> protected abstract boolean protectedHasArray();
>
> 1.3) The following method should be "final":
> public CharBuffer put(char[] src)
>
> 2. java.nio.Buffer
> 2.1) The following fields should NOT be "protected":
> int UNSET_MARK
> int capacity
> int limit
> int mark should
> int position
> 2.3) The following method should NOT be "protected":
> protected Buffer(int capacity)
> 3. java.nio.ByteBuffer, DoubleBuffer, FloatBuffer, IntBuffer, LongBuffer, ShortBuffer
> 3.1) The following field should NOT be "protected":
> com.ibm.platform.Endianness order
> 3.2) The following methods should NOT be "protected":
> protected ByteBuffer(int capacity)
> protected abstract byte[] protectedArray();
> protected abstract int protectedArrayOffset();
> protected abstract boolean protectedHasArray();
> 3.3) The following method should be "final":
> public ByteBuffer order(ByteOrder byteOrder)
>
> 4. The implementation of bulk put/get methods of all the buffer classes are low-efficiency
>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Closed: (HARMONY-26) The API of buffer classes in java.nio
are not compliant with the specification of Java 5.0
Posted by "Tim Ellison (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/HARMONY-26?page=all ]
Tim Ellison closed HARMONY-26:
------------------------------
> The API of buffer classes in java.nio are not compliant with the specification of Java 5.0
> ------------------------------------------------------------------------------------------
>
> Key: HARMONY-26
> URL: http://issues.apache.org/jira/browse/HARMONY-26
> Project: Harmony
> Type: Bug
> Components: Classlib
> Reporter: Richard Liang
> Assignee: Tim Ellison
> Attachments: DirectBuffer.java, nio-tests.jar
>
> 1. java.nio.CharBuffer
> 1.1) java.nio.CharBuffer needs to implement two new interface java.lang.Appendable and java.lang.Readable
> 1.2) The following methods should NOT be "protected":
> protected CharBuffer(int capacity)
> protected abstract char[] protectedArray();
> protected abstract int protectedArrayOffset();
> protected abstract boolean protectedHasArray();
>
> 1.3) The following method should be "final":
> public CharBuffer put(char[] src)
>
> 2. java.nio.Buffer
> 2.1) The following fields should NOT be "protected":
> int UNSET_MARK
> int capacity
> int limit
> int mark should
> int position
> 2.3) The following method should NOT be "protected":
> protected Buffer(int capacity)
> 3. java.nio.ByteBuffer, DoubleBuffer, FloatBuffer, IntBuffer, LongBuffer, ShortBuffer
> 3.1) The following field should NOT be "protected":
> com.ibm.platform.Endianness order
> 3.2) The following methods should NOT be "protected":
> protected ByteBuffer(int capacity)
> protected abstract byte[] protectedArray();
> protected abstract int protectedArrayOffset();
> protected abstract boolean protectedHasArray();
> 3.3) The following method should be "final":
> public ByteBuffer order(ByteOrder byteOrder)
>
> 4. The implementation of bulk put/get methods of all the buffer classes are low-efficiency
>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (HARMONY-26) The API of buffer classes in java.nio
are not compliant with the specification of Java 5.0
Posted by "Richard Liang (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/HARMONY-26?page=all ]
Richard Liang updated HARMONY-26:
---------------------------------
Attachment: nio-tests.jar
> The API of buffer classes in java.nio are not compliant with the specification of Java 5.0
> ------------------------------------------------------------------------------------------
>
> Key: HARMONY-26
> URL: http://issues.apache.org/jira/browse/HARMONY-26
> Project: Harmony
> Type: Bug
> Components: Classlib
> Reporter: Richard Liang
> Assignee: Tim Ellison
> Attachments: DirectBuffer.java, nio-tests.jar
>
> 1. java.nio.CharBuffer
> 1.1) java.nio.CharBuffer needs to implement two new interface java.lang.Appendable and java.lang.Readable
> 1.2) The following methods should NOT be "protected":
> protected CharBuffer(int capacity)
> protected abstract char[] protectedArray();
> protected abstract int protectedArrayOffset();
> protected abstract boolean protectedHasArray();
>
> 1.3) The following method should be "final":
> public CharBuffer put(char[] src)
>
> 2. java.nio.Buffer
> 2.1) The following fields should NOT be "protected":
> int UNSET_MARK
> int capacity
> int limit
> int mark should
> int position
> 2.3) The following method should NOT be "protected":
> protected Buffer(int capacity)
> 3. java.nio.ByteBuffer, DoubleBuffer, FloatBuffer, IntBuffer, LongBuffer, ShortBuffer
> 3.1) The following field should NOT be "protected":
> com.ibm.platform.Endianness order
> 3.2) The following methods should NOT be "protected":
> protected ByteBuffer(int capacity)
> protected abstract byte[] protectedArray();
> protected abstract int protectedArrayOffset();
> protected abstract boolean protectedHasArray();
> 3.3) The following method should be "final":
> public ByteBuffer order(ByteOrder byteOrder)
>
> 4. The implementation of bulk put/get methods of all the buffer classes are low-efficiency
>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Resolved: (HARMONY-26) The API of buffer classes in java.nio
are not compliant with the specification of Java 5.0
Posted by "Tim Ellison (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/HARMONY-26?page=all ]
Tim Ellison resolved HARMONY-26:
--------------------------------
Resolution: Fixed
Actually, that wasn't as bad as it looks at first sight. It is mostly refactoring to be spec compliant, no functional change.
Richard please can you review and verify.
> The API of buffer classes in java.nio are not compliant with the specification of Java 5.0
> ------------------------------------------------------------------------------------------
>
> Key: HARMONY-26
> URL: http://issues.apache.org/jira/browse/HARMONY-26
> Project: Harmony
> Type: Bug
> Components: Classlib
> Reporter: Richard Liang
> Assignee: Tim Ellison
> Attachments: DirectBuffer.java
>
> 1. java.nio.CharBuffer
> 1.1) java.nio.CharBuffer needs to implement two new interface java.lang.Appendable and java.lang.Readable
> 1.2) The following methods should NOT be "protected":
> protected CharBuffer(int capacity)
> protected abstract char[] protectedArray();
> protected abstract int protectedArrayOffset();
> protected abstract boolean protectedHasArray();
>
> 1.3) The following method should be "final":
> public CharBuffer put(char[] src)
>
> 2. java.nio.Buffer
> 2.1) The following fields should NOT be "protected":
> int UNSET_MARK
> int capacity
> int limit
> int mark should
> int position
> 2.3) The following method should NOT be "protected":
> protected Buffer(int capacity)
> 3. java.nio.ByteBuffer, DoubleBuffer, FloatBuffer, IntBuffer, LongBuffer, ShortBuffer
> 3.1) The following field should NOT be "protected":
> com.ibm.platform.Endianness order
> 3.2) The following methods should NOT be "protected":
> protected ByteBuffer(int capacity)
> protected abstract byte[] protectedArray();
> protected abstract int protectedArrayOffset();
> protected abstract boolean protectedHasArray();
> 3.3) The following method should be "final":
> public ByteBuffer order(ByteOrder byteOrder)
>
> 4. The implementation of bulk put/get methods of all the buffer classes are low-efficiency
>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (HARMONY-26) The API of buffer classes in
java.nio are not compliant with the specification of Java 5.0
Posted by "Tim Ellison (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/HARMONY-26?page=comments#action_12363270 ]
Tim Ellison commented on HARMONY-26:
------------------------------------
Richard, I have taken your tests (with slight refactoring of pcakage names), and they pass with the latest version of the NIO code.
The tests are in NIO module, src/test/java/** at repository revision 370544.
> The API of buffer classes in java.nio are not compliant with the specification of Java 5.0
> ------------------------------------------------------------------------------------------
>
> Key: HARMONY-26
> URL: http://issues.apache.org/jira/browse/HARMONY-26
> Project: Harmony
> Type: Bug
> Components: Classlib
> Reporter: Richard Liang
> Assignee: Tim Ellison
> Attachments: DirectBuffer.java, nio-tests.jar
>
> 1. java.nio.CharBuffer
> 1.1) java.nio.CharBuffer needs to implement two new interface java.lang.Appendable and java.lang.Readable
> 1.2) The following methods should NOT be "protected":
> protected CharBuffer(int capacity)
> protected abstract char[] protectedArray();
> protected abstract int protectedArrayOffset();
> protected abstract boolean protectedHasArray();
>
> 1.3) The following method should be "final":
> public CharBuffer put(char[] src)
>
> 2. java.nio.Buffer
> 2.1) The following fields should NOT be "protected":
> int UNSET_MARK
> int capacity
> int limit
> int mark should
> int position
> 2.3) The following method should NOT be "protected":
> protected Buffer(int capacity)
> 3. java.nio.ByteBuffer, DoubleBuffer, FloatBuffer, IntBuffer, LongBuffer, ShortBuffer
> 3.1) The following field should NOT be "protected":
> com.ibm.platform.Endianness order
> 3.2) The following methods should NOT be "protected":
> protected ByteBuffer(int capacity)
> protected abstract byte[] protectedArray();
> protected abstract int protectedArrayOffset();
> protected abstract boolean protectedHasArray();
> 3.3) The following method should be "final":
> public ByteBuffer order(ByteOrder byteOrder)
>
> 4. The implementation of bulk put/get methods of all the buffer classes are low-efficiency
>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (HARMONY-26) The API of buffer classes in
java.nio are not compliant with the specification of Java 5.0
Posted by "Richard Liang (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/HARMONY-26?page=comments#action_12363247 ]
Richard Liang commented on HARMONY-26:
--------------------------------------
Yes, Tim. The fix has been properly applied :-) Thanks a lot.
And I have attached my unit test cases to JIRA.
> The API of buffer classes in java.nio are not compliant with the specification of Java 5.0
> ------------------------------------------------------------------------------------------
>
> Key: HARMONY-26
> URL: http://issues.apache.org/jira/browse/HARMONY-26
> Project: Harmony
> Type: Bug
> Components: Classlib
> Reporter: Richard Liang
> Assignee: Tim Ellison
> Attachments: DirectBuffer.java
>
> 1. java.nio.CharBuffer
> 1.1) java.nio.CharBuffer needs to implement two new interface java.lang.Appendable and java.lang.Readable
> 1.2) The following methods should NOT be "protected":
> protected CharBuffer(int capacity)
> protected abstract char[] protectedArray();
> protected abstract int protectedArrayOffset();
> protected abstract boolean protectedHasArray();
>
> 1.3) The following method should be "final":
> public CharBuffer put(char[] src)
>
> 2. java.nio.Buffer
> 2.1) The following fields should NOT be "protected":
> int UNSET_MARK
> int capacity
> int limit
> int mark should
> int position
> 2.3) The following method should NOT be "protected":
> protected Buffer(int capacity)
> 3. java.nio.ByteBuffer, DoubleBuffer, FloatBuffer, IntBuffer, LongBuffer, ShortBuffer
> 3.1) The following field should NOT be "protected":
> com.ibm.platform.Endianness order
> 3.2) The following methods should NOT be "protected":
> protected ByteBuffer(int capacity)
> protected abstract byte[] protectedArray();
> protected abstract int protectedArrayOffset();
> protected abstract boolean protectedHasArray();
> 3.3) The following method should be "final":
> public ByteBuffer order(ByteOrder byteOrder)
>
> 4. The implementation of bulk put/get methods of all the buffer classes are low-efficiency
>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira