Re: [jira] Assigned: (HARMONY-88) Contribution of code and unit tests for jndi, logging, prefs and sql plus unit tests only for beans, crypto, math, regex and security
Dears, I'm trying to build the new code and run the unit tests, and I find there are lots of test cases fail/error when run the Beans tests with Beans implementation of JIRA#39. java.beans Error 135, Failure 230 (total test cases = 759) java.beans.beancontext Error 68, Failure 31 (total test cases = 245) After a rough investigation, I find there are two major problems in the Beans implementation: 1. Improper class loader used. e.g., Line 113 of java.beans.Beans Class c = Class.forName(beanName, true, cls); 2. Some methods do not handle null argument Not sure whether I can create JIRA issues. Maybe after the two contribution (39 and 88) are accepted :-) Richard Liang China Software Development Lab, IBM Geir Magnusson Jr (JIRA) wrote: [ http://issues.apache.org/jira/browse/HARMONY-88?page=all ] Geir Magnusson Jr reassigned HARMONY-88: Assign To: Geir Magnusson Jr Contribution of code and unit tests for jndi, logging, prefs and sql plus unit tests only for beans, crypto, math, regex and security -- Key: HARMONY-88 URL: http://issues.apache.org/jira/browse/HARMONY-88 Project: Harmony Type: New Feature Components: Contributions Environment: Win32 and Linux Reporter: George Harley Assignee: Geir Magnusson Jr Attachments: Harmony-Contribution.zip Zip file containing implementation and unit test code for the following Harmony components : * jndi * logging * prefs * sql In addition there is unit test code only for the following Harmony components : * beans * crypto * math * regex * security The contents of this zip have been laid out with the current classlib directory structure of the Apache Harmony SVN repository in mind. A version of enhanced/classlib/trunk/make/build-java.xml is included containing new Ant targets to compile the new implementation plus tests code, and then run the tests. Native code, plus makefiles are included to build a shared library that is required to support the prefs implementation on the win.IA32 platform. Not all of the unit test classes are capable of being compiled when the Ant target compile-tests in EXTRACT_DIR/Harmony/make/build-java.xml is run. This is because the current contents of the Harmony trunk do not satisfy all of the dependencies of some classes. This issue affects the unit test code for the following set of components ... * beans (needs beans implementation in trunk) * crypto (needs crypto implementation in trunk) * logging (needs beans implementation in trunk) * jndi (needs applet implementation in trunk) * sql (needs rmi implementation in trunk) As a temporary measure, the lines of Ant script in EXTRACT_DIR/Harmony/make/build-java.xml that compile the above test code have been commented out with explanations.
Re: newbie to project-where to start from
karan malhi wrote: Tim, Thanks for such a detailed reply. I have a couple of more questions: 1. Do I have to sign and fax back the questionnaire before I start working on harmony ? It would be good to have that information, yes. We want to be able to demonstrate the provenance of our code, and this is a major element in the system. 2. I know this is dumb but I saw in some previous posts that the tests were being compiled with jrockit. You can compile with whatever you want. However, we're trying to always move closer to self-hosting, so we've been specifying the eclipse compiler in the ant build scripts. So what I would do is mimic what we already have going on there. I guess I can use any compiler (sun) without causing any licensing issues - right? Absolutely. Use whatever compiler you choose. And even if there was an issue w/ the binary, you would only be contributing the source code anyway. Sorry, but I am very poor with this licensing stuff. Just want to make sure I am playing within the rules of the game. No one here is a lawyer - it's hard for all of us... geir
Re: I welcome J2SE 6's faster-splash.... re: Java speed-up
On 2/16/06, Fernando Cassia [EMAIL PROTECTED] wrote: [snip] You try to sound clever by making that statement, but imho, despite any other speed-up work who might be implemented, Sun's solution is very important, and something that should have been implemented a long, long time ago. I welcome their implementation, even if late. Get this: Splash screens sever an important purpose: they're a visual cue to tell the user that the program is loading (even if it takes a long time). Yes, splash screen feature is very important from usability point of you. However the problem itself is not completely clear for me: even early I was able to show splash screen if I wanted. Obviously, Swing stuff takes to much time to be initialized, but it start initialization only when the first reference to Swing is processed, i.e. direct or indirect call requires UIManager to be loaded. Therefore you can easily show splash screen at the begging of the program and continue with loading all other 'heavy-weight' stuff then. Does it make sense? For instance, I used SWT just to show splash screen quickly and then continue with Swing-based UI. Of course, such approach requires VM to be completely initialized anyway (in contrast to Mustang's splashes). I welcome any approaches which makes JVM start up faster :-) -- Anton Avtamonov, Intel Middleware Products Division
[jira] Updated: (HARMONY-80) serialVersionUID is missed in org.ietf.jgss.GSSException
[ http://issues.apache.org/jira/browse/HARMONY-80?page=all ] Stepan Mishura updated HARMONY-80: -- Attachment: fixHarmony80.txt Tim, Good catch! Thank you. It indeed incorrect and I'd change bug summary to: GSSException has the incorrect serialized form, but I don't know how to do this. The fix is attached. serialVersionUID is missed in org.ietf.jgss.GSSException Key: HARMONY-80 URL: http://issues.apache.org/jira/browse/HARMONY-80 Project: Harmony Type: Bug Components: Classlib Reporter: Stepan Mishura Priority: Trivial Attachments: fix.txt, fixHarmony80.txt According to Java Spec 5.0 serialVersionUID for org.ietf.jgss.GSSException class is -2706218945227726672L. -- 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-96) Two new methods need to be implemented by java.nio.charset.Charset
Two new methods need to be implemented by java.nio.charset.Charset -- Key: HARMONY-96 URL: http://issues.apache.org/jira/browse/HARMONY-96 Project: Harmony Type: Improvement Components: Classlib Reporter: Richard Liang There are two new methods added since Java 5.0 1. public static Charset defaultCharset() 2. public final int compareTo(Charset that) I'd like to implement the two methods and attach my code 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-80) GSSException has the incorrect serialized form
[ http://issues.apache.org/jira/browse/HARMONY-80?page=all ] Tim Ellison reassigned HARMONY-80: -- Assign To: Tim Ellison GSSException has the incorrect serialized form -- Key: HARMONY-80 URL: http://issues.apache.org/jira/browse/HARMONY-80 Project: Harmony Type: Bug Components: Classlib Reporter: Stepan Mishura Assignee: Tim Ellison Priority: Trivial Attachments: fix.txt, fixHarmony80.txt According to Java Spec 5.0 serialVersionUID for org.ietf.jgss.GSSException class is -2706218945227726672L. -- 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] do we need a global exclude list?
Geir Magnusson Jr wrote: Stepan Mishura wrote: Did anybody think of creating a 'global' (i.e. shared by all modules) exclude list or every module will have its own exclude list? Or Harmony tests will always pass and we don't need it at all :-) That would be the goal :) I see at least the following benefits of creating 'global' exclude list: all know issues are kept in one well known place (they don't spread between several private lists) That's true, but I always imagined that people would be working in the modules anyway, so there isn't much gain. Modules should be as self-sufficient as we can make them, so devolving tests and their exclude lists into a module makes sense to me too. They can be linked into a global view quite easily (read on...) also it is easier to create an exclude list for a target platform, for example, linux.exclude or win.exclude. Yes, that could be. Interesting idea. The mechanism that George contributed in HARMONY-57 uses a decorator to implement an exclusion list on regular JUnit tests. (I happen to know that George is off enjoying himself for the next few days, so I hope he doesn't mind me describing it here.) The exclusion list is implemented as a (declarative) XML file read when the tests run -- in HARMONY-57 you can see one in Harmony_Tests/src/test/resources/config/jcltest-excludes.xml Picking an entry at random from there: ... hy:type id=tests.api.java.io.FileTest hy:exclude id=test_Constructor_String_String_112270 shouldfix=true hy:reasonUndiagnosed failure/hy:reason /hy:exclude hy:exclude id=test_Constructor_File_String_112270 shouldfix=true hy:reasonUndiagnosed failure/hy:reason /hy:exclude hy:exclude id=test_deleteOnExit shouldfix=true hy:reasonNeeds investigation.../hy:reason /hy:exclude /hy:type ... You can see how it works -- some tests are excluded because they fail and should be fixed, others (not shown here) can be excluded because they don't make sense on a particular platform, VM, etc. Applying a style sheet makes it easy to read the exclusions list in glorious technicolor, either in an individual module or as a combined global view. Take a look at the incoming contribution and see if it fits your needs. Regards, Tim However, I did imagine that we'd give the modules a bit of freedom and independence for testing - a global exclude list might impact that? geir Thoughts? Thanks, Stepan Mishura Intel Middleware Products Division -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
Re: Mission impossible: new APIs without spec in Java 5.0
Hi, What is wrong if you prepare unit tests and investigate how it works? I think that is valid approach for such cases. Am I wrong? -- Anton Avtamonov, Intel Middleware Products Division On 2/16/06, Richard Liang [EMAIL PROTECTED] wrote: Dears, There are three protected methods added in java.text.BreakIterator, but I cannot find their specification. What shall we do? protected static long getLong(byte[] buf, int offset) protected static int getInt(byte[] buf, int offset) protected static short getShort(byte[] buf, int offset) -- Richard Liang China Software Development Lab, IBM
[jira] Resolved: (HARMONY-80) GSSException has the incorrect serialized form
[ http://issues.apache.org/jira/browse/HARMONY-80?page=all ] Tim Ellison resolved HARMONY-80: Resolution: Fixed Stepan, Fixed in security2 org.ietf.jgss.GSSException at repo revision 378205. Please check that the patch has been applied as you expected. GSSException has the incorrect serialized form -- Key: HARMONY-80 URL: http://issues.apache.org/jira/browse/HARMONY-80 Project: Harmony Type: Bug Components: Classlib Reporter: Stepan Mishura Assignee: Tim Ellison Priority: Trivial Attachments: fix.txt, fixHarmony80.txt According to Java Spec 5.0 serialVersionUID for org.ietf.jgss.GSSException class is -2706218945227726672L. -- 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: I welcome J2SE 6's faster-splash.... re: Java speed-up
Anton Avtamonov wrote: On 2/16/06, Fernando Cassia [EMAIL PROTECTED] wrote: [snip] You try to sound clever by making that statement, but imho, despite any other speed-up work who might be implemented, Sun's solution is very important, and something that should have been implemented a long, long time ago. I welcome their implementation, even if late. Get this: Splash screens sever an important purpose: they're a visual cue to tell the user that the program is loading (even if it takes a long time). Yes, splash screen feature is very important from usability point of you. However the problem itself is not completely clear for me: even early I was able to show splash screen if I wanted. Obviously, Swing stuff takes to much time to be initialized, but it start initialization only when the first reference to Swing is processed, i.e. direct or indirect call requires UIManager to be loaded. Therefore you can easily show splash screen at the begging of the program and continue with loading all other 'heavy-weight' stuff then. Does it make sense? For instance, I used SWT just to show splash screen quickly and then continue with Swing-based UI. Of course, such approach requires VM to be completely initialized anyway (in contrast to Mustang's splashes). I welcome any approaches which makes JVM start up faster :-) A common technique is for the launcher to open the dialog box (using native platform win man of course), then pass the handle to Java to close after start-up. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
[jira] Created: (HARMONY-97) ZipOutputStream.close() throws IOException if the stream is already closed
ZipOutputStream.close() throws IOException if the stream is already closed
--
Key: HARMONY-97
URL: http://issues.apache.org/jira/browse/HARMONY-97
Project: Harmony
Type: Bug
Components: Classlib
Reporter: Svetlana Samoilenko
According to 1.5 specification for сlose() method in interface Closeable:
Closes this stream and releases any system resources associated with it.
If the stream is already closed then invoking this method has no effect.
Harmony throws IOException if the stream is already closed.
Code to reproduce:
import java.io.*;
import java.util.zip.*;
public class test2 {
public static void main(String args[]) {
ZipOutputStream zos = null;
try {
File f=new File(myFile);
f.createNewFile();
f.deleteOnExit();
FileOutputStream ff=new FileOutputStream(f);
BufferedOutputStream b=new BufferedOutputStream(ff);
zos=new ZipOutputStream(new BufferedOutputStream(b));
zos.putNextEntry(new ZipEntry(myFile));
} catch (IOException ee) {
ee.printStackTrace();
}
try {
zos.close();
zos.close();
System.out.println(PASSED);
} catch (IOException ee) {
System.out.println(FAILED);
ee.printStackTrace();
}
}
}
Steps to Reproduce:
1. Build Harmony (check-out on 2006-01-30) j2se subset as described in
README.txt.
2. Compile test2.java using BEA 1.4 javac
javac -d . test2.java
3. Run java using compatible VM (J9)
java -showversion test2
Output:
C:\tmpC:\jrockit-j2sdk1.4.2_04\bin\java.exe -showversion test2
java version 1.4.2_04
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_04-b05)
BEA WebLogic JRockit(TM) 1.4.2_04 JVM (build ari-31788-20040616-1132-win-ia32,
Native Threads, GC strategy: parallel)
PASSED
C:\tmpC:\harmony\trunk\deploy\jre\bin\java -showversion test2
(c) Copyright 1991, 2005 The Apache Software Foundation or its licensors, as
applicable.
FAILED
java.io.IOException: Stream is closed
at java.util.zip.ZipOutputStream.finish(ZipOutputStream.java:157)
at java.util.zip.ZipOutputStream.close(ZipOutputStream.java:66)
at test2.main(test2.java:26)
Suggested fix:
Index: trunk/modules/archive/src/main/java/java/util/zip/ZipOutputStream.java
===
--- trunk/modules/archive/src/main/java/java/util/zip/ZipOutputStream.java
(revision 378195)
+++ trunk/modules/archive/src/main/java/java/util/zip/ZipOutputStream.java
(working copy)
@@ -77,8 +77,7 @@
*/
public void close() throws IOException {
finish();
- out.close();
- out = null;
+ out.close();
}
/**
@@ -165,9 +164,7 @@
* @exception IOException
*If an error occurs while finishing
*/
- public void finish() throws IOException {
- if (out == null)
- throw new
IOException(Msg.getString(K0059));
+ public void finish() throws IOException {
if (cDir == null)
return;
if (entries.size() == 0)
Suggested junit test case:
ZipOutputStreamTest.java
-
import junit.framework.*;
import java.util.zip.*;
import java.io.*;
public class ZipOutputStreamTest extends TestCase {
public static void main(String[] args) {
junit.textui.TestRunner.run(ZipOutputStream.class);
}
public void test_close() {
ZipOutputStream zos = null;
try {
File f=new File(myFile);
f.createNewFile();
f.deleteOnExit();
FileOutputStream ff=new FileOutputStream(f);
BufferedOutputStream b=new BufferedOutputStream(ff);
zos=new ZipOutputStream(new BufferedOutputStream(b));
zos.putNextEntry(new ZipEntry(myFile));
} catch (IOException ee) {
fail(Unnexpected IOException);
}
try {
zos.close();
zos.close();
} catch (IOException ee) {
fail(Unnexpected IOException);
}
}
}
--
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] do we need a global exclude list?
On 2/16/06, Geir Magnusson Jr geir at pobox.com wrote: Stepan Mishura wrote: Did anybody think of creating a 'global' (i.e. shared by all modules) exclude list or every module will have its own exclude list? Or Harmony tests will always pass and we don't need it at all :-) That would be the goal :) I see at least the following benefits of creating 'global' exclude list: all know issues are kept in one well known place (they don't spread between several private lists) That's true, but I always imagined that people would be working in the modules anyway, so there isn't much gain. also it is easier to create an exclude list for a target platform, for example, linux.exclude or win.exclude. Yes, that could be. Interesting idea. However, I did imagine that we'd give the modules a bit of freedom and independence for testing - a global exclude list might impact that? I think we won't restrict freedom too much if we ask update only one list. And I believe it won't be updated too often that may cause frequent conflict resolution. Also the global exclude list may be useful to understand impact of a bug, for example, we may organize its entries in the following way: !-- HARMONY-NNN, summary : a bug in luni module -- exclude name=java/lang/SomeTest.java/ exclude name=java/security/SomeTest.java/ exclude name=java/nio/SomeTest.java/ ... exclude name=java/text/SomeTest.java/ !-- HARMONY-ZZZ, summary : a bug in auth module -- exclude name=javax/security/auth/SomeTest.java/ Thanks, Stepan geir Thoughts? Thanks, Stepan Mishura Intel Middleware Products Division -- Thanks, Stepan Mishura Intel Middleware Products Division
Re: [classlib] do we need a global exclude list?
On 2/16/06, Tim Ellison t.p.ellison at gmail.com wrote: Applying a style sheet makes it easy to read the exclusions list in glorious technicolor, either in an individual module or as a combined global view. I see. And global view will be very helpful Thanks, Stepan On 2/16/06, Tim Ellison t.p.ellison at gmail.com wrote: Geir Magnusson Jr wrote: Stepan Mishura wrote: Did anybody think of creating a 'global' (i.e. shared by all modules) exclude list or every module will have its own exclude list? Or Harmony tests will always pass and we don't need it at all :-) That would be the goal :) I see at least the following benefits of creating 'global' exclude list: all know issues are kept in one well known place (they don't spread between several private lists) That's true, but I always imagined that people would be working in the modules anyway, so there isn't much gain. Modules should be as self-sufficient as we can make them, so devolving tests and their exclude lists into a module makes sense to me too. They can be linked into a global view quite easily (read on...) also it is easier to create an exclude list for a target platform, for example, linux.exclude or win.exclude. Yes, that could be. Interesting idea. The mechanism that George contributed in HARMONY-57 uses a decorator to implement an exclusion list on regular JUnit tests. (I happen to know that George is off enjoying himself for the next few days, so I hope he doesn't mind me describing it here.) The exclusion list is implemented as a (declarative) XML file read when the tests run -- in HARMONY-57 you can see one in Harmony_Tests/src/test/resources/config/jcltest-excludes.xml Picking an entry at random from there: ... hy:type id=tests.api.java.io.FileTest hy:exclude id=test_Constructor_String_String_112270 shouldfix=true hy:reasonUndiagnosed failure/hy:reason /hy:exclude hy:exclude id=test_Constructor_File_String_112270 shouldfix=true hy:reasonUndiagnosed failure/hy:reason /hy:exclude hy:exclude id=test_deleteOnExit shouldfix=true hy:reasonNeeds investigation.../hy:reason /hy:exclude /hy:type ... You can see how it works -- some tests are excluded because they fail and should be fixed, others (not shown here) can be excluded because they don't make sense on a particular platform, VM, etc. Applying a style sheet makes it easy to read the exclusions list in glorious technicolor, either in an individual module or as a combined global view. Take a look at the incoming contribution and see if it fits your needs. Regards, Tim However, I did imagine that we'd give the modules a bit of freedom and independence for testing - a global exclude list might impact that? geir Thoughts? Thanks, Stepan Mishura Intel Middleware Products Division -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. -- Thanks, Stepan Mishura Intel Middleware Products Division
[jira] Commented: (HARMONY-80) GSSException has the incorrect serialized form
[ http://issues.apache.org/jira/browse/HARMONY-80?page=comments#action_12366605 ] Stepan Mishura commented on HARMONY-80: --- Ok with the fix. Thanks GSSException has the incorrect serialized form -- Key: HARMONY-80 URL: http://issues.apache.org/jira/browse/HARMONY-80 Project: Harmony Type: Bug Components: Classlib Reporter: Stepan Mishura Assignee: Tim Ellison Priority: Trivial Attachments: fix.txt, fixHarmony80.txt According to Java Spec 5.0 serialVersionUID for org.ietf.jgss.GSSException class is -2706218945227726672L. -- 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
Mission impossible: new APIs without spec in Java 5.0
Dears, There are three protected methods added in java.text.BreakIterator, but I cannot find their specification. What shall we do? protected static long getLong(byte[] buf, int offset) protected static int getInt(byte[] buf, int offset) protected static short getShort(byte[] buf, int offset) -- Richard Liang China Software Development Lab, IBM
[jira] Closed: (HARMONY-80) GSSException has the incorrect serialized form
[ http://issues.apache.org/jira/browse/HARMONY-80?page=all ] Tim Ellison closed HARMONY-80: -- Verified by Stepan GSSException has the incorrect serialized form -- Key: HARMONY-80 URL: http://issues.apache.org/jira/browse/HARMONY-80 Project: Harmony Type: Bug Components: Classlib Reporter: Stepan Mishura Assignee: Tim Ellison Priority: Trivial Attachments: fix.txt, fixHarmony80.txt According to Java Spec 5.0 serialVersionUID for org.ietf.jgss.GSSException class is -2706218945227726672L. -- 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] do we need a global exclude list?
+1 Richard Liang China Software Development Lab, IBM Stepan Mishura wrote: Did anybody think of creating a 'global' (i.e. shared by all modules) exclude list or every module will have its own exclude list? Or Harmony tests will always pass and we don't need it at all :-) I see at least the following benefits of creating 'global' exclude list: all know issues are kept in one well known place (they don't spread between several private lists), also it is easier to create an exclude list for a target platform, for example, linux.exclude or win.exclude. Thoughts? Thanks, Stepan Mishura Intel Middleware Products Division
[jira] Updated: (HARMONY-80) GSSException has the incorrect serialized form
[ http://issues.apache.org/jira/browse/HARMONY-80?page=all ] Tim Ellison updated HARMONY-80: --- Summary: GSSException has the incorrect serialized form (was: serialVersionUID is missed in org.ietf.jgss.GSSException) GSSException has the incorrect serialized form -- Key: HARMONY-80 URL: http://issues.apache.org/jira/browse/HARMONY-80 Project: Harmony Type: Bug Components: Classlib Reporter: Stepan Mishura Priority: Trivial Attachments: fix.txt, fixHarmony80.txt According to Java Spec 5.0 serialVersionUID for org.ietf.jgss.GSSException class is -2706218945227726672L. -- 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
old faithful (was: Re: newbie to project-where to start from)
Geir Magnusson Jr wrote: Tim Ellison wrote: Pick a module [1] that interests you and from there the test code is in module_name/src/test/java/org.apache.harmony.tests.pkg.typeTest.java where pkg and type are the package and type under test; see here [2] for an example. I'm not convinced that we should only use this package convention for tests. One should certainly be able to put a test in the same package as the class being tested... ah that old favourite ;-) I'm sure that I don't need to repeat myself, but, 'oh go on then' - you cannot put code in java.* packages without running them on the bootclasspath. - I am *strongly* opposed to running tests on the bootclasspath - the code is subject to different rules c.f. app classpath - our target apps don't run there so the API tests are bogus - I agree with putting helpers into the bootclasspath to expose implementation classes that are tested (by tests on the app class path) - I would like to see a separation of java API tests and impl tests, so we know which ones we expect to pass on any compliant impl. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
Re: [classlib] do we need a global exclude list?
On 2/16/06, Tim Ellison [EMAIL PROTECTED] wrote: That's true, but I always imagined that people would be working in the modules anyway, so there isn't much gain. Modules should be as self-sufficient as we can make them, so devolving tests and their exclude lists into a module makes sense to me too. As far as tests in one module can fail because of bugs in other modules, I think the modules are not self-sufficient. Thanks, Mikhail
beans tests (was: Re: [jira] Assigned: (HARMONY-88) Contribution of code and unit tests for jndi, logging, prefs and sql plus unit tests only for beans, crypto, math, regex and security)
Richard Liang wrote: Dears, I'm trying to build the new code and run the unit tests, and I find there are lots of test cases fail/error when run the Beans tests with Beans implementation of JIRA#39. java.beans Error 135, Failure 230 (total test cases = 759) java.beans.beancontext Error 68, Failure 31 (total test cases = 245) After a rough investigation, I find there are two major problems in the Beans implementation: 1. Improper class loader used. e.g., Line 113 of java.beans.Beans Class c = Class.forName(beanName, true, cls); This is precisely what I'm talking about on the 'test layout' mail-thread. Running test code on the bootclasspath will pick up the wrong classloader and the test will be incorrectly pass. These APIs MUST be tested by code running on the application classpath. 2. Some methods do not handle null argument Not sure whether I can create JIRA issues. Maybe after the two contribution (39 and 88) are accepted :-) If the contributions are accepted, and the tests merged into the main build, then by your numbers we'll see (135+230+68+31=) 464 testcase failures -- that's a lot of JIRA issues... Regards, Tim Geir Magnusson Jr (JIRA) wrote: [ http://issues.apache.org/jira/browse/HARMONY-88?page=all ] Geir Magnusson Jr reassigned HARMONY-88: Assign To: Geir Magnusson Jr Contribution of code and unit tests for jndi, logging, prefs and sql plus unit tests only for beans, crypto, math, regex and security -- Key: HARMONY-88 URL: http://issues.apache.org/jira/browse/HARMONY-88 Project: Harmony Type: New Feature Components: Contributions Environment: Win32 and Linux Reporter: George Harley Assignee: Geir Magnusson Jr Attachments: Harmony-Contribution.zip Zip file containing implementation and unit test code for the following Harmony components : * jndi * logging * prefs * sql In addition there is unit test code only for the following Harmony components : * beans * crypto * math * regex * security The contents of this zip have been laid out with the current classlib directory structure of the Apache Harmony SVN repository in mind. A version of enhanced/classlib/trunk/make/build-java.xml is included containing new Ant targets to compile the new implementation plus tests code, and then run the tests. Native code, plus makefiles are included to build a shared library that is required to support the prefs implementation on the win.IA32 platform. Not all of the unit test classes are capable of being compiled when the Ant target compile-tests in EXTRACT_DIR/Harmony/make/build-java.xml is run. This is because the current contents of the Harmony trunk do not satisfy all of the dependencies of some classes. This issue affects the unit test code for the following set of components ... * beans (needs beans implementation in trunk) * crypto (needs crypto implementation in trunk) * logging (needs beans implementation in trunk) * jndi (needs applet implementation in trunk) * sql (needs rmi implementation in trunk) As a temporary measure, the lines of Ant script in EXTRACT_DIR/Harmony/make/build-java.xml that compile the above test code have been commented out with explanations. -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
Re: newbie to project-where to start from
karan malhi wrote: Tim, Thanks for such a detailed reply. I have a couple of more questions: 1. Do I have to sign and fax back the questionnaire before I start working on harmony ? You can start working straight away! but before we can accept your contributions into the project we'll need to have a completed questionnaire. If you have not worked on a java implementation before then it should only take a couple of minutes to complete. See the contribution policy here: http://incubator.apache.org/harmony/contribution_policy.html and the questionnaire here: http://incubator.apache.org/harmony/auth_cont_quest.html 2. I know this is dumb but I saw in some previous posts that the tests were being compiled with jrockit. I guess I can use any compiler (sun) without causing any licensing issues - right? Sorry, but I am very poor with this licensing stuff. Just want to make sure I am playing within the rules of the game. You can use whichever compiler you want (ensuring it is 1.4 compliant ;-) ), and then can compare your results against any complaint java implementation (e.g. Sun, BEA, IBM, ...). Tests should be written to the javadoc spec, rather than deducing behavior from any particular implementation. Thanks, Tim Tim Ellison wrote: karan malhi wrote: I need to know how I can start on harmony. I would like to start by writing some tests. That would be great -- thanks Karan! If you have detailed knowledge of another implementation of Java then we need to talk further, otherwise dive right in. Examples of 'detailed knowledge' can be found in the Harmony Questionnaire [0] [0] http://incubator.apache.org/harmony/auth_cont_quest.html Here are my questions : 1. Are there any predefined assertions to test or do we simply write test after looking at the api docs for each method Looking at the spec and writing tests is a pretty good start. There are some tests in the repository already, and some more incoming, but we'll worry about merging new code into the full test suite. 2. Are there any naming conventions for test cases Yes. Pick a module [1] that interests you and from there the test code is in module_name/src/test/java/org.apache.harmony.tests.pkg.typeTest.java where pkg and type are the package and type under test; see here [2] for an example. We are using JUnit, so your test class extends junit.framework.TestCase. Each test method is public void test_methodID() where methodID is the method under test including param types; e.g. [3]. Don't worry too much about the names, we'll fix them on the way in if necessary. [1] http://svn.apache.org/viewcvs.cgi/incubator/harmony/enhanced/classlib/trunk/modules/ [2] http://svn.apache.org/viewcvs.cgi/incubator/harmony/enhanced/classlib/trunk/modules/luni/src/test/java/org/apache/harmony/tests/java/net/ [3] http://svn.apache.org/viewcvs.cgi/incubator/harmony/enhanced/classlib/trunk/modules/luni/src/test/java/org/apache/harmony/tests/java/net/InetAddressTest.java?view=markup 3. When one files a JIRA for a failed test, does one also attach the test to the JIRA Yes please, a succinct description with a unit test is great, and if you have a proposed patch that would be even better ;-) We have had lots of good examples of bug reports, here's one I picked at random to show the type of thing we like to see: https://issues.apache.org/jira/browse/HARMONY-53 Thanks again for your offer of help. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
Re: newbie to project-where to start from
2006/2/16, Tim Ellison [EMAIL PROTECTED]: Tests should be written to the javadoc spec, rather than deducing behavior from any particular implementation. By the way... Do we want to be bug compatible with reference implementation? -- Alexey A. Petrenko Intel Middleware Products Division
Re: Mission impossible: new APIs without spec in Java 5.0
Hmm, they look to me like they could be impl methods that were inadvertently exposed. They don't seem to fit in to the BreakIterator bag. If I were you I'd implement them to throw a NotYetImplementedException. Regards, Tim Anton Avtamonov wrote: Hi, What is wrong if you prepare unit tests and investigate how it works? I think that is valid approach for such cases. Am I wrong? -- Anton Avtamonov, Intel Middleware Products Division On 2/16/06, Richard Liang [EMAIL PROTECTED] wrote: Dears, There are three protected methods added in java.text.BreakIterator, but I cannot find their specification. What shall we do? protected static long getLong(byte[] buf, int offset) protected static int getInt(byte[] buf, int offset) protected static short getShort(byte[] buf, int offset) -- Richard Liang China Software Development Lab, IBM -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
[jira] Updated: (HARMONY-98) java.util.BitSet.clear(int toIndex,int fromIndex) throws unexpected IndexOutOfBoundsException when toIndex=fromIndex
[ http://issues.apache.org/jira/browse/HARMONY-98?page=all ]
Svetlana Samoilenko updated HARMONY-98:
---
Attachment: fix.txt
java.util.BitSet.clear(int toIndex,int fromIndex) throws unexpected
IndexOutOfBoundsException when toIndex=fromIndex
Key: HARMONY-98
URL: http://issues.apache.org/jira/browse/HARMONY-98
Project: Harmony
Type: Bug
Components: Classlib
Reporter: Svetlana Samoilenko
Attachments: fix.txt
According to 1.4.2 and 1.5 specification java.util.BitSet.clear(int,int)
throws IndexOutOfBoundsException - if fromIndex is negative, or toIndex is
negative, or fromIndex is larger than toIndex.
Harmony throws IndexOutOfBoundsException if toIndex=fromIndex.
Code to reproduce:
import java.util.BitSet;
public class test2 {
public static void main(String[] args) {
BitSet set = new BitSet();
for(int i=0; i 20; i++) {
set.set(i);
}
set.clear(10,10);
}
}
Steps to Reproduce:
1. Build Harmony (check-out on 2006-01-30) j2se subset as described in
README.txt.
2. Compile test2.java using BEA 1.4 javac
javac -d . test2.java
3. Run java using compatible VM (J9)
java -showversion test2
Output:
C:\tmpC:\jrockit-j2sdk1.4.2_04\bin\java.exe -showversion test2
java version 1.4.2_04
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_04-b05)
BEA WebLogic JRockit(TM) 1.4.2_04 JVM (build
ari-31788-20040616-1132-win-ia32, Native Threads, GC strategy: parallel)
PASSED
C:\tmpC:\harmony\trunk\deploy\jre\bin\java -showversion test2
(c) Copyright 1991, 2005 The Apache Software Foundation or its licensors, as
applicable.
java.lang.IndexOutOfBoundsException: Negative index specified
at java.util.BitSet.clear(BitSet.java:423)
at test2.main(test2.java:16)
Suggested fix in attachment.
Suggested junit test case:
BitSetTest.java
-
import junit.framework.*;
import java.util.BitSet;
public class BitSetTest extends TestCase {
public static void main(String[] args) {
junit.textui.TestRunner.run(BitSetTest.class);
}
public void test_clear() {
BitSet set = new BitSet();
for(int i=0; i 20; i++) {
set.set(i);
}
set.clear(10,10);
}
}
--
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-97) ZipOutputStream.close() throws IOException if the stream is already closed
[ http://issues.apache.org/jira/browse/HARMONY-97?page=all ]
Tim Ellison reassigned HARMONY-97:
--
Assign To: Tim Ellison
ZipOutputStream.close() throws IOException if the stream is already closed
--
Key: HARMONY-97
URL: http://issues.apache.org/jira/browse/HARMONY-97
Project: Harmony
Type: Bug
Components: Classlib
Reporter: Svetlana Samoilenko
Assignee: Tim Ellison
According to 1.5 specification for ?lose() method in interface Closeable:
Closes this stream and releases any system resources associated with it.
If the stream is already closed then invoking this method has no effect.
Harmony throws IOException if the stream is already closed.
Code to reproduce:
import java.io.*;
import java.util.zip.*;
public class test2 {
public static void main(String args[]) {
ZipOutputStream zos = null;
try {
File f=new File(myFile);
f.createNewFile();
f.deleteOnExit();
FileOutputStream ff=new FileOutputStream(f);
BufferedOutputStream b=new BufferedOutputStream(ff);
zos=new ZipOutputStream(new BufferedOutputStream(b));
zos.putNextEntry(new ZipEntry(myFile));
} catch (IOException ee) {
ee.printStackTrace();
}
try {
zos.close();
zos.close();
System.out.println(PASSED);
} catch (IOException ee) {
System.out.println(FAILED);
ee.printStackTrace();
}
}
}
Steps to Reproduce:
1. Build Harmony (check-out on 2006-01-30) j2se subset as described in
README.txt.
2. Compile test2.java using BEA 1.4 javac
javac -d . test2.java
3. Run java using compatible VM (J9)
java -showversion test2
Output:
C:\tmpC:\jrockit-j2sdk1.4.2_04\bin\java.exe -showversion test2
java version 1.4.2_04
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_04-b05)
BEA WebLogic JRockit(TM) 1.4.2_04 JVM (build
ari-31788-20040616-1132-win-ia32, Native Threads, GC strategy: parallel)
PASSED
C:\tmpC:\harmony\trunk\deploy\jre\bin\java -showversion test2
(c) Copyright 1991, 2005 The Apache Software Foundation or its licensors, as
applicable.
FAILED
java.io.IOException: Stream is closed
at java.util.zip.ZipOutputStream.finish(ZipOutputStream.java:157)
at java.util.zip.ZipOutputStream.close(ZipOutputStream.java:66)
at test2.main(test2.java:26)
Suggested fix:
Index: trunk/modules/archive/src/main/java/java/util/zip/ZipOutputStream.java
===
--- trunk/modules/archive/src/main/java/java/util/zip/ZipOutputStream.java
(revision 378195)
+++ trunk/modules/archive/src/main/java/java/util/zip/ZipOutputStream.java
(working copy)
@@ -77,8 +77,7 @@
*/
public void close() throws IOException {
finish();
- out.close();
- out = null;
+ out.close();
}
/**
@@ -165,9 +164,7 @@
* @exception IOException
*If an error occurs while finishing
*/
- public void finish() throws IOException {
- if (out == null)
- throw new
IOException(Msg.getString(K0059));
+ public void finish() throws IOException {
if (cDir == null)
return;
if (entries.size() == 0)
Suggested junit test case:
ZipOutputStreamTest.java
-
import junit.framework.*;
import java.util.zip.*;
import java.io.*;
public class ZipOutputStreamTest extends TestCase {
public static void main(String[] args) {
junit.textui.TestRunner.run(ZipOutputStream.class);
}
public void test_close() {
ZipOutputStream zos = null;
try {
File f=new File(myFile);
f.createNewFile();
f.deleteOnExit();
FileOutputStream ff=new FileOutputStream(f);
BufferedOutputStream b=new BufferedOutputStream(ff);
zos=new ZipOutputStream(new BufferedOutputStream(b));
zos.putNextEntry(new ZipEntry(myFile));
} catch (IOException ee) {
fail(Unnexpected IOException);
}
try {
zos.close();
zos.close();
} catch (IOException ee) {
fail(Unnexpected IOException);
[jira] Commented: (HARMONY-71) java.net.URLConnection.setUseCaches throws unspecified IllegalAccessError
[
http://issues.apache.org/jira/browse/HARMONY-71?page=comments#action_12366637 ]
Stepan Mishura commented on HARMONY-71:
---
Tim,
Added test case (test_setUseCachesZ) depends on network and it fails if it can
not create connection with apache.org. The same for HARMONY-72. I'm going to
attach a patch file with a local server in it. Could you reopen this JIRA?
Thanks,
Stepan.
java.net.URLConnection.setUseCaches throws unspecified IllegalAccessError
--
Key: HARMONY-71
URL: http://issues.apache.org/jira/browse/HARMONY-71
Project: Harmony
Type: Bug
Components: Classlib
Reporter: Svetlana Samoilenko
Assignee: Tim Ellison
According to j2se 1.4.2 specification method
java.net.URLConnection.setUseCaches(boolean) throws IllegalStateException, if
already connected. Harmony throws java.lang.IllegalAccessError instead, that
contradicts the specification.
Code to reproduce:
import java.io.IOException;
import java.net.*;
public class test2 {
public static void main(String[] args) {
HttpURLConnection u=null;
try {
u=(HttpURLConnection)(new
URL(http://intel.com;).openConnection());
u.connect();
} catch (MalformedURLException e) {
System.out.println(unexpected MalformedURLException+e);
} catch (IOException f) {
System.out.println(unexpected IOException+f);
}
try {
u.setUseCaches(true);
} catch (IllegalStateException e) {
System.out.println(OK. Expected IllegalStateException);
e.printStackTrace();
};
}
}
Steps to Reproduce:
1. Build Harmony (check-out on 2006-01-30) j2se subset as described in
README.txt.
2. Compile test2.java using BEA 1.4 javac
javac -d . test2.java
3. Run java using compatible VM (J9)
java -showversion test2
Output:
C:\tmpC:\jrockit-j2sdk1.4.2_04\bin\java.exe -showversion test2
java version 1.4.2_04
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_04-b05)
BEA WebLogic JRockit(TM) 1.4.2_04 JVM (build
ari-31788-20040616-1132-win-ia32, Native Threads, GC strategy: parallel)
OK. Expected IllegalStateException
java.lang.IllegalStateException: Already connected
at java.net.URLConnection.setUseCaches(Z)V(URLConnection.java:828)
at test2.main([Ljava.lang.String;)V(test2.java:17)
C:\tmpC:\harmony\trunk\deploy\jre\bin\java -showversion test2
(c) Copyright 1991, 2005 The Apache Software Foundation or its licensors, as
applicable.
java.lang.IllegalAccessError: Connection already established
at java.net.URLConnection.setUseCaches(URLConnection.java:923)
at test2.main(test2.java:17)
Suggested junit test case:
URLConnectionTest.java
-
import java.io.IOException;
import java.net.*;
import junit.framework.*;
public class URLConnectionTest extends TestCase {
public static void main(String[] args) {
junit.textui.TestRunner.run(URLConnectionTest.class);
}
public void test_setUseCaches () {
HttpURLConnection u=null;
try {
u=(HttpURLConnection)(new
URL(http://intel.com;).openConnection());
u.connect();
} catch (MalformedURLException e) {
fail(unexpected MalformedURLException+e);
} catch (IOException f) {
fail(unexpected IOException+f);
}
try {
u.setUseCaches(true);
} catch (IllegalStateException e) { //expected
};
}
}
--
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-98) java.util.BitSet.clear(int toIndex,int fromIndex) throws unexpected IndexOutOfBoundsException when toIndex=fromIndex
[
http://issues.apache.org/jira/browse/HARMONY-98?page=comments#action_12366640 ]
Tim Ellison commented on HARMONY-98:
looks like the wrong patch was attached -- this patch is == HARMONY-93
java.util.BitSet.clear(int toIndex,int fromIndex) throws unexpected
IndexOutOfBoundsException when toIndex=fromIndex
Key: HARMONY-98
URL: http://issues.apache.org/jira/browse/HARMONY-98
Project: Harmony
Type: Bug
Components: Classlib
Reporter: Svetlana Samoilenko
Attachments: fix.txt
According to 1.4.2 and 1.5 specification java.util.BitSet.clear(int,int)
throws IndexOutOfBoundsException - if fromIndex is negative, or toIndex is
negative, or fromIndex is larger than toIndex.
Harmony throws IndexOutOfBoundsException if toIndex=fromIndex.
Code to reproduce:
import java.util.BitSet;
public class test2 {
public static void main(String[] args) {
BitSet set = new BitSet();
for(int i=0; i 20; i++) {
set.set(i);
}
set.clear(10,10);
}
}
Steps to Reproduce:
1. Build Harmony (check-out on 2006-01-30) j2se subset as described in
README.txt.
2. Compile test2.java using BEA 1.4 javac
javac -d . test2.java
3. Run java using compatible VM (J9)
java -showversion test2
Output:
C:\tmpC:\jrockit-j2sdk1.4.2_04\bin\java.exe -showversion test2
java version 1.4.2_04
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_04-b05)
BEA WebLogic JRockit(TM) 1.4.2_04 JVM (build
ari-31788-20040616-1132-win-ia32, Native Threads, GC strategy: parallel)
PASSED
C:\tmpC:\harmony\trunk\deploy\jre\bin\java -showversion test2
(c) Copyright 1991, 2005 The Apache Software Foundation or its licensors, as
applicable.
java.lang.IndexOutOfBoundsException: Negative index specified
at java.util.BitSet.clear(BitSet.java:423)
at test2.main(test2.java:16)
Suggested fix in attachment.
Suggested junit test case:
BitSetTest.java
-
import junit.framework.*;
import java.util.BitSet;
public class BitSetTest extends TestCase {
public static void main(String[] args) {
junit.textui.TestRunner.run(BitSetTest.class);
}
public void test_clear() {
BitSet set = new BitSet();
for(int i=0; i 20; i++) {
set.set(i);
}
set.clear(10,10);
}
}
--
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: [jira] Commented: (HARMONY-71) java.net.URLConnection.setUseCaches throws unspecified IllegalAccessError
I would rather that you just opened a new JIRA issue for that as it
doesn't relate to the original problem.
FYI there is a local server incoming in the HARMONY-57 contribution, so
don't spend any time on it, see:
HARMONY-57\Harmony\Harmony_Tests\src\test\java\tests\support\Support_HttpServer.java
Regards,
Tim
Stepan Mishura (JIRA) wrote:
[
http://issues.apache.org/jira/browse/HARMONY-71?page=comments#action_12366637
]
Stepan Mishura commented on HARMONY-71:
---
Tim,
Added test case (test_setUseCachesZ) depends on network and it fails if it
can not create connection with apache.org. The same for HARMONY-72. I'm going
to attach a patch file with a local server in it. Could you reopen this JIRA?
Thanks,
Stepan.
java.net.URLConnection.setUseCaches throws unspecified IllegalAccessError
--
Key: HARMONY-71
URL: http://issues.apache.org/jira/browse/HARMONY-71
Project: Harmony
Type: Bug
Components: Classlib
Reporter: Svetlana Samoilenko
Assignee: Tim Ellison
According to j2se 1.4.2 specification method
java.net.URLConnection.setUseCaches(boolean) throws IllegalStateException,
if already connected. Harmony throws java.lang.IllegalAccessError instead,
that contradicts the specification.
Code to reproduce:
import java.io.IOException;
import java.net.*;
public class test2 {
public static void main(String[] args) {
HttpURLConnection u=null;
try {
u=(HttpURLConnection)(new
URL(http://intel.com;).openConnection());
u.connect();
} catch (MalformedURLException e) {
System.out.println(unexpected MalformedURLException+e);
} catch (IOException f) {
System.out.println(unexpected IOException+f);
}
try {
u.setUseCaches(true);
} catch (IllegalStateException e) {
System.out.println(OK. Expected IllegalStateException);
e.printStackTrace();
};
}
}
Steps to Reproduce:
1. Build Harmony (check-out on 2006-01-30) j2se subset as described in
README.txt.
2. Compile test2.java using BEA 1.4 javac
javac -d . test2.java
3. Run java using compatible VM (J9)
java -showversion test2
Output:
C:\tmpC:\jrockit-j2sdk1.4.2_04\bin\java.exe -showversion test2
java version 1.4.2_04
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_04-b05)
BEA WebLogic JRockit(TM) 1.4.2_04 JVM (build
ari-31788-20040616-1132-win-ia32, Native Threads, GC strategy: parallel)
OK. Expected IllegalStateException
java.lang.IllegalStateException: Already connected
at java.net.URLConnection.setUseCaches(Z)V(URLConnection.java:828)
at test2.main([Ljava.lang.String;)V(test2.java:17)
C:\tmpC:\harmony\trunk\deploy\jre\bin\java -showversion test2
(c) Copyright 1991, 2005 The Apache Software Foundation or its licensors, as
applicable.
java.lang.IllegalAccessError: Connection already established
at java.net.URLConnection.setUseCaches(URLConnection.java:923)
at test2.main(test2.java:17)
Suggested junit test case:
URLConnectionTest.java
-
import java.io.IOException;
import java.net.*;
import junit.framework.*;
public class URLConnectionTest extends TestCase {
public static void main(String[] args) {
junit.textui.TestRunner.run(URLConnectionTest.class);
}
public void test_setUseCaches () {
HttpURLConnection u=null;
try {
u=(HttpURLConnection)(new
URL(http://intel.com;).openConnection());
u.connect();
} catch (MalformedURLException e) {
fail(unexpected MalformedURLException+e);
} catch (IOException f) {
fail(unexpected IOException+f);
}
try {
u.setUseCaches(true);
} catch (IllegalStateException e) { //expected
};
}
}
--
Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.
Re: [classlib] proposal to revisit componentization for security (was: Re: problems with security2)
/me points at stuff worth saving... On Wed, Feb 15, 2006 at 10:23:53AM +, Tim Ellison wrote: thoughts on modularity among other things
Re: I welcome J2SE 6's faster-splash.... re: Java speed-up
Fernando Cassia wrote: On 2/16/06, Stefano Mazzocchi [EMAIL PROTECTED] wrote: which implements a very interesting trick to speed up java startup performance: save the hotspot information in a repository (at JVM shut down) so that the JIT doesn't have to wait when it starts until it knows what is a hotspot to start compiling it. the performance improvements are not likely to change the perception that java is awefully slow to start up on the desktop, but it's a clever idea. In the meanwhile, Sun's attempt to solve the same problem in JSE6 is this= : http://java.sun.com/developer/JDCTechTips/2005/tt1115.html#1 No comment. You try to sound clever by making that statement, but imho, despite any other speed-up work who might be implemented, Sun's solution is very important, and something that should have been implemented a long, long time ago. I welcome their implementation, even if late. Get this: Splash screens sever an important purpose: they're a visual cue to tell the user that the program is loading (even if it takes a long time). It's all about PERCEPTION. Java aps are PERCEIVED as slower because the computer appears to freeze until the program's UI is finally showed on the screen (after ALL classes -and even more if it uses Swing- needed to run are loaded- By then, the user is no longer interested in seeing a splash screen, he's already wondering why it took so long See, most Flash content on the web takes an AWFUL LOT of time to download, yet if you ask users, they'll tell you that Flash loads faster than java. The difference? Flash applets can show a message RIGHT AWAY and often display a progress dialog as the rest of the flash cr*p is downloading, telling the user what is going on. In contrast, java applets (and desktop applications as well) freeze the user experience until the applet (or desktop app) has loaded. My point was that it is *trivial* to patch the C code that implements the java JVM loader to add something like that. On an apple computer, since practically 5 years ago, you can double click on a jar file and the icon will start bouncing right away on your dock. My point is: I don't think this is silly, it's a very useful feature, but it's *lame* that it took them almost 10 years to realize they needed it! But look at the bright side: there are probably many other really simple yet useful things that can be done to make java more useful on the desktop and this will be a marketing win for alternative JVMs. We need to find the tab-browsing-equivalent of a JVM ;-) -- Stefano.
Re: Mission impossible: new APIs without spec in Java 5.0
Richard Liang wrote: Dears, There are three protected methods added in java.text.BreakIterator, but I cannot find their specification. What shall we do? protected static long getLong(byte[] buf, int offset) protected static int getInt(byte[] buf, int offset) protected static short getShort(byte[] buf, int offset) Guess :-) -- Stefano.
Re: [classlib] do we need a global exclude list?
Could there be a switch to over-ride the global exclude list entry/entries? This way a module by default would use a global exclude list and also have the freedom to ignore it and use the module exclude list. Geir Magnusson Jr wrote: However, I did imagine that we'd give the modules a bit of freedom and independence for testing - a global exclude list might impact that? Stepan Mishura wrote: Did anybody think of creating a 'global' (i.e. shared by all modules) exclude list or every module will have its own exclude list? Or Harmony tests will always pass and we don't need it at all :-) That would be the goal :) I see at least the following benefits of creating 'global' exclude list: all know issues are kept in one well known place (they don't spread between several private lists) That's true, but I always imagined that people would be working in the modules anyway, so there isn't much gain. also it is easier to create an exclude list for a target platform, for example, linux.exclude or win.exclude. Yes, that could be. Interesting idea. However, I did imagine that we'd give the modules a bit of freedom and independence for testing - a global exclude list might impact that? geir Thoughts? Thanks, Stepan Mishura Intel Middleware Products Division -- Karan Singh
Re: newbie to project-where to start from
Geir Magnusson Jr geir at pobox.com writes: I think we should certainly be using Muave for testing. However, that doesn't remove the need for our own unit tests to be testing implementation internals. Completely agree. Tests of implementation internals don't belong in Mauve of course. I guess the question is whether, when a Harmony contributor wants to write a test for documented, public, specified API functionality, should that test go in Mauve instead of Harmony's own test framework? Obviously I'd argue that it should, as then it benefits all implementations, not just Harmony. Plus if Harmony contributors are running Mauve regularly, they're getting the benefits of Mauve tests contributed by developers of other implementations too. (I've watched people go down this road before: I was following several projects with independent class library implementations years before there was any prospect of them merging into Classpath as they've now done. Even when there was no cooperation on the library code, everybody seemed to agree it was in their best interests to collaborate on the test suite...) If it *is* recommended for Harmony contributors to put such tests into Mauve, that recommendation probably ought to be mentioned in answer to questions like the one that I replied to; the original poster didn't say whether their tests were going to be of implementation internals or not... Would you like to help us get it working in our build/test framework? I'm afraid you're asking the wrong person: I can't get Mauve working at all... Stuart.
Re: old faithful
Tim Ellison wrote: Geir Magnusson Jr wrote: Tim Ellison wrote: Pick a module [1] that interests you and from there the test code is in module_name/src/test/java/org.apache.harmony.tests.pkg.typeTest.java where pkg and type are the package and type under test; see here [2] for an example. I'm not convinced that we should only use this package convention for tests. One should certainly be able to put a test in the same package as the class being tested... ah that old favourite ;-) We never resolved it. I'm sure that I don't need to repeat myself, but, 'oh go on then' - you cannot put code in java.* packages without running them on the bootclasspath. - I am *strongly* opposed to running tests on the bootclasspath - the code is subject to different rules c.f. app classpath - our target apps don't run there so the API tests are bogus I support this argument for code that tests the API as a client would - i.e. as app code uses the API. As for testing internals of java.foo. - I agree with putting helpers into the bootclasspath to expose implementation classes that are tested (by tests on the app class path) - I would like to see a separation of java API tests and impl tests, so we know which ones we expect to pass on any compliant impl. Yes - I agree with the last bit. So how do we move forward? Is it worth investigating some kind of test harness that gives us the control we need for security and classloader issues so we can split of tests that want to be java.foo and those that are o.a.h.x.test geir geir
Re: newbie to project-where to start from
Alexey Petrenko wrote: 2006/2/16, Tim Ellison [EMAIL PROTECTED]: Tests should be written to the javadoc spec, rather than deducing behavior from any particular implementation. By the way... Do we want to be bug compatible with reference implementation? I actually think so for now :)
Re: [classlib] do we need a global exclude list?
Geir Magnusson Jr wrote: Tim Ellison wrote: The exclusion list is implemented as a (declarative) XML file read when the tests run -- in HARMONY-57 you can see one in Harmony_Tests/src/test/resources/config/jcltest-excludes.xml Picking an entry at random from there: ... hy:type id=tests.api.java.io.FileTest hy:exclude id=test_Constructor_String_String_112270 shouldfix=true hy:reasonUndiagnosed failure/hy:reason /hy:exclude hy:exclude id=test_Constructor_File_String_112270 shouldfix=true hy:reasonUndiagnosed failure/hy:reason /hy:exclude hy:exclude id=test_deleteOnExit shouldfix=true hy:reasonNeeds investigation.../hy:reason /hy:exclude /hy:type ... You can see how it works -- some tests are excluded because they fail and should be fixed, others (not shown here) can be excluded because they don't make sense on a particular platform, VM, etc. Applying a style sheet makes it easy to read the exclusions list in glorious technicolor, either in an individual module or as a combined global view. That's cute. And if these were local to each module, in a well-known place, we still could present a global picture with a top level thingy that generates a list... Yep, probably putting the exclusion list into src/test/resources in each module, and like you say, easy to combine. We could also add a platform element to make exclusions platform specific... Already there ;-) xsd:element name=exclude xsd:complexType xsd:sequence xsd:element ref=reason minOccurs=0 maxOccurs=1/ /xsd:sequence xsd:attribute name=id type=idtype default=all / xsd:attribute name=platform type=platformlisttype default=all / xsd:attribute name=shouldfix type=booleanstringtype default=true / /xsd:complexType /xsd:element where xsd:simpleType name=platformstringtype xsd:restriction base=xsd:string xsd:enumeration value=win.IA32/ xsd:enumeration value=linux.IA32/ xsd:enumeration value=all/ /xsd:restriction /xsd:simpleType but of course we can do whatever we want. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
Re: [classlib] do we need a global exclude list?
karan malhi wrote: Could there be a switch to over-ride the global exclude list entry/entries? This way a module by default would use a global exclude list and also have the freedom to ignore it and use the module exclude list. I don't know what having two exclude lists would mean - a test should be excluded for a specific reason, and therefore I can't see why one would be in the global list, but not in the module list (and vice versa...) geir Geir Magnusson Jr wrote: However, I did imagine that we'd give the modules a bit of freedom and independence for testing - a global exclude list might impact that? Stepan Mishura wrote: Did anybody think of creating a 'global' (i.e. shared by all modules) exclude list or every module will have its own exclude list? Or Harmony tests will always pass and we don't need it at all :-) That would be the goal :) I see at least the following benefits of creating 'global' exclude list: all know issues are kept in one well known place (they don't spread between several private lists) That's true, but I always imagined that people would be working in the modules anyway, so there isn't much gain. also it is easier to create an exclude list for a target platform, for example, linux.exclude or win.exclude. Yes, that could be. Interesting idea. However, I did imagine that we'd give the modules a bit of freedom and independence for testing - a global exclude list might impact that? geir Thoughts? Thanks, Stepan Mishura Intel Middleware Products Division
Re: [classlib] do we need a global exclude list?
karan malhi wrote: Could there be a switch to over-ride the global exclude list entry/entries? This way a module by default would use a global exclude list and also have the freedom to ignore it and use the module exclude list. In the incoming HARMONY-57 contribution the list is 'global', but you can override the exclusion list by specifying a replacement's location in a java property. In future, I see the global list as simply a dynamic amalgam of the module lists in the target. If we put the exclude lists in a standard location, (in the repo and in the tests jar file(s)) then they can be found by the test framework. Regards, Tim Geir Magnusson Jr wrote: However, I did imagine that we'd give the modules a bit of freedom and independence for testing - a global exclude list might impact that? Stepan Mishura wrote: Did anybody think of creating a 'global' (i.e. shared by all modules) exclude list or every module will have its own exclude list? Or Harmony tests will always pass and we don't need it at all :-) That would be the goal :) I see at least the following benefits of creating 'global' exclude list: all know issues are kept in one well known place (they don't spread between several private lists) That's true, but I always imagined that people would be working in the modules anyway, so there isn't much gain. also it is easier to create an exclude list for a target platform, for example, linux.exclude or win.exclude. Yes, that could be. Interesting idea. However, I did imagine that we'd give the modules a bit of freedom and independence for testing - a global exclude list might impact that? geir Thoughts? Thanks, Stepan Mishura Intel Middleware Products Division -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
Re: newbie to project-where to start from
Stuart Ballard wrote: Geir Magnusson Jr geir at pobox.com writes: I think we should certainly be using Muave for testing. However, that doesn't remove the need for our own unit tests to be testing implementation internals. Completely agree. Tests of implementation internals don't belong in Mauve of course. Agreed. I guess the question is whether, when a Harmony contributor wants to write a test for documented, public, specified API functionality, should that test go in Mauve instead of Harmony's own test framework? If the person is a Harmony contributor the test would go into Harmony wouldn't it? If they were a Mauve contributor it would go into Mauve? Of course these are not exclusive options. Obviously I'd argue that it should, as then it benefits all implementations, not just Harmony. How so? what is stopping all implementations running Harmony's Java API tests? Plus if Harmony contributors are running Mauve regularly, they're getting the benefits of Mauve tests contributed by developers of other implementations too. Agreed, and that is a good thing. Since Mauve is under GPLv2 the tests won't end up in our repository tho' and the consequences of combining the tests into a single work have already been discussed. (I've watched people go down this road before: I was following several projects with independent class library implementations years before there was any prospect of them merging into Classpath as they've now done. Even when there was no cooperation on the library code, everybody seemed to agree it was in their best interests to collaborate on the test suite...) Cool, we accept contributions from everyone who is eligible under the ACQ rules ;-) If it *is* recommended for Harmony contributors to put such tests into Mauve, that recommendation probably ought to be mentioned in answer to questions like the one that I replied to; the original poster didn't say whether their tests were going to be of implementation internals or not... There are a number of places that people can contribute. If people want their work to be GPLv2 compatible then Mauve is a good choice, if people want their work to be ASL compatible then Harmony is a good choice. I'm not going to suggest where people should contribute their efforts -- in the end it all benefits the open software ecosystem. Would you like to help us get it working in our build/test framework? I'm afraid you're asking the wrong person: I can't get Mauve working at all... (let's not get into a license discussion again) Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
Re: newbie to project-where to start from
Is mauve modular? I mean, suppose people were writing test cases that could be bundled together and plugged in. So if people were writing tests here in Harmony and (for whatever reason) didn't contribute to Mauve, we still could publish and distribute a Mauve Test Bundle that people could pick up and use... geir Tim Ellison wrote: Stuart Ballard wrote: Geir Magnusson Jr geir at pobox.com writes: I think we should certainly be using Muave for testing. However, that doesn't remove the need for our own unit tests to be testing implementation internals. Completely agree. Tests of implementation internals don't belong in Mauve of course. Agreed. I guess the question is whether, when a Harmony contributor wants to write a test for documented, public, specified API functionality, should that test go in Mauve instead of Harmony's own test framework? If the person is a Harmony contributor the test would go into Harmony wouldn't it? If they were a Mauve contributor it would go into Mauve? Of course these are not exclusive options. Obviously I'd argue that it should, as then it benefits all implementations, not just Harmony. How so? what is stopping all implementations running Harmony's Java API tests? Plus if Harmony contributors are running Mauve regularly, they're getting the benefits of Mauve tests contributed by developers of other implementations too. Agreed, and that is a good thing. Since Mauve is under GPLv2 the tests won't end up in our repository tho' and the consequences of combining the tests into a single work have already been discussed. (I've watched people go down this road before: I was following several projects with independent class library implementations years before there was any prospect of them merging into Classpath as they've now done. Even when there was no cooperation on the library code, everybody seemed to agree it was in their best interests to collaborate on the test suite...) Cool, we accept contributions from everyone who is eligible under the ACQ rules ;-) If it *is* recommended for Harmony contributors to put such tests into Mauve, that recommendation probably ought to be mentioned in answer to questions like the one that I replied to; the original poster didn't say whether their tests were going to be of implementation internals or not... There are a number of places that people can contribute. If people want their work to be GPLv2 compatible then Mauve is a good choice, if people want their work to be ASL compatible then Harmony is a good choice. I'm not going to suggest where people should contribute their efforts -- in the end it all benefits the open software ecosystem. Would you like to help us get it working in our build/test framework? I'm afraid you're asking the wrong person: I can't get Mauve working at all... (let's not get into a license discussion again) Regards, Tim
Re: I welcome J2SE 6's faster-splash.... re: Java speed-up
On 2/16/06, Stefano Mazzocchi [EMAIL PROTECTED] wrote: We need to find the tab-browsing-equivalent of a JVM ;-) It's simple, Google should make one of their apps a cross-platform, Swing based java one. Google, unlike Sun, will then have the marketing power to convince vendors to preload a java VM on their systems. Issue solved. Microsoft can get away with the huge bloated .Net runtime just because they ship it with newer Windows versions. Otherwise nobody would donwload it I'm still scratching my bald head thinking why hasn't Google embraced desktop java yet. Google Talk would be a killer app written in Swing / 100% Pure Java. H*ck, there's even a pure-java mpeg4 implementation Open source streaming media in Java™ MediaFrame is an Open Source http://mediaframe.org/#opensource streaming media platform in Java™ which provides a fast, easy to implement and extremely small applet that enables over 97% (AdShadowhttp://adshadow.com/2002-03) of web users to view your audio/video content without having to rely on external player applications or bulky plug-ins. MediaFrame does not require special servers, software or programming knowledge (feature list http://mediaframe.org/#features). MediaFrame is based on open standards and is compatible with Mpeg (Mpeg-1 Mpeg-4), the industry standard in video compression. This enables users to create MediaFrame ready content in any number of applications, from Adobe AfterEffects to Media Cleaner. MediaFrame is feature complete for Mpeg-1 and in Beta release for Mpeg-4. Both the Mpeg-1 Mpeg-4 versions of MediaFrame are availble for download now, along with source code, documentation and sample video.. MediaFrame is* dual license software*. Under this model, users may choose to use MediaFrame under the free software/open source GNU General Public License (commonly known as the GPL) or under a commercial license. Google Plans to add video to Google Talk http://australianit.news.com.au/articles/0,7204,16554205%5E24170%5E%5Enbv%5E24169,00.html Btw: Pretty impressive things can be done with JDIC, things that make Java desktop apps look and feel like native code: minimize to windows systray (o Gnome panel on Linux), call the system's default web browser, and more. See: https://jdic.dev.java.net/ One killer example of today=B4s desktop java technology is Azureus, the bittorrent client (http://azureus.sourceforge.net). Just my $0.02 FC -- Hay dos caminos claros para mí: la creatividad o el ridículo Adolfo Castelo (1940-2004)
Re: compiling JCHEVM with GCC/Cygwin
Hi, Enrico. Thank you for your help. Looks like I am following you step by step and now have the same error which you discussed with Archie few days ago =) 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 But unfortunately this mail-list do not contain solution for it. I can not figure out how to solve it. Can you help me, please? Ivan
Re: compiling JCHEVM with GCC/Cygwin
snowdosker wrote: vm.c - line 46 message = assertion failure: _JC_FULL_ALIGNMENT = (sizeof(_jc_word)) This assertion is there because we align the start of an object with the first reference (which is in front of the object header). The fix for this is to modify the code to align non-array objects on 8 byte boundaries even if they have an odd number of reference words (yuck). This requires changing the algorithm for determining object size and heap block size, as well as skip word handling, etc. (blah blah gnarly internals). However, I'm curious why double alignment is 8 under Cygwin but only 4 under Linux but both are x86. Obviously that can't derive only from the hardware. So for now I'd say just comment out that assertion and proceed. If you get funny floating point results then we'll know why :-) -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: compiling JCHEVM with GCC/Cygwin
snowdosker wrote: Hi, Enrico. Thank you for your help. Looks like I am following you step by step and now have the same error which you discussed with Archie few days ago =) 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 But unfortunately this mail-list do not contain solution for it. I can not figure out how to solve it. Can you help me, please? Ivan Hi Ivan, try this, in the autogen.sh file: CONFIGFLAGS= --disable-assertions After disabling the assertions, you should be face the same problem where I'm currently stuck at: http://cygwin.com/ml/cygwin/2006-02/msg00570.html That problem, I think, should disappear on a WindowsXP Professional Edition. Let me know how it goes. Enrico
Re: compiling JCHEVM with GCC/Cygwin
Thank you Enrico and Archie. So now with assertions disabled I faced next problem, Enrico mentioned in his email. The same failed to open native library /usr/local/classpath/lib/classpath/libjavanio.dll.a: permission denied I'm trying to run it under XP professional so I had no problem to set exec flags in permissions but this do not help. Still the same problem. Please, let me know if you will find solution. Thanks, Ivan
Re: I welcome J2SE 6's faster-splash.... re: Java speed-up
Fernando Cassia wrote: I'm still scratching my bald head thinking why hasn't Google embraced desktop java yet. Google Talk would be a killer app written in Swing / 100% Pure Java. It's never stupid to stay realistic. There is no JavaSound implementation giving you enough control of e.g. the sound card latency to allow a usable telephone application to be implemented. H*ck, there's even a pure-java mpeg4 implementation Which doesn't work for me. A few still frames are being shown and updated every few seconds and then the player hangs. Apart from that, due to other problems with JavaSound is it not possible to implement reasonable quality video players in Java. The JavaSound API has functions to read the current position of the audio playback, to sync the video accordingly, but the accuracy and correctness of this function makes it unusable. Tor
[jira] Commented: (HARMONY-97) ZipOutputStream.close() throws IOException if the stream is already closed
[
http://issues.apache.org/jira/browse/HARMONY-97?page=comments#action_12366743 ]
Svetlana Samoilenko commented on HARMONY-97:
Tim, thank you, bug is not reproducible with latest sources.
ZipOutputStream.close() throws IOException if the stream is already closed
--
Key: HARMONY-97
URL: http://issues.apache.org/jira/browse/HARMONY-97
Project: Harmony
Type: Bug
Components: Classlib
Reporter: Svetlana Samoilenko
Assignee: Tim Ellison
According to 1.5 specification for ?lose() method in interface Closeable:
Closes this stream and releases any system resources associated with it.
If the stream is already closed then invoking this method has no effect.
Harmony throws IOException if the stream is already closed.
Code to reproduce:
import java.io.*;
import java.util.zip.*;
public class test2 {
public static void main(String args[]) {
ZipOutputStream zos = null;
try {
File f=new File(myFile);
f.createNewFile();
f.deleteOnExit();
FileOutputStream ff=new FileOutputStream(f);
BufferedOutputStream b=new BufferedOutputStream(ff);
zos=new ZipOutputStream(new BufferedOutputStream(b));
zos.putNextEntry(new ZipEntry(myFile));
} catch (IOException ee) {
ee.printStackTrace();
}
try {
zos.close();
zos.close();
System.out.println(PASSED);
} catch (IOException ee) {
System.out.println(FAILED);
ee.printStackTrace();
}
}
}
Steps to Reproduce:
1. Build Harmony (check-out on 2006-01-30) j2se subset as described in
README.txt.
2. Compile test2.java using BEA 1.4 javac
javac -d . test2.java
3. Run java using compatible VM (J9)
java -showversion test2
Output:
C:\tmpC:\jrockit-j2sdk1.4.2_04\bin\java.exe -showversion test2
java version 1.4.2_04
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_04-b05)
BEA WebLogic JRockit(TM) 1.4.2_04 JVM (build
ari-31788-20040616-1132-win-ia32, Native Threads, GC strategy: parallel)
PASSED
C:\tmpC:\harmony\trunk\deploy\jre\bin\java -showversion test2
(c) Copyright 1991, 2005 The Apache Software Foundation or its licensors, as
applicable.
FAILED
java.io.IOException: Stream is closed
at java.util.zip.ZipOutputStream.finish(ZipOutputStream.java:157)
at java.util.zip.ZipOutputStream.close(ZipOutputStream.java:66)
at test2.main(test2.java:26)
Suggested fix:
Index: trunk/modules/archive/src/main/java/java/util/zip/ZipOutputStream.java
===
--- trunk/modules/archive/src/main/java/java/util/zip/ZipOutputStream.java
(revision 378195)
+++ trunk/modules/archive/src/main/java/java/util/zip/ZipOutputStream.java
(working copy)
@@ -77,8 +77,7 @@
*/
public void close() throws IOException {
finish();
- out.close();
- out = null;
+ out.close();
}
/**
@@ -165,9 +164,7 @@
* @exception IOException
*If an error occurs while finishing
*/
- public void finish() throws IOException {
- if (out == null)
- throw new
IOException(Msg.getString(K0059));
+ public void finish() throws IOException {
if (cDir == null)
return;
if (entries.size() == 0)
Suggested junit test case:
ZipOutputStreamTest.java
-
import junit.framework.*;
import java.util.zip.*;
import java.io.*;
public class ZipOutputStreamTest extends TestCase {
public static void main(String[] args) {
junit.textui.TestRunner.run(ZipOutputStream.class);
}
public void test_close() {
ZipOutputStream zos = null;
try {
File f=new File(myFile);
f.createNewFile();
f.deleteOnExit();
FileOutputStream ff=new FileOutputStream(f);
BufferedOutputStream b=new BufferedOutputStream(ff);
zos=new ZipOutputStream(new BufferedOutputStream(b));
zos.putNextEntry(new ZipEntry(myFile));
} catch (IOException ee) {
fail(Unnexpected IOException);
}
try {
zos.close();
zos.close();
} catch
[jira] Commented: (HARMONY-79) java.util.jar.Attributes.put(Object name, Object value) doesn't throw ClassCastException
[
http://issues.apache.org/jira/browse/HARMONY-79?page=comments#action_12366745 ]
Svetlana Samoilenko commented on HARMONY-79:
Tim, thank you, I can't reproduce the bug with latest sources.
java.util.jar.Attributes.put(Object name, Object value) doesn't throw
ClassCastException
Key: HARMONY-79
URL: http://issues.apache.org/jira/browse/HARMONY-79
Project: Harmony
Type: Bug
Components: Classlib
Reporter: Svetlana Samoilenko
Assignee: Tim Ellison
Attachments: AttributesTest.java, Attributes_patch.txt
According to the j2se 1.4 and 1.5 specification method
java.util.jar.Attributes.put throws ClassCastException - if the name is not a
Attributes.Name or the value is not a String.
Harmony doesn't throw ClassCastException
1) if the name is not a Attributes.Name
2) if the value is not a String
Code to reproduce:
import java.util.jar.Attributes;
public class test2 {
public static void main(String[] args) {
Attributes att=new Attributes();
try {
att.put(new Object(), new String() );
} catch ( ClassCastException e) {
System.out.println(ClassCastException if the name is not a
Attributes.Name );
};
try {
att.put(new Attributes.Name(IMPLEMENTATION_VENDOR), new
Object());
} catch ( ClassCastException e) {
System.out.println(ClassCastException if the value is not a
String);
return;
};
System.out.println(Wrong. Must be ClassCastException);
}
}
Steps to Reproduce:
1. Build Harmony (check-out on 2006-01-30) j2se subset as described in
README.txt.
2. Compile test2.java using BEA 1.4 javac
javac -d . test2.java
3. Run java using compatible VM (J9)
java -showversion test2
Output:
C:\tmpC:\jrockit-j2sdk1.4.2_04\bin\java.exe -showversion test2
java version 1.4.2_04
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_04-b05)
BEA WebLogic JRockit(TM) 1.4.2_04 JVM (build
ari-31788-20040616-1132-win-ia32, Native Threads, GC strategy: parallel)
ClassCastException if the name is not a Attributes.Name
ClassCastException if the value is not a String
C:\tmpC:\harmony\trunk\deploy\jre\bin\java -showversion test2
(c) Copyright 1991, 2005 The Apache Software Foundation or its licensors, as
applicable.
Wrong. Must be ClassCastException
Siggested fix:
to change the line 232 in
archive/src/main/java/java/util/jar/Attributes.java as follows:
232 return map.put((Name) key, (String) value);
Suggested junit test case:
AttributesTest.java
-
import java.util.jar.*;
import junit.framework.*;
public class AttributesTest extends TestCase {
public static void main(String[] args) {
junit.textui.TestRunner.run(AttributesTest.class);
}
public void test_put () {
Attributes att=new Attributes();
// ClassCastException if the name is not a Attributes.Name
try {
att.put(new Object(), new String() );
} catch ( ClassCastException e) {
// expected
};
//ClassCastException if the value is not a String
try {
att.put(new Attributes.Name(IMPLEMENTATION_VENDOR), new
Object());
} catch ( ClassCastException e) {
// expected
};
}
}
--
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-98) java.util.BitSet.clear(int toIndex,int fromIndex) throws unexpected IndexOutOfBoundsException when toIndex=fromIndex
[ http://issues.apache.org/jira/browse/HARMONY-98?page=all ]
Svetlana Samoilenko updated HARMONY-98:
---
Attachment: fix_hrm-98.txt
Tim, thank you for pointing my tipo out. Could you change fix.txt with
fix_hrm-98.txt?
java.util.BitSet.clear(int toIndex,int fromIndex) throws unexpected
IndexOutOfBoundsException when toIndex=fromIndex
Key: HARMONY-98
URL: http://issues.apache.org/jira/browse/HARMONY-98
Project: Harmony
Type: Bug
Components: Classlib
Reporter: Svetlana Samoilenko
Attachments: fix.txt, fix_hrm-98.txt
According to 1.4.2 and 1.5 specification java.util.BitSet.clear(int,int)
throws IndexOutOfBoundsException - if fromIndex is negative, or toIndex is
negative, or fromIndex is larger than toIndex.
Harmony throws IndexOutOfBoundsException if toIndex=fromIndex.
Code to reproduce:
import java.util.BitSet;
public class test2 {
public static void main(String[] args) {
BitSet set = new BitSet();
for(int i=0; i 20; i++) {
set.set(i);
}
set.clear(10,10);
}
}
Steps to Reproduce:
1. Build Harmony (check-out on 2006-01-30) j2se subset as described in
README.txt.
2. Compile test2.java using BEA 1.4 javac
javac -d . test2.java
3. Run java using compatible VM (J9)
java -showversion test2
Output:
C:\tmpC:\jrockit-j2sdk1.4.2_04\bin\java.exe -showversion test2
java version 1.4.2_04
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_04-b05)
BEA WebLogic JRockit(TM) 1.4.2_04 JVM (build
ari-31788-20040616-1132-win-ia32, Native Threads, GC strategy: parallel)
PASSED
C:\tmpC:\harmony\trunk\deploy\jre\bin\java -showversion test2
(c) Copyright 1991, 2005 The Apache Software Foundation or its licensors, as
applicable.
java.lang.IndexOutOfBoundsException: Negative index specified
at java.util.BitSet.clear(BitSet.java:423)
at test2.main(test2.java:16)
Suggested fix in attachment.
Suggested junit test case:
BitSetTest.java
-
import junit.framework.*;
import java.util.BitSet;
public class BitSetTest extends TestCase {
public static void main(String[] args) {
junit.textui.TestRunner.run(BitSetTest.class);
}
public void test_clear() {
BitSet set = new BitSet();
for(int i=0; i 20; i++) {
set.set(i);
}
set.clear(10,10);
}
}
--
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: I welcome J2SE 6's faster-splash.... re: Java speed-up
This can't be a Java issue - it must be the design-by-committee-for-all-platforms-ever-to-be problem... I would love to see a good sound API in the style of SWT. Call it JavaAudio... Tor-Einar Jarnbjo wrote: Fernando Cassia wrote: I'm still scratching my bald head thinking why hasn't Google embraced desktop java yet. Google Talk would be a killer app written in Swing / 100% Pure Java. It's never stupid to stay realistic. There is no JavaSound implementation giving you enough control of e.g. the sound card latency to allow a usable telephone application to be implemented. H*ck, there's even a pure-java mpeg4 implementation Which doesn't work for me. A few still frames are being shown and updated every few seconds and then the player hangs. Apart from that, due to other problems with JavaSound is it not possible to implement reasonable quality video players in Java. The JavaSound API has functions to read the current position of the audio playback, to sync the video accordingly, but the accuracy and correctness of this function makes it unusable. Tor
[jira] Updated: (HARMONY-68) java.nio.charset.Charset.isSupported(String charsetName) does not throw IllegalCharsetNameException for spoiled standard sharset name
[ http://issues.apache.org/jira/browse/HARMONY-68?page=all ]
Richard Liang updated HARMONY-68:
-
Attachment: charset_patch.txt
Please try my patch according to the spec of Java 5.0 :-)
java.nio.charset.Charset.isSupported(String charsetName) does not throw
IllegalCharsetNameException for spoiled standard sharset name
-
Key: HARMONY-68
URL: http://issues.apache.org/jira/browse/HARMONY-68
Project: Harmony
Type: Bug
Components: Classlib
Reporter: Svetlana Samoilenko
Attachments: charset_patch.txt
According to j2se 1.4.2 specification for Charset.isSupported(String
charsetName) the method must throw IllegalCharsetNameException if the
given charset name is illegal .
Legal charset name must begin with either a letter or a digit.
The test listed below shows that there is no the exception if to insert -
or _ symbols before standard sharset name, for example -UTF-8 or
_US-ASCII.
Moreover the method returns true in this case.
BEA also does not throw the exception but returns false.
Code to reproduce:
import java.nio.charset.*;
public class test2 {
public static void main (String[] args) {
// string starts neither a letter nor a digit
boolean sup=false;
try{
sup=Charset.isSupported(-UTF-8);
System.out.println(***BAD. should be exception; sup=+sup);
sup=Charset.isSupported(_US-ASCII);
System.out.println(***BAD. should be exception; sup=+sup);
} catch (IllegalCharsetNameException e) {
System.out.println(***OK. Expected IllegalCharsetNameException
+ e);
}
}
}
Steps to Reproduce:
1. Build Harmony (check-out on 2006-01-30) j2se subset as described in
README.txt.
2. Compile test2.java using BEA 1.4 javac
javac -d . test2.java
3. Run java using compatible VM (J9)
java -showversion test2
Output:
C:\tmpC:\jrockit-j2sdk1.4.2_04\bin\java.exe -showversion test2
java version 1.4.2_04
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_04-b05)
BEA WebLogic JRockit(TM) 1.4.2_04 JVM (build
ari-31788-20040616-1132-win-ia32, Native Threads, GC strategy: parallel)
***BAD. should be exception; sup=false
***BAD. should be exception; sup=false
C:\tmpC:\harmony\trunk\deploy\jre\bin\java -showversion test2
(c) Copyright 1991, 2005 The Apache Software Foundation or its licensors, as
applicable.
***BAD. should be exception; sup=true
***BAD. should be exception; sup=true
Suggested junit test case:
CharserTest.java
-
import java.nio.charset.*;
import junit.framework.*;
public class CharsetTest extends TestCase {
public static void main(String[] args) {
junit.textui.TestRunner.run(CharsetTest.class);
}
public void test_isSupported() {
boolean sup=false;
// string starts neither a letter nor a digit
try{
sup=Charset.isSupported(-UTF-8);
fail(***BAD. should be exception IllegalCharsetNameException);
} catch (IllegalCharsetNameException e) { //expected
}
// string starts neither a letter nor a digit
try{
sup=Charset.isSupported(_US-ASCII);
fail(***BAD. should be exception IllegalCharsetNameException);
} catch (IllegalCharsetNameException e) { //expected
}
}
}
--
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-99) java.nio.charset.CharsetDecoder.decode(ByteBuffer in) does not throw MalformedInputException when buffer's current position is not legal
java.nio.charset.CharsetDecoder.decode(ByteBuffer in) does not throw
MalformedInputException when buffer's current position is not legal
Key: HARMONY-99
URL: http://issues.apache.org/jira/browse/HARMONY-99
Project: Harmony
Type: Bug
Components: Classlib
Reporter: Svetlana Samoilenko
According to 1.4.2 and 1.5 java.nio.charset.CharsetDecoder.decode(ByteBuffer
in) throws
MalformedInputException - If the byte sequence starting at the input buffer's
current position is not legal for this charset and the current malformed-input
action is CodingErrorAction.REPORT.
Harmony does not throw MalformedInputException in this case as test listed
below shows.
Code to reproduce:
import java.nio.*;
import java.nio.charset.*;
public class test2 {
public static void main(String[] args) throws Exception {
Charset cs =Charset.forName(utf-16);
CharsetDecoder decoder = cs.newDecoder();
decoder.onMalformedInput(CodingErrorAction.REPORT);
decoder.onUnmappableCharacter(CodingErrorAction.REPORT);
CharBuffer out = CharBuffer.allocate(10);
ByteBuffer in = ByteBuffer.wrap(new byte[] { 109, 97, 109});
CharBuffer res1 = decoder.decode(in);
//output
System.out.println(CharBuffer==+res1);
System.out.println(CharBuffer.position ==+res1.position());
System.out.println(toHexString==+Integer.toHexString(res1.charAt(0)));
System.out.println(ByteBuffer.position()==+in.position());
System.out.println(ByteBuffer.remaining()==+in.remaining());
}
}
Steps to Reproduce:
1. Build Harmony (check-out on 2006-01-30) j2se subset as described in
README.txt.
2. Compile test2.java using BEA 1.4 javac
javac -d . test2.java
3. Run java using compatible VM (J9)
java -showversion test2
Output:
C:\tmpC:\jrockit-j2sdk1.4.2_04\bin\java.exe -showversion test2
java version 1.4.2_04
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_04-b05)
BEA WebLogic JRockit(TM) 1.4.2_04 JVM (build ari-31788-20040616-1132-win-ia32,
Native Threads, GC strategy: parallel)
java.nio.charset.MalformedInputException: Input length = 1
at java.nio.charset.CoderResult.throwException()V(CoderResult.java:260)
at
java.nio.charset.CharsetDecoder.decode(Ljava.nio.ByteBuffer;)Ljava.nio.CharBuffer;(CharsetDecoder.java:763)
at test2.main([Ljava.lang.String;)V(test2.java:34)
C:\tmpC:\harmony\trunk\deploy\jre\bin\java -showversion test2
(c) Copyright 1991, 2005 The Apache Software Foundation or its licensors, as
applicable.
res1==
res1==0
toHexString==6d61
ByteBuffer.position()==3
ByteBuffer.remaining()==0
Suggested junit test case:
CharsetDecoderTest.java
-
import junit.framework.*;
import java.nio.*;
import java.nio.charset.*;
public class CharsetDecoderTest extends TestCase {
public static void main(String[] args) {
junit.textui.TestRunner.run(CharsetDecoderTest.class);
}
public void test_decode() {
try {
Charset cs =Charset.forName(utf-16);
CharsetDecoder decoder = cs.newDecoder();
decoder.onMalformedInput(CodingErrorAction.REPORT);
decoder.onUnmappableCharacter(CodingErrorAction.REPORT);
CharBuffer out = CharBuffer.allocate(10);
ByteBuffer in = ByteBuffer.wrap(new byte[] { 109, 97, 109});
CharBuffer res1 = decoder.decode(in);
fail(MalformedInputException should have thrown);
} catch (MalformedInputException e) {
//expected
} catch (CharacterCodingException e) {
fail(unexpected CharacterCodingException);
}
}
}
--
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-99) java.nio.charset.CharsetDecoder.decode(ByteBuffer in) does not throw MalformedInputException when buffer's current position is not legal
[ http://issues.apache.org/jira/browse/HARMONY-99?page=all ]
Richard Liang updated HARMONY-99:
-
Attachment: CharsetDecoder_patch.txt
Please try me patch. At least, it will pass the proposed test case. :-)
java.nio.charset.CharsetDecoder.decode(ByteBuffer in) does not throw
MalformedInputException when buffer's current position is not legal
Key: HARMONY-99
URL: http://issues.apache.org/jira/browse/HARMONY-99
Project: Harmony
Type: Bug
Components: Classlib
Reporter: Svetlana Samoilenko
Attachments: CharsetDecoder_patch.txt
According to 1.4.2 and 1.5 java.nio.charset.CharsetDecoder.decode(ByteBuffer
in) throws
MalformedInputException - If the byte sequence starting at the input buffer's
current position is not legal for this charset and the current
malformed-input action is CodingErrorAction.REPORT.
Harmony does not throw MalformedInputException in this case as test listed
below shows.
Code to reproduce:
import java.nio.*;
import java.nio.charset.*;
public class test2 {
public static void main(String[] args) throws Exception {
Charset cs =Charset.forName(utf-16);
CharsetDecoder decoder = cs.newDecoder();
decoder.onMalformedInput(CodingErrorAction.REPORT);
decoder.onUnmappableCharacter(CodingErrorAction.REPORT);
CharBuffer out = CharBuffer.allocate(10);
ByteBuffer in = ByteBuffer.wrap(new byte[] { 109, 97, 109});
CharBuffer res1 = decoder.decode(in);
//output
System.out.println(CharBuffer==+res1);
System.out.println(CharBuffer.position ==+res1.position());
System.out.println(toHexString==+Integer.toHexString(res1.charAt(0)));
System.out.println(ByteBuffer.position()==+in.position());
System.out.println(ByteBuffer.remaining()==+in.remaining());
}
}
Steps to Reproduce:
1. Build Harmony (check-out on 2006-01-30) j2se subset as described in
README.txt.
2. Compile test2.java using BEA 1.4 javac
javac -d . test2.java
3. Run java using compatible VM (J9)
java -showversion test2
Output:
C:\tmpC:\jrockit-j2sdk1.4.2_04\bin\java.exe -showversion test2
java version 1.4.2_04
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_04-b05)
BEA WebLogic JRockit(TM) 1.4.2_04 JVM (build
ari-31788-20040616-1132-win-ia32, Native Threads, GC strategy: parallel)
java.nio.charset.MalformedInputException: Input length = 1
at
java.nio.charset.CoderResult.throwException()V(CoderResult.java:260)
at
java.nio.charset.CharsetDecoder.decode(Ljava.nio.ByteBuffer;)Ljava.nio.CharBuffer;(CharsetDecoder.java:763)
at test2.main([Ljava.lang.String;)V(test2.java:34)
C:\tmpC:\harmony\trunk\deploy\jre\bin\java -showversion test2
(c) Copyright 1991, 2005 The Apache Software Foundation or its licensors, as
applicable.
res1==
res1==0
toHexString==6d61
ByteBuffer.position()==3
ByteBuffer.remaining()==0
Suggested junit test case:
CharsetDecoderTest.java
-
import junit.framework.*;
import java.nio.*;
import java.nio.charset.*;
public class CharsetDecoderTest extends TestCase {
public static void main(String[] args) {
junit.textui.TestRunner.run(CharsetDecoderTest.class);
}
public void test_decode() {
try {
Charset cs =Charset.forName(utf-16);
CharsetDecoder decoder = cs.newDecoder();
decoder.onMalformedInput(CodingErrorAction.REPORT);
decoder.onUnmappableCharacter(CodingErrorAction.REPORT);
CharBuffer out = CharBuffer.allocate(10);
ByteBuffer in = ByteBuffer.wrap(new byte[] { 109, 97, 109});
CharBuffer res1 = decoder.decode(in);
fail(MalformedInputException should have thrown);
} catch (MalformedInputException e) {
//expected
} catch (CharacterCodingException e) {
fail(unexpected CharacterCodingException);
}
}
}
--
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
