Re: Are we going to do our own collections API impl too ??
Rajith, There is still work to do to bring these up to the 5.0 API. If you have an interest in this area please go ahead and send in some updates(*), they will be very much appreciated. (*) The only caveat at the moment is that the entire classlib code is being compiled with the 1.4-source compatibility option, so APIs that use 5.0 language features will have to wait. Take a look at what is there, and send us a patch via JIRA. Regards, Tim Rajith Attapattu wrote: ok cool, did we do this from scratch or the code was donated by somebody or organization. On 1/23/06, Paulex Yang [EMAIL PROTECTED] wrote: There ARE an implementation now! Check out http://svn.apache.org/viewcvs.cgi/incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java/util/ Rajith Attapattu : Hi Guys, I assume we will be doing our own impl of the collections API as well at some point in time !! Looks like you guys are still building the core infra structure like JVM ect... So when do u guys think or rather plan to do sommething like the collection api or some of the other core API's in the jdk?? Any road map or project plan that sort of describes these things :) ? Regards, Rajith. -- Paulex Yang China Software Development Lab IBM -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
Re: java.util.concurrent implementation
AIUI the Unsafe type is Sun's means of manipulating OS heap memory -- classlib has a type that does that (currently in NIO module, and called com.ibm.platform.OSMemory, though I agree with Paulex that it should move into LUNI). If the functionality of OSMemory is lacking we can, of course, extend it to support concurrent. Regards, Tim Rodrigo Kumpera wrote: Can we import the backport of jsr-166 as the starting point for implementing this package? It's released as public domain, so there should be not license issue IFAIK. There are only a few things required make it work, like removing references to com.sun.Unsafe. -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
[jira] Commented: (HARMONY-38) com.ibm.platform.struct.AbstractMemorySpy doesn't actually autoFree native memory
[
http://issues.apache.org/jira/browse/HARMONY-38?page=comments#action_12363811 ]
Tim Ellison commented on HARMONY-38:
Paulex,
I've fixed the autoFree() problem described above in NIO
com.ibm.platform.struct.AbstractMemorySpy.java at repo revision 371895.
If you have a patch for the WeakReference/PhantomReference issue please send it
along, otherwise I'm happy to take a look at it myself.
com.ibm.platform.struct.AbstractMemorySpy doesn't actually autoFree native
memory
-
Key: HARMONY-38
URL: http://issues.apache.org/jira/browse/HARMONY-38
Project: Harmony
Type: Bug
Components: Classlib
Reporter: Paulex Yang
Assignee: Tim Ellison
Priority: Critical
com.ibm.platform.struct.IMemorySpy is a memory watcher, and the
AbstractMemorySpy is a default implementation working with nio direct buffers
to free the native memories when direct buffer instances are garbage
collected. But currently its auto free donsn't work.
Look inside the orphanedMemory(Object obj) method, the memory is freed only
if the local variable wrapper can be found from the memoryInUse, a Map which
records the native memories used by direct buffers, but actually it will be
removed when autoFree(PlatfromAddress) is invoked. Checking the autoFree()
reference, I found that all DirectByteBuffer will invoke autoFree() in
constructor, which means no memory will be freed.
A simple fix:
modify the Ln 94 in autoFree() from:
wrapper = (AddressWrapper) memoryInUse.remove(address);
to:
wrapper = (AddressWrapper) memoryInUse.get(address);
and it should work.
The steps to reproduce the bug:
1. Add the following line in the the Ln109, which indicates the memory is
auto freed by AbstractMemorySpy
System.out.println(MemorySpy autofree:+wrapper.shadow);
2. Run the test below:
public class MemorySpyTest {
public static void main(String[] args) throws Exception {
for (int i = 0; i 1000; i++) {
try{
ByteBuffer buffer = ByteBuffer.allocateDirect(1024);
buffer = null;
}catch(Exception e){
e.printStackTrace();
}
System.gc();
}
}
Before modification: application exits silently.
After modification, hundres of lines printed out, like this:
.
MemorySpy autofree:PlatformAddress[9310024]
MemorySpy autofree:PlatformAddress[9311056]
MemorySpy autofree:PlatformAddress[9312088]
MemorySpy autofree:PlatformAddress[9313120]
MemorySpy autofree:PlatformAddress[9314152]
MemorySpy autofree:PlatformAddress[9315184]
MemorySpy autofree:PlatformAddress[9316216]
MemorySpy autofree:PlatformAddress[9317248]
...
Another possible pitfall in AbstractMemorySpy is it uses WeakReference and
ReferenceQueue to get notification when the buffers are ready to be garbage
collected. But it is not so safe yet to free the native memory, because the
weakly-reachable object has its chance to be resurrected to
strongly-reachable, if only some finalize() method doing this is executed. A
safer solution is to use PhantomReference instead, because phantom-reachable
object has no chance to survive. The only concern is the PhantomReference
should be explicitly cleared by application, but that's OK because the
orphanedMemory() method is a perfect candidate to do this.
I will attach the patch soon.
--
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: java.util.concurrent implementation
OK -- thanks Rodrigo. Those types of atomic ops are not in the OSMemory type right now. If we get the concurrent code we can look at the full set of requirements and implement them in classlib. Regards, Tim Rodrigo Kumpera wrote: util.concurrent needs two pieces of unsafe functionality: atomic operations like compare and set, compare and increment, etc; and field offset discovering needed by AtomicIntegerFieldUpdater, for example. The other parts don't require special handling besides LockSupport with would benefit from som changes in java.lang.Thread. On 1/24/06, Tim Ellison [EMAIL PROTECTED] wrote: AIUI the Unsafe type is Sun's means of manipulating OS heap memory -- classlib has a type that does that (currently in NIO module, and called com.ibm.platform.OSMemory, though I agree with Paulex that it should move into LUNI). If the functionality of OSMemory is lacking we can, of course, extend it to support concurrent. Regards, Tim Rodrigo Kumpera wrote: Can we import the backport of jsr-166 as the starting point for implementing this package? It's released as public domain, so there should be not license issue IFAIK. There are only a few things required make it work, like removing references to com.sun.Unsafe. -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
Re: ntwin32.mak dependency
Geir Magnusson Jr schrieb: Please, feel free to take a whack at it. Just don't break us that are using the non-free toolchain. I was just curious if I was doing something wrong and generally the opinion, that it would make sense to not require a rather expensive compiler suite to build the Harmony VM. I am not sure however if I can be of much help fixing the issue. I haven't been writing much C for several years and honestly have no clue what is necessary to tweek the source to be buildable by other compilers. Tor
Re: [classlib] Unit and performance testing
On 1/24/06, Tim Ellison [EMAIL PROTECTED] wrote: Mikhail Loenko wrote: Hello We have figured out that one of approcahes that was earlier dicussed and that I originally opposed would work for us. That is: get PerformanceTest class out of there and replace log() with calls to java.util.logging.Logger. Please let me know what you think. What are you logging? Normally any information that would be useful to easily detect the reason of failure. A good test explains why it failed, the best test submits a bug report and provides a patch, the worst test just complains that it failed. I would not wish to debug just to figure out that the reason of failures is that I've forgot to include something to classpath or there is another config problem Nobody is going to search log files looking for success/failure messages. Agreed If the test passes, then all is fine; if it does not pass then it should inform the framework (i.e. a failing assertion or an explicit call to fail()). At that point JUnit will give you a cause of failure, and if fail() is not always convinient, for example, how would you print stack trace to fail()? Meanwhile stacktrace is most often enough to find what the problems are and sort them out. Thanks, Mikhail that is not enough you debug it with a debugger not println's. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
[jira] Resolved: (HARMONY-30) java.text.BreakIterator.next () returns incorrect value
[ http://issues.apache.org/jira/browse/HARMONY-30?page=all ]
Tim Ellison resolved HARMONY-30:
Resolution: Fixed
Tatyana,
Fixed in TEXT module java.text.BreakIterator.java at repo revision 371905.
Please check that it fully resolves your problem.
java.text.BreakIterator.next () returns incorrect value
Key: HARMONY-30
URL: http://issues.apache.org/jira/browse/HARMONY-30
Project: Harmony
Type: Bug
Components: Classlib
Reporter: tatyana doubtsova
Assignee: Tim Ellison
java.text.BreakIterator.next () returns incorrect value
Code for reproducing Test.java:
import java.text.BreakIterator;
import java.util.Locale;
public class Test {
public static void main (String[] args) {
BreakIterator bi = BreakIterator.getWordInstance(Locale.US);
bi.setText(This is the test, WordInstance);
int n = bi.first();
System.out.println(bi.first() = + n);
n = bi.next();
System.out.println(bi.next() = + n);
}
}
Steps to Reproduce:
1. Build Harmony-14 j2se subset as described in README.txt.
2. Compile Test.java using BEA 1.4 javac
javac -d . Test.java
2. Run java using compatible VM (J9)
java -showversion Test
Output:
java version 1.4.2 (subset)
(c) Copyright 1991, 2005 The Apache Software Foundation or its licensors, as
applicable.
bi.first() = 0
bi.next() = 30
Output on BEA 1.4.2 to compare with:
bi.first() = 0
bi.next() = 4
Suggested junit test case:
package org.apache.harmony.tests.java.text;
import java.text.BreakIterator;
import java.util.Locale;
import junit.framework.TestCase;
public class BreakIteratorTest extends TestCase {
public static void main(String[] args) {
junit.textui.TestRunner.run(BreakIteratorTest.class);
}
public void test_next() {
BreakIterator bi = BreakIterator.getWordInstance(Locale.US);
bi.setText(This is the test, WordInstance);
int n = bi.first();
n = bi.next();
assertTrue(Assert 0: next() returns incorrect value + n, n
== 4 );
}
}
--
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-36) java.nio.CharBuffer does not implement java.lang.Appendable and java.lang.Readable
[ http://issues.apache.org/jira/browse/HARMONY-36?page=all ] Tim Ellison resolved HARMONY-36: Resolution: Fixed Richard, Fixed in LUNI and NIO modules at repo revision 371907. Please check and confirm this patch. java.nio.CharBuffer does not implement java.lang.Appendable and java.lang.Readable -- Key: HARMONY-36 URL: http://issues.apache.org/jira/browse/HARMONY-36 Project: Harmony Type: Bug Components: Classlib Reporter: Richard Liang Assignee: Tim Ellison Attachments: Appendable.java, CharBufferTest_patch.txt, CharBuffer_patch.txt, CharSequenceAdapter_patch.txt, Readable.java In Java 5, java.nio.CharBuffer are required to implement two new interfaces java.lang.Appendable and java.lang.Readable. I will attache the new interfaces and fix for java.nio.CharBuffer soon :-) -- 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-24) java.net.URLEncoder.encode(String s, String enc) doesn't throw UnsupportedEncodingException
[ http://issues.apache.org/jira/browse/HARMONY-24?page=all ]
Tim Ellison reassigned HARMONY-24:
--
Assign To: Tim Ellison (was: Geir Magnusson Jr)
java.net.URLEncoder.encode(String s, String enc) doesn't throw
UnsupportedEncodingException
---
Key: HARMONY-24
URL: http://issues.apache.org/jira/browse/HARMONY-24
Project: Harmony
Type: Bug
Components: Classlib
Reporter: Vladimir Strigun
Assignee: Tim Ellison
Corresponding to API specification method encode(String, String) of
java.net.URLEncoder should throw UnsupportedEncodingException - If the named
encoding is not supported. But the test shows that Harmony implementation
doesn't throw an exception.
import java.io.UnsupportedEncodingException;
import java.net.URLEncoder;
public class Test {
public static void main(String[] args) {
try {
System.out.println(URLEncoder.encode=+URLEncoder.encode(str,unknown_enc));
} catch (UnsupportedEncodingException e) {
e.printStackTrace();
}
}
}
--
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: [classlib] Unit and performance testing
I'd like to add that logging may help when you are not able to reproduce a bug. Thanks, Stepan Mishura Intel Middleware Products Division On 1/24/06, Mikhail Loenko [EMAIL PROTECTED] wrote: On 1/24/06, Tim Ellison [EMAIL PROTECTED] wrote: Mikhail Loenko wrote: Hello We have figured out that one of approcahes that was earlier dicussed and that I originally opposed would work for us. That is: get PerformanceTest class out of there and replace log() with calls to java.util.logging.Logger. Please let me know what you think. What are you logging? Normally any information that would be useful to easily detect the reason of failure. A good test explains why it failed, the best test submits a bug report and provides a patch, the worst test just complains that it failed. I would not wish to debug just to figure out that the reason of failures is that I've forgot to include something to classpath or there is another config problem Nobody is going to search log files looking for success/failure messages. Agreed If the test passes, then all is fine; if it does not pass then it should inform the framework (i.e. a failing assertion or an explicit call to fail()). At that point JUnit will give you a cause of failure, and if fail() is not always convinient, for example, how would you print stack trace to fail()? Meanwhile stacktrace is most often enough to find what the problems are and sort them out. Thanks, Mikhail that is not enough you debug it with a debugger not println's. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. -- Thanks, Stepan Mishura Intel Middleware Products Division
Re: 'security2' TODOs list
Stepan Mishura wrote: I'd like to create a list of TODO's to track all issues related to 'security2' module integration. Because it is hard to figure out from many threads in mailing list what things were done, what blocks us to move forward and what can be resolved later. Also this list should help us to understand who took responsibility for a selected item and where we can help. So here is the summary of issues: Issues that should be resolved before substituting the current 'security' module 1) Moving com.openintel to org.apache.harmony (status: almost DONE) Issues: - Did we agree on com.openintel.drlx.* - org.apache.harmony.x.*? Either way, it's done. Well, I don't remember that this variant was proposed and discussed: com.openintel.drlx.* - org.apache.harmony.security.x.* Nope - I just did it because I was in the middle of moving it. You made a good argument that we needed to keep *.drlx.* in a separate package, so I did that. I don't really care what it's called. So now we have org.apache.harmony.security.x.security.auth package name that looks quite strange for me. You should have seen the *.fortress.* package name. This comes down to organization, rather than aesthetics. We are going to have org.apache.harmony. I'd like to consider adding classlib in there to give a bit of future prooofing to o.a.h namespace. I do think for sanity sake, we want to have something that gives a hint on the module, hence org.apache.harmony.security as it's in the security module. Question: Is this a temporary naming pattern? I mean org.apache.harmony.element.x.*, otherwise I'd expect to have the following package names for support classes 1) javax.net http://javax.net - org.apache.harmony.net.x.* 2) javax.rmi - org.apache.harmony.rmi.x.* 3) javax.sql - org.apache.harmony.sql.x.* Are you OK with package names above? Well, right now, we have modules that span the java[x].* packaging, and that is reflected in the namespace. I'd like to keep that if we can. - Tim had problems with running security tests. Not sure - he didn't have the patience for one of them, and was startled by the amount of gibberish the tests spewed to stdout. Tim? As I understood Tim needs ant target 'tests.run' that simply runs tests. Yes - he was able to type ant tests.run, but thought there was a problem due to the verbose output, and he thought one test hung it ran so long. (KeyGen IIRC) 2) Integrate build files (status: NONE) - split 'security2' to components - compiling native code - compile and run unit tests I did integrate the build files. You can kick of an ant from the top and you get the whole thing. There is one issue regarding where jni.h comes from that George stumbled over, but I'll fix tha tnow. May be it make sense, as Leo suggested, to fill JIRA tracker say: integrate security2 build. And we'll provide a patch or series of patches (one for each issue) to enhance the current build with the following: - building a number of separate components from 'security2' - compiling native code on Windows and Linux - add target for compiling unit tests - add target for running unit tests Break these up into separate issues. We already should have targets for the above. The build modification is bounded with component reorg and discussion about test framework. But IMHO they are not blocker issues and our modifications may be adjusted later. Yep Issues that may be resolved later: 1) Writing JavaDoc (status: the discussion got stuck, no decision was made) 'security2' has com.intel.drl.spec_ref javadoc tag that should be replaced That will be replaced, at least with our own for now as we evolve the javadoc discussion. OK 2) New Modules or Components a. Providers: put providers into separate modules (status: no objections) See http://mail-archives.apache.org/mod_mbox/incubator-harmony- dev/200601.mbox/[EMAIL PROTECTED] mailto:dev/200601.mbox/[EMAIL PROTECTED]. com%3e b. Do reorg in security component: (status: no replies) Pick out JAAS, JGSS-API and SASL from 'security' module and create a separate module for them (name for module?). The rest of 'security' to be combined with 'crypto' module. See http://mail-archives.apache.org/mod_mbox/incubator-harmony- dev/200601.mbox/[EMAIL PROTECTED] mailto:dev/200601.mbox/[EMAIL PROTECTED]. com%3e Yep - that's a todo . 3) Performance testing (status: the discussion got stuck, no decision was made) There is PerformanceTest super class that should be substituted with some other mechanism. (JUnit decoration, simple Logger …) I think that there's general agreement we need another approach to this - it's too intrusive to have our test class hierarchy rooted in this... Agree that we need another approach but IMO this is not a blocker issue. 4) Test framework (status: the discussion got
Re: [classlib] Unit and performance testing
Mikhail Loenko wrote:
On 1/24/06, Tim Ellison [EMAIL PROTECTED] wrote:
Mikhail Loenko wrote:
Hello
We have figured out that one of approcahes that was earlier dicussed and that
I originally opposed would work for us.
That is: get PerformanceTest class out of there and replace log() with calls
to java.util.logging.Logger.
Please let me know what you think.
What are you logging?
Normally any information that would be useful to easily detect
the reason of failure. A good test explains why it failed, the best test
submits a bug report and provides a patch, the worst test
just complains that it failed.
Right - so in the event of failure, write all the information that you
need out.
In the event of success, don't.
I would not wish to debug just to figure out that the reason of failures is
that I've forgot to include something to classpath or there is another
config problem
Right - you look at the test output, which has the ClassNotFound
stacktrace. That's how I remember to put junit and bcprov in my classpath.
Nobody is going to search log files looking for success/failure messages.
Agreed
If the test passes, then all is fine; if it does not pass then it should
inform the framework (i.e. a failing assertion or an explicit call to
fail()). At that point JUnit will give you a cause of failure, and if
fail() is not always convinient, for example, how would you print
stack trace to fail()? Meanwhile stacktrace is most often enough
to find what the problems are and sort them out.
if (condition isn't met) {
System.out.printStackTrace()
fail()
}
Thanks,
Mikhail
that is not enough you debug it with a debugger not println's.
Regards,
Tim
--
Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.
Re: [classlib] Unit and performance testing
That's true - but then it should be turned on when you are looking for said bug. If things are running fine, keep the logging off. geir Stepan Mishura wrote: I'd like to add that logging may help when you are not able to reproduce a bug. Thanks, Stepan Mishura Intel Middleware Products Division On 1/24/06, Mikhail Loenko [EMAIL PROTECTED] wrote: On 1/24/06, Tim Ellison [EMAIL PROTECTED] wrote: Mikhail Loenko wrote: Hello We have figured out that one of approcahes that was earlier dicussed and that I originally opposed would work for us. That is: get PerformanceTest class out of there and replace log() with calls to java.util.logging.Logger. Please let me know what you think. What are you logging? Normally any information that would be useful to easily detect the reason of failure. A good test explains why it failed, the best test submits a bug report and provides a patch, the worst test just complains that it failed. I would not wish to debug just to figure out that the reason of failures is that I've forgot to include something to classpath or there is another config problem Nobody is going to search log files looking for success/failure messages. Agreed If the test passes, then all is fine; if it does not pass then it should inform the framework (i.e. a failing assertion or an explicit call to fail()). At that point JUnit will give you a cause of failure, and if fail() is not always convinient, for example, how would you print stack trace to fail()? Meanwhile stacktrace is most often enough to find what the problems are and sort them out. Thanks, Mikhail that is not enough you debug it with a debugger not println's. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. -- Thanks, Stepan Mishura Intel Middleware Products Division
[jira] Created: (HARMONY-43) Performance enhancement for nio buffers bulk get/put methods
Performance enhancement for nio buffers bulk get/put methods Key: HARMONY-43 URL: http://issues.apache.org/jira/browse/HARMONY-43 Project: Harmony Type: Improvement Components: Classlib Reporter: Richard Liang The performance of some bulk get/put methods can be enhanced. I will post the patches one by one. -- 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-43) Performance enhancement for nio buffers bulk get/put methods
[ http://issues.apache.org/jira/browse/HARMONY-43?page=all ] Richard Liang updated HARMONY-43: - Attachment: CharBuffer_patch.txt This patch is created against java.nio which will affect the following files: java.nio.CharBuffer java.nio.CharArrayBuffer java.nio.CharSequenceAdapter java.nio.CharToByteBufferAdapter java.nio.ReadOnlyCharArrayBuffer java.nio.ReadWriteCharArrayBuffer Performance enhancement for nio buffers bulk get/put methods Key: HARMONY-43 URL: http://issues.apache.org/jira/browse/HARMONY-43 Project: Harmony Type: Improvement Components: Classlib Reporter: Richard Liang Attachments: CharBuffer_patch.txt The performance of some bulk get/put methods can be enhanced. I will post the patches one by one. -- 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-43) Performance enhancement for nio buffers bulk get/put methods
[ http://issues.apache.org/jira/browse/HARMONY-43?page=all ] Tim Ellison reassigned HARMONY-43: -- Assign To: Tim Ellison Performance enhancement for nio buffers bulk get/put methods Key: HARMONY-43 URL: http://issues.apache.org/jira/browse/HARMONY-43 Project: Harmony Type: Improvement Components: Classlib Reporter: Richard Liang Assignee: Tim Ellison Attachments: CharBuffer_patch.txt The performance of some bulk get/put methods can be enhanced. I will post the patches one by one. -- 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-42) com.ibm.io.nio.FileChannel is not fully implemented
[ http://issues.apache.org/jira/browse/HARMONY-42?page=comments#action_12363844 ] Tim Ellison commented on HARMONY-42: Paulex, I don't understand this issue. The file you have attached is a modified version of the com.ibm.platform.IFileSystem.java that is in NIO. Your comment indicates that it is enhanced to support regular IO types, yet it appears that mmap is removed. Is that right? I'm not going to take this enhancement at the moment. Please provide further rationale. (Please can you send your enhancements as diff's rather than file replacements, it will make tehm much easier to evaluate.) Thanks, Tim com.ibm.io.nio.FileChannel is not fully implemented --- Key: HARMONY-42 URL: http://issues.apache.org/jira/browse/HARMONY-42 Project: Harmony Type: Bug Components: Classlib Reporter: Paulex Yang Assignee: Tim Ellison Attachments: IFileSystem.java Many functions of FileChannel, such as memory map, transfer, gathering/scattering I/O are not implemented. Further, three classes in java.io, FileInputStream FileOutputStream, and RandomAccessFile, are related to java.nio.FileChannel, so that they can be refactored to base on same JNI interface, just like the network channels and sockets. -- 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] Created: (HARMONY-44) some security2 unit tests log redundant information
some security2 unit tests log redundant information --- Key: HARMONY-44 URL: http://issues.apache.org/jira/browse/HARMONY-44 Project: Harmony Type: Improvement Components: Classlib Reporter: Mikhail Loenko Priority: Trivial Information that is logged by security2 unit tests should be revisited. For example the following logs at the beginning of tests are not necessary and should be removed: logln(==test_02: UnrecoverableKeyException==); There are 231 occurrences of this kind out of 534 total logging calls in the security2 unit tests. I'm going to submit a patch removing logln(==... -- 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-44) some security2 unit tests log redundant information
[ http://issues.apache.org/jira/browse/HARMONY-44?page=all ] Mikhail Loenko updated HARMONY-44: -- Attachment: patch.txt The patch that removes 'logln(==...' from security2 unit tests some security2 unit tests log redundant information --- Key: HARMONY-44 URL: http://issues.apache.org/jira/browse/HARMONY-44 Project: Harmony Type: Improvement Components: Classlib Reporter: Mikhail Loenko Priority: Trivial Attachments: patch.txt Information that is logged by security2 unit tests should be revisited. For example the following logs at the beginning of tests are not necessary and should be removed: logln(==test_02: UnrecoverableKeyException==); There are 231 occurrences of this kind out of 534 total logging calls in the security2 unit tests. I'm going to submit a patch removing logln(==... -- 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: [classlib] Unit and performance testing
OK, I'll review the logs and remove those ones that certainly unnecessary. Then we'll see what are the remaining ones and what to do with them. Thanks, Mikhail. On 1/24/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: That's true - but then it should be turned on when you are looking for said bug. If things are running fine, keep the logging off. geir Stepan Mishura wrote: I'd like to add that logging may help when you are not able to reproduce a bug. Thanks, Stepan Mishura Intel Middleware Products Division On 1/24/06, Mikhail Loenko [EMAIL PROTECTED] wrote: On 1/24/06, Tim Ellison [EMAIL PROTECTED] wrote: Mikhail Loenko wrote: Hello We have figured out that one of approcahes that was earlier dicussed and that I originally opposed would work for us. That is: get PerformanceTest class out of there and replace log() with calls to java.util.logging.Logger. Please let me know what you think. What are you logging? Normally any information that would be useful to easily detect the reason of failure. A good test explains why it failed, the best test submits a bug report and provides a patch, the worst test just complains that it failed. I would not wish to debug just to figure out that the reason of failures is that I've forgot to include something to classpath or there is another config problem Nobody is going to search log files looking for success/failure messages. Agreed If the test passes, then all is fine; if it does not pass then it should inform the framework (i.e. a failing assertion or an explicit call to fail()). At that point JUnit will give you a cause of failure, and if fail() is not always convinient, for example, how would you print stack trace to fail()? Meanwhile stacktrace is most often enough to find what the problems are and sort them out. Thanks, Mikhail that is not enough you debug it with a debugger not println's. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. -- Thanks, Stepan Mishura Intel Middleware Products Division
