[classlib][general]find a more proper folder to put src-jars?
Hi All, Currently Harmony has pack all its source files into jars and put them in deploy\jdk\jre\lib\boot, e.g, luni-src.jar, nio-src.jar, etc(I don't know when this happens, however they are here now). In most cases it does not disturb any one. However when I fix something in a package(luni) and try to debug in test, eclipse always lead me to the source files in the jar, not the file in the workspace I currently modify, this do take me into trouble until I find the reason and delete luni-src.jar.(My run environment in eclipse 3.2: take Harmony as JRE, put main-luni\bin and JRE-System Library[Harmony] into clasapath- bootstrap entries; put test-luni\bin, junit and support into classpath- User entries. It works well, only some trouble in debugging). So IMHO Harmony may find another folder to put these src-jars, e.g., a src folder in deploy\jdk, which can be much clear, and will not make trouble in debugging any more. Any suggestions/options? Thanks! -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM
Re: [general] TLP transition - site has been moved, redirect in place
Geir Magnusson Jr. wrote: We now have a site http://harmony.apache.org/ and there's a redirect from http://incubator.apache.org/harmony/ to there. Tomorrow sometime we'll do the mail switch - that should be totally transparent - new lists will be created, sub lists will be copied, and mail going to old will be forwarded to new. I'll have the website setup before hand, do the switch, and then update the site. Also, Friday night eastern we'll do the SVN switch to avoid catching people in the middle of work (ok, some will still be caught...). A simple svn switch will fix your local copy, so you shouldn't have to re-check anything out. JIRA has been re-categorized, and I'll be asking for a solaris zone to play in. I've found the new page, great! ;) And do we have to change the mail address harmony-dev@incubator.apache.org to [EMAIL PROTECTED] or so tomorrow? -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM
Re: [testing][nio] 2 tests fail on the SUSE linux
Vladimir Ivanov wrote: Hello everyone, today my cruise control failed on the linux SUSE box with 2 errors in the org.apache.harmony.nio.tests.java.nio.channels.SocketChannelTest test. Could somebody reproduce/ fix this issue? Thanks, Vlaidimir Tests testSocket_configureblocking and testCFII_ConnectAfterFinish_Server_NonBlock reports ERROR with similar output: The address is not available java.net.BindException: The address is not available at org.apache.harmony.luni.platform.OSNetworkSystem.socketBindImpl(Native Method) at org.apache.harmony.luni.platform.OSNetworkSystem.bind( OSNetworkSystem.java:126) at org.apache.harmony.luni.net.PlainSocketImpl.bind(PlainSocketImpl.java:161) at java.net.ServerSocket.init(ServerSocket.java:116) at java.net.ServerSocket.init(ServerSocket.java:72) at org.apache.harmony.nio.tests.java.nio.channels.SocketChannelTest.setUp( SocketChannelTest.java:77) Hi, I have run the test with latest Harmony with IBMVME on SUSE 10 Enterprise but find nothing wrong. However IMO it was Support_PortManager.getNextPort() cause the problem. This method, as we already know, is unsafe. Thus the test is not stable sometimes, though it appears in-frequently. We may find a way to fix it, e.g, try to bind to an available port, check if successful. -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM
Re: [announcement] Apache Board approved Apache Harmony as a Top Level Project of the ASF
Cl! Let's cheer! :D Geir Magnusson Jr. wrote: I am happy to report that the Apache Board was willing to consider our proposal and voted to accept it at today's board meeting. As stated in the Incubation vote, this is a necessary condition for graduation from the Incubator. Therefore, upon a successful outcome of the Incubator PMC vote, we are Apache Harmony, project of the Apache Software Foundation! Congratulations to everyone! When the vote is complete, we'll get to work on the transition activities, but until then, just give yourself a well-deserved pat on the back. Thanks all! geir -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM
Re: [classlib][pack200] Unpacked my first archive today!
Alex Blewitt wrote: I managed to unpack a Pack200 file completely today for the first time, so that by the end of it there were no bytes left in the queue. Unfortunately, it wasn't a spectacularly exciting archive -- just one interface with no methods (about as exciting as java.lang.Serializable, in fact) but I think that I've unlocked the next stage in the process for decompressing the attributes that are left (including things like bytecodes, etc.). That's great achievement! :) At the moment, the data is just in an unpacked state; I've not yet looked at re-assembling the data into their constituent .class files (need to get hold of the class bytecode format for that) or even reconstituting the Jar file. I'm thinking of using ZipEntry and ZipOutputStream (or corresponding Jar variants) for building the resulting Jar file. I'm not sure whether they are implemented or not in the current trunk or not, but I might start working against the ZipOutputStream/ZipEntry APIs. Yes, IMHO it is necessary to understand class bytecode format. And Zip/Jar file operations has already implemented, you can use either Java APIs in Harmony or C APIs(we have zlib in archive\src\main\native) if necessary. Onward and upward ... Good luck! :) Alex. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[classlib][test]Deal with un-deleted temp files created in tests
Hi, Recently I find some temp files created in tests are not deleted. We may delete them, or put them in test/resource . 1)in module\archive: modules\archive\GZIPOutFinish.txt modules\archive\GZIPOutClose2.txt modules\archive\GZIPOutWrite.txt modules\archive\JDK2-3gabba.zip Take a close look into it, the first three files are created in GZIPOutputStreamTest. Seems the files were deleted in tearDown(), but very strangely the lines of deleting files was comment-out without any comment. Do anyone know why? If I delete these files, no error was occurred in test on winxp. And the last file was created ZipFileTest, which has a comment that Note zfile is a user-defined zip file used by other tests and should not be deleted, it seems it must be put in resource directory. However,if I do delete it in tearDown(), no error was occurred while run archive test on winxp. 2)in luni: modules\luni\hyts_missingclass.ser This file is created in ObjectInputStreamTest. The test try to test serialization, however it did not follow our serialization-test framework. The fix is easy (change it to use the framework). 3)in jndi: a new directory org\apache\harmony\jndi\tests\javax\naming\spi with a file jndiprovider.properties and a sub directory mock. This directory is created in NamingManagerTest, I guess it must be put in some place in test\resource ? Any suggestions/comments? And any more such files to deal? Thanks! -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][net] The old fix is not complete (was Re: [jira] Updated: (HARMONY-1117) [classlib][net] Harmony implementation of SocketImpl.getFileDescriptor() return real object, but RI return null)
Andrew Zhang wrote:
I don't think the fix is complete. The patch only fixed reported bug, but
introduces new severe bugs.
Because fd would never be initialized after applying the patch. Running all
tests would also fail with crash.
Yes, fd without initialized may cause a tragedy, all network functions
relay on this.
After deleting initialization code in SocketImpl.java, we have to
initialize
SocketImpl.fd elsewhere. I suggest add the code into
PlainSocketImpl.createmethod. Am I right?
I believe this may be correct. Or we can add a constructor in
PlainSocketImpl, initial fd there.
If no one objects, I'll apply a patch to fix this jira. Thanks!
On 8/9/06, Igor V. Stolyarov (JIRA) [EMAIL PROTECTED] wrote:
[ http://issues.apache.org/jira/browse/HARMONY-1117?page=all ]
Igor V. Stolyarov updated HARMONY-1117:
---
Attachment: Harmony-1117.patch
Fix attached
[classlib][net] Harmony implementation of
SocketImpl.getFileDescriptor()
return real object, but RI return null
---
Key: HARMONY-1117
URL: http://issues.apache.org/jira/browse/HARMONY-1117
Project: Harmony
Issue Type: Bug
Reporter: Igor V. Stolyarov
Attachments: Harmony-1117.patch
Harmony implementation of SocketImpl.getFileDescriptor() return real
object, but RI return null
Test---
import java.io.*;
import java.net.*;
public class Test {
public static void main(String[] args) {
try {
TestSocketImpl testSocketImpl = new TestSocketImpl();
System.out.println(res=+testSocketImpl.getFileDescriptor()
);
} catch (Exception e) {
e.printStackTrace();
}
}
}
class TestSocketImpl extends SocketImpl {
public FileDescriptor getFileDescriptor(){
return super.getFileDescriptor();
}
protected void create(boolean arg0) throws IOException {}
protected void connect(String arg0, int arg1) throws IOException {}
protected void connect(InetAddress arg0, int arg1) throws
IOException {}
protected void connect(SocketAddress arg0, int arg1) throws
IOException {}
protected void bind(InetAddress arg0, int arg1) throws
IOException{}
protected void listen(int arg0) throws IOException {}
protected void accept(SocketImpl arg0) throws IOException {}
protected InputStream getInputStream() throws IOException {
return null;
}
protected OutputStream getOutputStream() throws IOException {
return null;
}
protected int available() throws IOException {
return 0;
}
protected void close() throws IOException {}
protected void sendUrgentData(int arg0) throws IOException {}
public void setOption(int arg0, Object arg1) throws
SocketException{}
public Object getOption(int arg0) throws SocketException {
return null;
}
}
Output
Harmony:
java version 1.5 (subset)
(c) Copyright 1991, 2006 The Apache Software Foundation or its
licensors, as app
licable.
[EMAIL PROTECTED]
JRockit:
java version 1.5.0
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-b64)
BEA WebLogic JRockit(R) (build dra-38972-20041208-2001-win-ia32,
R25.0.0-75, GC:
System optimized over throughput (initial strategy singleparpar))
res=null
--
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
--
Best Regards!
Jimmy, Jing Lv
China Software Development Lab, IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] catching up
Tim Ellison wrote: Just catching up on harmony mail after a break from the keyboard. I'll write my apologies once here for picking up on a number of threads late. Looks like things are steaming along quite nicely. Tim Great news, welcome back! :) -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] [jvmti] Question about JVMTI calling Java code
Gregory Shimansky wrote: Hello I have recently identified a problem which may potentially lead to an infinite recursion with the current implementation of some JVMTI functions in DRLVM. The functions like GetThreadInfo or GetThreadGroupInfo call Java methods like Thread.getName() to return the necessary information to the JVMTI agent. This works ok in most cases but in case an agent chooses to call such methods from inside of events like MethodEntry, MethodExit, SingleStep, Breakpoint, etc for the exact Java methods like Thread.getName() this may easily lead to an infinite recursion. For the current DRLVM Thread Manager implementation it doesn't seem to be possible to get all of the information about Thread or ThreadGroup from native code only, so it is necessary to call Java anyway and I see only one solution which may not be perfect. It is possible to create a thread local flag for JVMTI which will disable sending any events to the loaded agents while calling Java code from inside of JVMTI API functions. This may impact the results of profiler agents and potentially miss some methods in CompiledMethodLoad event for tools like VTune, ThreadChecker and other. So I am unsure whether this fix is necessary or should we change threading code to make it possible to provide all necessary information in the native. The currently called Java Methods are Thread.getName() Thread.getPriority() Thread.isDaemon() Thread.getThreadGroup() Thread.getContextClassLoader() Thread.setDaemon() ThreadGroup.getParent() ThreadGroup.getName() ThreadGroup.getMaxPriority() ThreadGroup.isDaemon() ThreadGroup.enumerate() Quite a lot of these functions return information which is available from native code, but functions like Thread.getContextClassLoader() require calling Java. IIRC, the class Thread(and ThreadGroup) itself is a kernel class, isn't it? It may be easier to get a inner field(e.g, thread name) than invoking a method. I don't know DRLVM well, However I doubt if JVMTI and kernel class are together there in VM, it may be a clear and easy way to know each other? -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][security] problem processing SHA signatures in JBoss installer manifest
Richard Liang wrote:
After two-day struggling with JarFile, ObjectInputStream and
MessageDigest, in the end, I have identified the root cause. And now I
have two panda-eyes[1] ;-)
It seems a bug of
org.apache.harmony.security.provider.crypto.SHA1Impl. As I have no
idea about SHA1. Could any one have a look at this problem?
The following test case passes on RI, but fails on Harmony.
public void testUpdate() throws NoSuchAlgorithmException {
byte[] bytes = { 0x6e, 0x61, 0x6d, 0x65};
MessageDigest sha1 = MessageDigest.getInstance(SHA1);
byte[] digest1 = sha1.digest();
byte b = 0x04;
sha1.update(b);
for (int i = 0; i bytes.length; i++) {
sha1.update(bytes[i]);
}
byte[] digest2 = sha1.digest();
sha1.reset();
byte[] digest3 = sha1.digest();
assertTrue(MessageDigest.isEqual(digest1, digest3));
sha1.update(b);
sha1.update(bytes, 0, bytes.length);
byte[] digest4 = sha1.digest();
assertTrue(MessageDigest.isEqual(digest2, digest4));
}
[1]http://www.panda.org.cn/zhuye/bbe.jpg
Poor Richard! Looking for a needle in a bottle of hay, right? ;)
A closer study on SHA1Impl, I find these lines(line 194) may be wrong:
for ( ; ( i = toByte ) ( byteIndex 4 ) ; i++ ) { // *NOTE* it use
// = here
intArray[wordIndex] |=
( byteInput[i] 0xFF ) ((3 - byteIndex)3) ;
byteIndex++;
}
if ( byteIndex == 4 ) {
wordIndex++;
if ( wordIndex == 16 ) {
computeHash(intArray);
wordIndex = 0;
}
}
if ( i = toByte ) { // *NOTE* it use = here
return ;
}
Though I don't know SHA1 well, I guess it must be in the line of
second *NOTE*.
This bug happens when byteIndex==1, and fromByte==0, toByte==3(that is,
input byte number is 4). The first circle inputs 3 bytes into array,
leaving the last byte for next step. But at that time i==toByte, so the
last byte is omitted, which is properly an mistake.
Change it to if (i toByte) will solve the problem, I've run all
tests, including Richard's test, and they all passes. It'll be better
someone knows SHA1 check it.
If no objection, we can create a patch.
Best regards,
Richard
On 9/11/06, Richard Liang [EMAIL PROTECTED] wrote:
On 9/9/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
I was trying the latest snapshot with the JBoss installer (4.0.1) and
found a problem processing the SHA signatures int the jar manifest.
I've entered a JIRA - HARMONY-1412
I will have a look at it. ;-)
geir
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Richard Liang
China Software Development Lab, IBM
--
Best Regards!
Jimmy, Jing Lv
China Software Development Lab, IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib]volunteer to supply patches for old JIRAs
Tony Wu wrote: so helpful suggestion, thank you Nathan. According to Nathan's suggestion, I suggest we go ahead as below, 1. verify all the issues without patch, supply a patch if possible. 2. for the issues already has a patch, verify the reason why it was ignored, and then a.write testcase if caused by lack of test. b.supply another patch if the patch is out of date. c.add comments to support it if the patch is ok. Wonderful plan :) IIRC, there's a open JIRA of management, it is because Harmony java.lang.management does not exist yet, please ignore. And please ignore HARMONY-1375, it is in discussion still. Waiting for your summary :) On 9/13/06, Nathan Beyer [EMAIL PROTECTED] wrote: Here are a few things that I think might help with getting through some of the older outstanding issues, as well as new ones. * If an issue is old (over a month???), then verify that it's still an issue with the latest code and note this with a JIRA comment. * Obviously posting patches is great, but patches without tests are almost always ignored. ** If you're posting an enhancement, post a patch that enhances the tests and make sure they pass on an RI. (I always make sure the test passes on the RI before considering the patch.) ** If you're posting a fix, post a patch that includes a regression test. (I always apply the test first, then run it to see it fail, then I look at the fix.) * If there's a particular JIRA issue that you would like fixed and a patch already exists, try applying the patch yourself, verify it and then add a comment supporting the patch. -Nathan -Original Message- From: Tony Wu [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 12, 2006 10:26 PM To: harmony-dev@incubator.apache.org Subject: Re: [classlib]volunteer to supply patches for old JIRAs On 9/13/06, Spark Shen [EMAIL PROTECTED] wrote: Tony Wu 写道: Hi all, I noticed there're many unresolved JIRAs posted so long time. I purpose to dive into and find whether it is in my range and try to supply a patch if no one objects :) Is there anyone alse has interest and would like to work with me? Hi, It is interesting of your proposal. May I join in? Great! Welcome! I noticed that there are many categories of components. I suggest we only deal with those components we are familier with. Since there are so many unresolved JIRAs, will you start from the beginning and I will start from the end. If someone else is interested, he/she may start from the middle. :-) good idea, I'll start to look in descendent order of jira sn. Best regards -- Spark Shen China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Tony Wu China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][internationalization]Are log messages and tools usage text to be internationalized?
Ilya Okomin wrote: Hi all, During rmi module internationalization I've faced with loads of log messages (e.g. take a look at o.a.h.rmi.DefaultRMIClassLoaderSpi). Also some classes (e.g. o.a.h.rmi.compiler.RmicStrings) have strings that are the usage texts of any console tool. I think we shouldn't internationalize such messages, however I'm not really sure about that. If we internationalize them - we'll obtain fully internationalized module it is an advantage. From the other hand - if you have to analyse someone's log, it is useful if the common langauge was used. Moreover, messages.properties file with the list of all messages will be too huge to find appropriate messages for new classes developed later. Any thoughts? IMHO, we have agree on that all console output can be internationalized. If the only problem of a too huge messages.properties file is to find appropriate, I guess we can: 1. Separate the file into several smaller ones, one for console, one for error message, etc. Or 2. add a prefix to the String name, for an example, rmi.console.1, rmi.errormsg.2. it can be more detail. In this way we can find some certain message easy. And I prefer 2. -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][luni] Put setInterruptAction() in our j.l.Thread stub?
Gregory Shimansky wrote: On Friday 08 September 2006 06:03 Jimmy, Jing Lv wrote: Geir Magnusson Jr. wrote: This came up in another thread. Currently, java.nio.channels.spi.AbstractInterruptibleChannel depends on there being a setInterruptAction() method on java.lang.Thread. I certainly think that this kind of thing should be documented, so the question - should we add this to our Thread stub class? Yes, the VMs whose Thread do not know how to interrupt a certain understratum blocking I/O(socket read/write, select, or so) is likely to use this method. Though DRLVM using SIGUSR2 may not meet this problem( does SIGUSR2 work on windows?). I agree this must be documented. DRLVM doesn't use POSIX signals on windows if you mean if they work in DRLVM. And if you mean whether they work in the same way as on Linux in regard of interrupting blocked IO I don't think so. POSIX signals on windows work in their own specific to windows kernel version way which makes them quite useless. In this way I believe that method is necessary, maybe not only for windows but also for other platforms. +1 of course to document to the above Geir question -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][luni] Put setInterruptAction() in our j.l.Thread stub?
Geir Magnusson Jr. wrote: This came up in another thread. Currently, java.nio.channels.spi.AbstractInterruptibleChannel depends on there being a setInterruptAction() method on java.lang.Thread. I certainly think that this kind of thing should be documented, so the question - should we add this to our Thread stub class? Yes, the VMs whose Thread do not know how to interrupt a certain understratum blocking I/O(socket read/write, select, or so) is likely to use this method. Though DRLVM using SIGUSR2 may not meet this problem( does SIGUSR2 work on windows?). I agree this must be documented. But to DRLVM, one problem is how to tell the interruption is necessary(say, user invoke wake() or some other methods to ask them to stop) or can be ignored(say, caused by other unrelated interruption and can be recover like recently fix to hysock.c and socket.c). geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][luni] socketus interruptus - fix committed
Geir Magnusson Jr. wrote:
I committed the initial fix to the socket interrupt problem. I stared
at it a while and did what I thought the simplest thing possible. (Most
of the staring was trying to grok some of the intent in the socket.c and
hysock.c code...
Simply put, I ensured that hysock_select() just dealt w/ that return
code correctly, translating to the HSOCK error code. (I also did a bit
of reformatting... apologies if it really upsets someone - I'll put it
back). The result is that hysock_select() still behaves the same.
I also modified one function in socket.c - the pollSelectRead() call -
to deal with the interrupt return code from hysock_select().
I *think* I got it right, and am hoping that some others can review and
comment. I'm embarrassed to have used a 'goto' (mimicing the style
there), but didn't want to do the rewrite I wanted to while also fixing
the interrupt problem. :) (I also want some better tests before we take
it apart...)
I've taken a quick review on the two files, and I like the reformatting
:) Maybe the goto can be avoid, but this does not matter much.
I notice the port lib, say hysock.c is modified, adding a line:
if (errno == EINTR) {
rc = portLibrary-error_set_last_error(portLibrary, errno,
HYPORT_ERROR_SOCKET_INTERRUPTED);
}
IMHO, we can avoid this modification, for method in socket.c the result
is judged by the return value(result), not last_error. IMHO, we'd
better do no modification on port lib. Please correct me if I'm wrong.
This of course fixes the problems w/ Tomcat that we created w/ the DRLVM
thread manager fix, so I'm going to try to spin a new snapshot tonight.
Also, I'll go and treat the other usages of hysock_select() to deal w/
this return code, but after there's been a period of review and comment
for these changes.
I have no objection if everything goes well, but still worry about how
to tell the difference between a necessary interruption(user
interruption) and this recover-able interruption.
geir
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Best Regards!
Jimmy, Jing Lv
China Software Development Lab, IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][luni] signalis interruptus in hysock
Geir Magnusson Jr. wrote: Artem Aliev wrote: The hyport and hy* are a porting layer that provides os independent interface. hysock_select() does not return EINTR on windows why it should do it under linux? either user presses Ctrl-c or ctrl-\ or VM uses other signals for its owns needs. I think you just gave me the answer. The *caller* to hysock_select() needs to decide what to do on EINTR, not hysock_select() itself. +1 to this solution, let's first keep portlib as it is, IIRC, there's many native methods refers it. But I'm still worry about ignore the signal in select(or its callers). I know few about the SIGUSR2, but I doubt if some user give a signal to the thread, how can our select process tell if the signal comes from user or form VM? Shall it continue anyway? Mask the signal may be a better way, select only stop when a certain signal comes with a certain mask. However it may still puzzle the native code if user also use masks. I was thinking the powerful SIGUSR2 may resolve some problem straightforwardly(like wakeup, etc.), but now I see there are still many problems. I believe J9 was not using any lib like SIGUSR2, maybe they create and handle threads themselves (RI may do like this as well). I'll keep an eye on the discussion, there are may select-related native codes to deal ... I still don't think this is a perfect solution, but I think it's better :) I still want to know about J9 though. Maybe I need to go work for IBM again :) geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib]strings externalization
Ilya Okomin wrote:
Hi, Jimmy!
It's great that you are interested in it!
Unfortunately there is no automatic externalization generation tool that
fits our needs. However, you can combine Eclipse externalization tool with
some manual work to get what is need. You can take a look into the
[classlib]strings externalization thread [1] for details. Main points
briefly:
1. Using Eclipse externalization tool you can extract all strings from the
sources. When you process certain source file strings that used for
messages
should be externalized, others should be ignored (as a result, Eclipse mark
them with non-nls tag).
2. Eclipse tool by default suggests you to use keep messages from each
class
in the separate messages.properties file, and keys in the properties file
will looks like class_name.id. We've decided to have one messages list
for each module with keys module.id (in your case module ==
instrument
:)). Thus at first you should change common prefix to module.. Next
step
is to configure Accessor class field: choose the proper package for
Messages class and messages.properties file(org.apache.harmony
.module.msgstool).
What is to take care of:
1. Continuation of the numeration of messages. For every new source file
you
process Eclipse tool will reset enumeration, and you should manually set
the
appropriate number for messages. Also it would be better if you avoid
messages duplication in the list. (Pretty annoying if you have many
messages
in the module and some of them are duplicated)
2. Messages formatting. If you have message located on the several source
code lines - you should concatenate them into one message string and use
one
Messages.getString(..) call. Also messages with arguments are supposed
to be
converted to strings with places for substitution by parameters being
arguments in Messages.getString() method. E.g. code:
int param;
...
NullPointerException(foo + param + bar);
supposed to be formatted as
NullPointerException(Messages.getString(module.1, param));
where module.1=foo {0} bar in the resource bundle.
I hope now the process is clear.
You can find examples of internationalized messages in the [sql] module.
As for messages in native code, actually I dealt only with java code.
You may find something interesting for you from the [drlvm] proposals for
VM c thread [2].
Regards,
Ilya.
[1]
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200607.mbox/[EMAIL PROTECTED]
[2]
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200607.mbox/[EMAIL PROTECTED]
Thanks Ilya, I'll apply patch soon. I deal with Java code only this
time, it is simple that I only find 3 strings :) I'll put them in
messages.properties under instrument with name instrument.1(2,3) and
update codes.
Instrument also have an console output string, I suggest also put it to
property file so it can be internationalization as well. Then there are
4 total.
And strings in native code may be refactored if we have conclusion of
native internationalization.
snip
--
Best Regards!
Jimmy, Jing Lv
China Software Development Lab, IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Created: (HARMONY-1295) [classlib][net] flaw in setReuseAddrAndReusePort()
Andrew Zhang wrote: On 8/29/06, Alexey Varlamov [EMAIL PROTECTED] wrote: 2006/8/29, Andrew Zhang [EMAIL PROTECTED]: On 8/28/06, Alexey Varlamov (JIRA) [EMAIL PROTECTED] wrote: [classlib][net] flaw in setReuseAddrAndReusePort() -- Key: HARMONY-1295 URL: http://issues.apache.org/jira/browse/HARMONY-1295 Project: Harmony Issue Type: Bug Components: Classlib Reporter: Alexey Varlamov Priority: Critical The tests.api.java.net.DatagramSocketTest test crashes on assert in DRLVM : Assertion `IsInstanceOf(env, obj, struct_Class_to_jclass(f-get_class()))' failed. The reason is that java.net.DatagramSocket.setReuseAddress(boolean) calls to PlainDatagramSocketImpl.setOption(int optID, Object val) with Boolean value, but underlying native code treats this value as Integer. Quickfix must be straightforward enough, but I inclined to blame the design of INetworkSystem.[set|get]SocketOption() as the actual root of the evil. The problem is that this API conceals the details of contract for particular options, and a client have to guess which type of value to pass. I think it's determine, not guess. :) And the implementation is basically an ugly switch sorting requests out to setBoolSocketOption() or setIntegerSocketOption(), etc. Shouldn'te refactor this? Any proposals? Thanks! Of course, lots of them ;). Just to start: 1) Why at all we clone underlying OS interface to Java with extra mapping JAVASOCKOPT_* to HY_SO_*? Totally agree with you. :) Current two option lists are duplicated. I think we'd better use one type defination. Let's have a clean API with specialized methods as XXXSocket classes have: setTTL(int) , isReuseAddress() etc. It's a design problem. The legacy design provides simple unified interface to classlib, while your proposal seems more specific and direct for classlib API usage. 2) At least we could provide more typified [s|g]etOption() methods, which take/return primitive values instead of wrappers. At first glance int and boolean would fit all needs, am I wrong? This way, type mismatch will be found immediately during compilation. Though this would not detect optid and value type disparity... Agree. For this case, at least, we could use booleanValue for Boolean and intValue for Integer. :) Interesting, deep look into code, I find JNI use pointer as the field ID, so field-ID of value in Boolean is the same as the one of Integer. In this way the code can get a value field of Integer out of a Boolean (C pointer is great! :) ). IMO, this is a mis-use but cause no error until a strict check is taken. :) This is a bug of native code, I agree we should use booleanValue instead of intValue, may we raise a JIRA and fix? -- Regards, Alexey - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib]strings externalization
Ilya Okomin wrote: Tim, great news for me. Everything looks fine with the patch you've applied, now it's time for the main part of the task. I've created HARMONY-1308 issue with task description. This issue is devided into a set of sub-issues for each module. I'm going to process them one by one. These issues can be processed in a parallel way, so everyone is welcomed to take part in the internationalization process :) Hi, Ilya, I'd like to process instrument :) Can you tell me something about the generation tool, or how can we process these strings? Is there anything to take care of? And in fact, in java.lang.instrument, there are some error messages in native code(AFAIK, there are also many in luni). Is there any tool to find them out automatic ? Thanks, Ilya. On 8/29/06, Tim Ellison [EMAIL PROTECTED] wrote: Thanks for waiting Ilya, I've applied the final patch on HARMONY-1201 (I'll check-in the tool when I get back from vacation). So now we can get to work on breaking out the messages into each component's message file. Regards, Tim Ilya Okomin wrote: On 8/11/06, Tim Ellison [EMAIL PROTECTED] wrote: I took a look at the HARMONY-1041 tool. It is fine, I have only minor comments: - do you think we need to separate the Message and MsgUtil types? Given that they are generated from a template I'd be inclined to combine them into a single type now. We have no need to look in that file in general. If you do choose to combine them then I would expect the resulting header to be (c) 1998, 2006. - Minor typo Better make changes in the teamplate file. - template. Ilya Okomin wrote: I would suggest to split this task into a set of jira sub-issues, one module - one issue. This kind of division would give us an opportunity this work to be done in a parallel mode. Agreed. I suggest that we run the msgtool on the existing modules and commit the generated code and catalog files, then the incoming patches can assume they are there and use them to fix the externalization. Hello, Tim! I've made changes to the generation tool [1] and also prepared patch with the set of generated files according to the existing modules set I've raised issue for that [2]. Not all modules were included into the generation (full set can be found in comments to the [2]). E.g. x-net module has package xnet, also I'm not sure about necessity to make internationalization in suncompat or rmi2, etc. You can check list of suggested modules and if something is missed I'll make update. Waiting for your comments and proposals! [1]http://issues.apache.org/jira/browse/HARMONY-1041 [2]http://issues.apache.org/jira/browse/HARMONY-1201 Regards, Ilya. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ClassLib][Instrument]Put tests to Harmony (and Support_Exec)
Hi, The development on instrument is going to an end (I may still apply a few patches of refine). And the tests for it do help a lot in finding bugs and applying compatibility with RI, and special thanks to Stepan and Support_Exec. :) However, I still have a problem with Support_Exec, it usually, if not always, meets a problem in loading kernel classes. Tracing into the code, I find it add a parameter -Xbootclasspath: to launcher with a System Property(com.ibm.oti.system.class.path, I'm using J9 for DRLVM not ready for jvmti yet). But the property was null on my workspace. After deleting that parameter, I get all tests pass using both Ant and eclipse. So can someone tell me how to handle this? Or can I make a little update to it? All existing tests has pass on both Harmony and RI in my workspace(Linux/windows) when make a little change to lib name. Though VM may not be updated for it very soon, I'd like to add tests to Harmony, make it excluded first until VM ready, in order that some one who is interested can check by making a little change and run tests. Any comments/suggestions? -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ClassLib][Instrument]Put tests to Harmony (and Support_Exec)
Oliver Deakin wrote: Jimmy, Jing Lv wrote: Hi, The development on instrument is going to an end (I may still apply a few patches of refine). And the tests for it do help a lot in finding bugs and applying compatibility with RI, and special thanks to Stepan and Support_Exec. :) However, I still have a problem with Support_Exec, it usually, if not always, meets a problem in loading kernel classes. Tracing into the code, I find it add a parameter -Xbootclasspath: to launcher with a System Property(com.ibm.oti.system.class.path, I'm using J9 for DRLVM not ready for jvmti yet). But the property was null on my workspace. After deleting that parameter, I get all tests pass using both Ant and eclipse. So can someone tell me how to handle this? Or can I make a little update to it? One problem here will be that com.ibm.oti.system.class.path went out with VME v3. In VME v4 we use org.apache.harmony.boot.class.path (see modules\luni\src\main\native\luni\shared\luniglob.c). Looking at Support_Exec, it appears that this setting is out of date and should be updated with the new value. Does this fix your problem? I see :) So could I fix this value? All existing tests has pass on both Harmony and RI in my workspace(Linux/windows) when make a little change to lib name. Though VM may not be updated for it very soon, I'd like to add tests to Harmony, make it excluded first until VM ready, in order that some one who is interested can check by making a little change and run tests. Any comments/suggestions? Sounds like a good idea - it seems that the workaround to run on the IBM VME is pretty straightforward, so people will be able to run the tests if they want to. Then when a new VME is out and/or drlvm catches up we can make the tests live. Great, if no objections I'll apply tests soon :) Regards, Oliver -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][instrument]and[VM]:launcher with parameter javaagent
Geir Magnusson Jr wrote: Jimmy, Jing Lv wrote: Hi, On writing tests for java.lang.instrument, I find it nice Harmony launcher can accept parameter -javaagent currently. Look deep into the launcher code, I find the parameter was really parsed by VM itself currently. And if I use J9VM, it can accept such parameter but ask for instrument.dll. As we know, Harmony naming convention use hyXXX.dll as dll-file name. Time to fix that. So vm fails to load lib here. However if I copy the file hyinstrument.dll to instrument.dll, J9VM load it happily and pass my test on Instrument. Yay! I do not know what does DRLVM or other VMs do here (I'd like to hear if jvmti has been implemented in DRLVM). I have zero interest in perpetuating the hy abhorrence. Hi, So Harmony is going to omit hy in DLLs? Do we have a plan on that? It'll be nice as test can work without VM changes :) So Instrument testcases can not be put to svn until this problem is solved (or it'll break build!). I guess there are two ways here: 1. to work around, add a line in build.xml, copy the file to instrument.dll, and wait for VM to get updated. Or we change filename in build system forever? Yay! 2. I wonder if we can modify in launcher, parse the parameter and pass the dll filename to VM? That's a very good idea - then you can A/B test with known good instrumentation. geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[classlib][instrument]and[VM]:launcher with parameter javaagent
Hi, On writing tests for java.lang.instrument, I find it nice Harmony launcher can accept parameter -javaagent currently. Look deep into the launcher code, I find the parameter was really parsed by VM itself currently. And if I use J9VM, it can accept such parameter but ask for instrument.dll. As we know, Harmony naming convention use hyXXX.dll as dll-file name. So vm fails to load lib here. However if I copy the file hyinstrument.dll to instrument.dll, J9VM load it happily and pass my test on Instrument. I do not know what does DRLVM or other VMs do here (I'd like to hear if jvmti has been implemented in DRLVM). So Instrument testcases can not be put to svn until this problem is solved (or it'll break build!). I guess there are two ways here: 1. to work around, add a line in build.xml, copy the file to instrument.dll, and wait for VM to get updated. Or we change filename in build system forever? 2. I wonder if we can modify in launcher, parse the parameter and pass the dll filename to VM? Any suggestions?Thanks! -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][luni] Suspicious behavior of java.util.EnumSet
Spark Shen wrote:
Hi All:
The following behavior of RI java.util.EnumSet seems odd. Do you have
any opinion on whether it is a bug of RI?
import java.util.EnumSet;
import java.util.Iterator;
public class Test {
static enum EnumFoo {
a, b,
}
public static void main(String[] args){
EnumSetEnumFoo set = EnumSet.noneOf(EnumFoo.class);
set.add(EnumFoo.a);
IteratorEnumFoo iterator = set.iterator();
iterator.next();
set.remove(EnumFoo.a);
iterator.remove(); (1)
// The output value is true
System.out.println(set.contains(EnumFoo.a));
// The output value is 64
System.out.println(set.size());
}
}
IMHO, when (1) is executed, an IllegalStateException should be thrown
out, since the element EnumFoo.a does not exist at the moment.
Any thoughts?
Best regards
Not very familiar with Enumset, but I think it is strange behavior
caused by iterator
This test can pass on RI
void test{
EnumSetEnumFoo set = EnumSet.noneOf(EnumFoo.class);
set.add(EnumFoo.a);
assertTrue(set.size() == 1);
assertTrue(set.remove(EnumFoo.a));
assertTrue(set.size() == 0);
assertFalse(set.remove(EnumFoo.a));
assertFalse(set.contains(EnumFoo.a));
}
Without Iterator influence, the EnumSet behave well. I think better to
focus on how iterator works there.
--
Best Regards!
Jimmy, Jing Lv
China Software Development Lab, IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][instrument]Using Support_Exec framework(was Re: [classlib][Instrument] Documents for non-unit-tests)
Anton Luht wrote: IMHO analysis of exception stacktrace output is a bad idea. Tests should not produce uncatched exceptions unless they fail. Test authors should explicitly catch an exception and print some text to stdout. Reasons are: - exception messages are not standard, different JVMs can produce different output - localized messages can be printed, the test may fail because of locales - if test author expects IOException but subclass of this exception is thrown and printed, the test will fail while if the test was written in the way catch IOException; print PASSED the test would pass Ah, we are trying to catch the exact exception name, not its message. I agree parsing the message is a bad idea, but find an exact exception name in the output is still stable, am I right? In fact, I have no idea to catch an exception in exec, it surely contains no such function, right? On 8/16/06, Stepan Mishura [EMAIL PROTECTED] wrote: On 8/16/06, Anton Luht wrote: Cool idea - rethrow exceptions from exec'ed java :) You exec jvm that dies because some exception (say, NPE) not catched, support_exec analyzes output, understands that NPE was thrown and rethrows it :) People who will look at those tests will certainly go mad. You misunderstoond the idea for using support_exec - no exceptions re-throwing should be made. A test will verify only that VM fails in expected way (i.e. with expected error message). Do you have a better idea how to test that? Thanks, Stepan. On 8/16/06, Jimmy, Jing Lv [EMAIL PROTECTED] wrote: Paulex Yang wrote: Jimmy, Jing Lv wrote: Hi, I'm trying to write some unit tests of instrument. As discussed, I'm using exec. Currently I've tried Support_Exec and find it fairly easy to use(Thanks Stepan :) ). For resources (jar files and utility classes), I make a new directory: $Harmony/modules/instrument/src/test/resource/org/apache/harmony/tests/instrument and put them there. And I meet a problem here. Currently the default classpath in running test is $Harmony/modules/instrument/bin, so it meets problem in loading those utility classes (it can load jar files though). I remember Mark has plan to change the classpath in running testcase, it'll be great if he make some progress. An another problem is checking, currently the result is checked by searching and compare in string(e.g, find someException in result). But the framework seems fails if any exception is thrown out. Can it make a little change that it passes and returns the error message in exec? Didn't catch up here, did you mean that you need to check the exception message as well as exception type? Not necessary to check messages. However we can not catch those exceptions so we have to analysis output. For an example: run java -javaagent:test.jar myclass so get output: Exception in thread main java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at sun.instrument.InstrumentationImpl.loadClassAndCallPremain(Unknown So urce) Caused by: java.lang.IllegalAccessError ... In this case we can search for InvocationTargetException in the output to ensure the expected exception. Sometimes we may also check cause by exceptions. This approach seems not perfect. Any comments/suggestions? Thanks! snip -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM -- Thanks, Stepan Mishura Intel Middleware Products Division -- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[classlib][instrument]Using Support_Exec framework(was Re: [classlib][Instrument] Documents for non-unit-tests)
Hi, I'm trying to write some unit tests of instrument. As discussed, I'm using exec. Currently I've tried Support_Exec and find it fairly easy to use(Thanks Stepan :) ). For resources (jar files and utility classes), I make a new directory: $Harmony/modules/instrument/src/test/resource/org/apache/harmony/tests/instrument and put them there. And I meet a problem here. Currently the default classpath in running test is $Harmony/modules/instrument/bin, so it meets problem in loading those utility classes (it can load jar files though). I remember Mark has plan to change the classpath in running testcase, it'll be great if he make some progress. An another problem is checking, currently the result is checked by searching and compare in string(e.g, find someException in result). But the framework seems fails if any exception is thrown out. Can it make a little change that it passes and returns the error message in exec? Jimmy, Jing Lv wrote: Stepan Mishura wrote: On 8/7/06, *Jimmy, Jing Lv* wrote: SNIP Sounds pretty good :) exec do helps, it can check simple situations. What I'm concern is that if the return code is not enough for some situations, e.g, what exception is thrown exactly, or what cause VM exit abnormally. IMHO, it is still necessary for us. Hi Jimmy, See attached test. It demonstrates VM forking. The test saves VM output and prints it in the end. So I expect that unit tests for 'instrument' module can do the same: fork VM with predefined args, save output and compare it with expected output. BWT, we have utility class[1] in 'support' for this task. It makes sense to improve it for our needs. Thanks, Stepan. Thanks Stepan, this is very attractive to me :) According to your approach, I believe now it can be automatized well, at least for many test. One concern from me is that, how do you handle output comparison? For an example, if VM halt with a exception, it output some message, so you get the output, find the exception name in it? And what can we do if it output some information only, which RI and Harmony may not appear the same? However this is a good idea, if no objections, I shall follow this approach in writing some test of instrument. [1] http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/support/src/test/java/tests/support/Support_Exec.java?revision=386058view=markup http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/support/src/test/java/tests/support/Support_Exec.java?revision=386058view=markup -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][instrument]Using Support_Exec framework(was Re: [classlib][Instrument] Documents for non-unit-tests)
Paulex Yang wrote: Jimmy, Jing Lv wrote: Hi, I'm trying to write some unit tests of instrument. As discussed, I'm using exec. Currently I've tried Support_Exec and find it fairly easy to use(Thanks Stepan :) ). For resources (jar files and utility classes), I make a new directory: $Harmony/modules/instrument/src/test/resource/org/apache/harmony/tests/instrument and put them there. And I meet a problem here. Currently the default classpath in running test is $Harmony/modules/instrument/bin, so it meets problem in loading those utility classes (it can load jar files though). I remember Mark has plan to change the classpath in running testcase, it'll be great if he make some progress. An another problem is checking, currently the result is checked by searching and compare in string(e.g, find someException in result). But the framework seems fails if any exception is thrown out. Can it make a little change that it passes and returns the error message in exec? Didn't catch up here, did you mean that you need to check the exception message as well as exception type? Not necessary to check messages. However we can not catch those exceptions so we have to analysis output. For an example: run java -javaagent:test.jar myclass so get output: Exception in thread main java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at sun.instrument.InstrumentationImpl.loadClassAndCallPremain(Unknown So urce) Caused by: java.lang.IllegalAccessError ... In this case we can search for InvocationTargetException in the output to ensure the expected exception. Sometimes we may also check cause by exceptions. This approach seems not perfect. Any comments/suggestions? Thanks! snip -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DRLVM][JNI]GetByteArrayRegion differs from RI (was Re: Exceptions found while running servlet...)
Gregory Shimansky wrote:
On Monday 14 August 2006 23:37 Geir Magnusson Jr wrote:
I've written a test [1] myself and cannot say I completely understand the
result. With length = 0 RI 1.5 allows calling to GettypeArrayRegion
with start equal to array length but throws AIOOBE if start is greater
than array length.
That makes sense to me, only because I am thinking of j.i.OutputStream's
write([], int, int) method, which does state that it's ok if start + len
== arraylen...
It is not specified either, is it? I looked at the
ObjectOutputStream.write(byte[], int, int) and didn't find any detailed
description about allowed ranges.
I'm sure if we thought about it, we'd figure out that it lends itself
nicely to some common loop idiom. I suspect it will be some end case
when some read returns an empty buffer, so
write(buf, 0, 0)
works without a check, or some situation where there's some post
decrement leading you to
write(buf, length, len)
where the len was calculated from (buf.length - length) or something.
Now, that isn't what the JNI spec says, but it seems like the JNI spec
was written in a hurry... :)
JNI spec is indeed quite incomplete when it comes to border cases. Sun
wouldn't need to create a special book [1] (however this clarification
doesn't clarify this particular case) for JNI clarification if they wrote a
complete spec from the start.
However Sun usually changes a spec if its implementation doesn't work
according to it for some time. JNI spec is really old, it was written for 1.1
and the statement about exception still remains.
Hi,
IMHO our Compatibility guidelines, if the spec is not clear, we
should follow RI. So no matter what happens to the spec(unless it
describe the detail condition of exception-thrown), it is still OK to
follow RI here, am I right?
I am unsure if we want to allow this compatibility and a reason to allow
it. When length is 0 the application still gets nothing except for clear
exception status. There is no value in allowing this call except for
allowing software which has a bug in it to work. On the other hand
allowing start == length to pass violates the spec IMHO.
I think it is better if software which uses this undocumented feature was
fixed instead of introducing this workaround, so if others agree I think
HARMONY-1156 could be closed.
Well, I don't feel strongly either way, but am uncomfortable with the
inconsistency. The JNI docs seem pretty sparse, and clearly some
thought went into allowing :
write( buff, buff.length, 0)
The whole exception condition looks like this
jsize length = GetArrayLength(env, array);
jsize end = start + len;
if(start 0 || start = length || end 0 || end length) {
char msg[30];
sprintf(msg, %d..%d, start, end);
ThrowNew_Quick(env, java/lang/ArrayIndexOutOfBoundsException, msg);
return;
}
and it is easy to change start = length to start length if you ask for it.
IMHO there's something wrong here. What will it do if len0 and length
start+len 0 ? Shall it be:
if(start 0 || start length || len 0 || end length)?
And the next line shall be like:
if (0 == len){
return;
}
I am still unsure if this is a place where spec should step away from the
spec be it imcomplete or not. Programmers who don't work for Sun read public
spec, don't they?
[1] http://java.sun.com/docs/books/jni/html/jniTOC.html
Still we should follow our Compatibility guidelines, right(For our goal
of Harmony)? :)
--
Best Regards!
Jimmy, Jing Lv
China Software Development Lab, IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][luni] Problem with java.io.OutputStream
Geir Magnusson Jr wrote:
When looking at HARMONY-1156, it became clear that our
java.io.OutputStream isn't right.
I'd like to make the following changes :
Follow the spec so that an IndexOOBE is thrown when :
a) offset is negative or
b) len is negative or
c) off + len buff.length
So in the case of
write( byte[count], count, 0);
for any value of count = 0, then none of the conditions are true, and
it should simply [quickly] return.
Now, the spec says that if the array is null, then a NPE should be
thrown, but this doesn't happen in the RI when len = 0.
This seems to be a reasonable thing to do, and therefore I think that we
should match the RI here, and not the spec.
Comments?
Hi Geir,
Sorry I don't catch well here. I write a test[1], extends
OutputStream and try passing a null byte and len = 0, RI and Harmony
both throw NPE(windows XP sp2, RI 1.5.06, the lastest Harmony,J9/DRLVM).
And HARMONY-1156 only asks if given write( byte[count], count, 0);
the write operation quickly returns. And we see it is better to fix in
JNI, am I right?
In fact, IMHO we are NOT breaking spec in return quickly as spec
does not tell clear what indexes in the region is not valid? :)
[1]
public void test_OutputStream () throws IOException {
try {
new MockOutputStream().write(null, 0, 0);
fail(should throw NPE);
} catch (NullPointerException e) {
// expected
}
}
class MockOutputStream extends OutputStream {
public void write(int oneByte) throws IOException {
throw new NotYetImplementedException();
}
}
geir
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Best Regards!
Jimmy, Jing Lv
China Software Development Lab, IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Where to run tests? (was Re: [classlib][support] Using new framework for testing serialization (was: ...)
Mark Hindess wrote:
On 10 August 2006 at 14:51, Stepan Mishura [EMAIL PROTECTED] wrote:
On 8/10/06, Jimmy, Jing Lv wrote:
Hi Stepan,
IMO, most ser file should be put into a certain directory, so
the the appropriate directory is always there.
I'd like to add a new method to the framework as:
public static void createGoldenFile(TestCase test,Object object)
throws IOException {
createGoldenFile(src/test/resources/serialization,test,object);
}
But if 'root' param is relative path them the generated
file is placed in 'bin' (i.e. module_root/bin/test).
folder. Am I right? So you have to move it by hands anyway to
module_root/src/test/resources/serialization folder.
I was thinking about this. Currently all of the relative paths in
modules/name/build.xml are relative to modules/name, except those
on test invocations which are relative to modules/name/bin/test.
IMHO, this is slightly confusing for instance in the security module,
For example, modules/security/build.xml sets the classpath (in ant) to include
../../build/tests when running the api tests, but when running the
api injected tests it appends ../../../../build/tests to the
bootclasspath (using -X vm argument).
I think ant should just run tests in modules/name.
(I didn't realise that eclipse already ran the tests for there or I'd
probably have suggested it earlier.)
Great idea! :)
So Stepan will not object my method of createGolden, right? ;)
Regards,
Mark.
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Best Regards!
Jimmy, Jing Lv
China Software Development Lab, IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Exceptions found while running servlet...
Martin Cordova wrote:
Is it OK to send this type of feedback to the list? please let me know
if not, and what subject conventions should I use (is there a link
about this?). I am not a Harmony developer, just a new user, I can
only provide feedback from my tests.
Welcome! I think everyone here is eager to see Harmony works with some
real projects well :)
I am running a small webapp, using Winstone servlet engine and IBM JDK
1.4.2 SP4 on WinXP SP2. Runs fine. I switched to Harmony JRE (aug-4),
and found these exceptions:
1.- I see this error while using servlet includes and also at the end
of some pages:
java.lang.ArrayIndexOutOfBoundsException: 0..0 at
org.apache.harmony.luni.platform.OSNetworkSystem.sendStreamImpl(OSNetworkSystem.java)
at
org.apache.harmony.luni.platform.OSNetworkSystem.sendStream(OSNetworkSystem.java:194)
at
org.apache.harmony.luni.net.PlainSocketImpl.write(PlainSocketImpl.java:647)
at
org.apache.harmony.luni.net.SocketOutputStream.write(SocketOutputStream.java:89)
at winstone.WinstoneOutputStream.commit(WinstoneOutputStream.java:152)
at winstone.WinstoneOutputStream.flush(WinstoneOutputStream.java:189)
at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:176) at
java.io.OutputStreamWriter.convert(OutputStreamWriter.java:240) at
java.io.OutputStreamWriter.write(OutputStreamWriter.java:228) at
java.io.PrintWriter.doWrite(PrintWriter.java:640) at
java.io.PrintWriter.write(PrintWriter.java:622) at
winstone.WinstoneResponseWriter.write(WinstoneResponseWriter.java:45)
at java.io.PrintWriter.write(PrintWriter.java:607) at
java.io.PrintWriter.write(PrintWriter.java:657) at
java.io.PrintWriter.print(PrintWriter.java:455) at
I've looked into this, I feel puzzled, the stack trace shows that:
org.apache.harmony.luni.net.SocketOutputStream.write(SocketOutputStream.java:89)
but there are checks for overflow:
if (0 = offset offset = buffer.length 0 = count
count = buffer.length - offset){
...
}
So can you give more information? e.g, what are PrintWriter try to write
that time? :)
2.- Trying to generate charts using JFreeCharts (server-side):
java.lang.NoClassDefFoundError: org/apache/harmony/awt/gl/ImageSurface
at
java.awt.image.BufferedImage.createImageSurface(BufferedImage.java:659)
at java.awt.image.BufferedImage.init(BufferedImage.java:352)
at org.jfree.chart.JFreeChart.createBufferedImage(JFreeChart.java:1211)
at org.jfree.chart.JFreeChart.createBufferedImage(JFreeChart.java:1193)
at
org.jfree.chart.JFreeChart.createBufferedImage(JFreeChart.java:1178)...
The JDBC related code is running fine, performance also looks very good.
I will contact Winstone developer to see if he can help in some way to
identify the problem. He already helped me a few months ago to help
identify a bug in GNU Classpath server socket API.
Regards,
Martin
--
Best Regards!
Jimmy, Jing Lv
China Software Development Lab, IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][support] Using new framework for testing serialization (was: Re: [jira] Updated: (HARMONY-1098) [classlib][instrument]Add tests for UnmodifiableClassException and IllegalClassFormatExce
Stepan Mishura wrote:
snip
BufferOverflowException());
But then you have to move generated file to the appropriate place by
hands.
Is this convenient?
Hi Stepan,
IMO, most ser file should be put into a certain directory, so the
the appropriate directory is always there.
I'd like to add a new method to the framework as:
public static void createGoldenFile(TestCase test,Object object)
throws IOException {
createGoldenFile(src/test/resources/serialization,test,object);
}
But if 'root' param is relative path them the generated file is placed in
'bin' (i.e. module_root/bin/test). folder. Am I right? So you have to
move it by hands anyway to module_root/src/test/resources/serialization
folder.
Ah sorry, I only test it on eclipse. Yes, if run on ant, it would
properly be module_root/bin/test.
IMO, mostly, people write code and create file once (for me, on
eclipse), so it is still a convenience if the framework offer such method.
And for people who use ant to run test, still can offer a method for
that, e.g.
public static void createGoldenFileUsingAnt(TestCase test,Object object)
throws IOException {
createGoldenFile(../../src/test/resources/serialization,test,object);
}
Am I right? Thanks! :)
Thanks,
Stepan.
I have tried the new method, and it works well :)
Can I or would you please make a patch for it? Thanks! :)
snip
Thanks,
Stepan Mishura
Intel Middleware Products Division
--
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Best Regards!
Jimmy, Jing Lv
China Software Development Lab, IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][instrument]Method to terminate VM.
Leo Li wrote: Hi, all During the implementaion of instrument, I encounter the choice about how to terminate the VM when some abnormal event occurs, for example, the expected jar file does not exist or the implementation class of Instrumentation cannot be found. The most simple and direct way is just to call exit(), and then the whole process will terminate. Hence OS will treat with all the release of resources. However, I propose to use FatalError of JNI instead, which notifies the VM to suicide, because it gives right to the implementation of VM to take charge of its own funeral affairs, which might include, for example, logging the cause of its crash. Any suggestion from VM guys? Thanks :) Hi, I agree that use VM FatalError is better than system exit(). If no objections, I will make code that way. -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[DRLVM][JNI]GetByteArrayRegion differs from RI (was Re: Exceptions found while running servlet...)
Hi,
As discussed in the former thread, I find that a JNI of DRLVM
(GetByteArrayRegion) differs from RI in passing parameter
(byte[count],count,0). RI (and J9 VM) returns immediately but DRLVM
throws an ArrayIndexOutOfBoundsException.
IMHO, it is better to improve here, make it follow RI, as JNI is
also a part of API, and users may use it. So if no objections, shall I
or someone raise a JIRA for this?
I don't know if Martin is urgent in using Harmony in Winstone
servlet engine (Martin, can you read this?), so shall I work around in
java code before we have conclusion?
Any comments/suggestions from DRLVM guys? Thanks!
Jimmy, Jing Lv wrote:
Jimmy, Jing Lv wrote:
snip
I do some further study and test then, and find the problem was not so
easy.
Alex and I are correct that offset = buffer.length here is wrong,
but the next count = buffer.length - offset seems has proved its
correctness.
I have a test[1], try to write(new byte[count],count, 0) to a
SocketOutputStream, the test passes quietly. I do this test on WinXp
Sp2, the latest Harmony workspace, with J9 VM5.
I believe the ArrayIndexOutOfBoundsException is throw out when it try
to get byte array in the native (GetByteArrayRegion), which is a JNI
method. I guess there may be some difference between VMs.
Martin, are you using DRLVM? Can someone using DRLVM (or other VMs)
run the test below on DRLVM for me? Thanks!
[1]
public void test_socketOutputStream() throws Exception {
ServerSocket ss = new ServerSocket(0);
Socket sock = new Socket();
sock.connect(new InetSocketAddress
(InetAddress.getLocalHost(),ss.getLocalPort()));
ss.accept();
OutputStream os = sock.getOutputStream();
os.write(new byte[0], 0, 0); // passes here
os.write(new byte[512], 512, 0); // passes here
}
Hi,
At last I have test[1] JNI method(GetByteArrayRegion) of RI (before
dinner, very hungry... :) )
The result is that, RI return successfully if the given offset
equals length of the byte array, and the given count is zero.
Thus IMHO it is better to improve DRLVM to follow RI, as JNI methods
are also API methods, users may use it.
Shall we raise a JIRA for DRLVM? Any comments/suggestions from DRLVM
guys? Thanks!
Time for dinner! :D
[1]
test.java
--
class test
{
static{
System.loadLibrary(testjni);
}
private native void testjni(byte[] bs);
public void usejni(){
testjni(new byte[512]);
}
public static void main(String args[]){
new test().usejni();
}
}
---
test.h
---
/* DO NOT EDIT THIS FILE - it is machine generated */
#include jni.h
/* Header for class test */
#ifndef _Included_test
#define _Included_test
#ifdef __cplusplus
extern C {
#endif
/*
* Class: test
* Method:testjni
* Signature: ([B)V
*/
JNIEXPORT void JNICALL Java_test_testjni
(JNIEnv *, jobject, jbyteArray);
#ifdef __cplusplus
}
#endif
#endif
--
test.c
--
#include test.h
JNIEXPORT void JNICALL Java_test_testjni
(JNIEnv * env, jobject obj,jbyteArray array){
jbyte* buf = (jbyte*)malloc(sizeof(jbyte)*512);
(*env)-GetByteArrayRegion(env,array,512, 0, buf);
}
(magic number 512 can be any integer, including zero)
snip
--
Best Regards!
Jimmy, Jing Lv
China Software Development Lab, IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][support] Using new framework for testing serialization (was: Re: [jira] Updated: (HARMONY-1098) [classlib][instrument]Add tests for UnmodifiableClassException and IllegalClassFormatExce
Stepan Mishura wrote:
On 8/10/06, Jimmy, Jing Lv wrote:
Stepan Mishura wrote:
snip
BufferOverflowException());
But then you have to move generated file to the appropriate place by
hands.
Is this convenient?
Hi Stepan,
IMO, most ser file should be put into a certain directory, so the
the appropriate directory is always there.
I'd like to add a new method to the framework as:
public static void createGoldenFile(TestCase test,Object object)
throws IOException {
createGoldenFile(src/test/resources/serialization,test,object);
}
But if 'root' param is relative path them the generated file is placed
in
'bin' (i.e. module_root/bin/test). folder. Am I right? So you
have to
move it by hands anyway to
module_root/src/test/resources/serialization
folder.
Ah sorry, I only test it on eclipse. Yes, if run on ant, it would
properly be module_root/bin/test.
IMO, mostly, people write code and create file once (for me, on
eclipse), so it is still a convenience if the framework offer such
method.
And for people who use ant to run test, still can offer a method for
that, e.g.
public static void createGoldenFileUsingAnt(TestCase test,Object object)
throws IOException {
createGoldenFile(../../src/test/resources/serialization,test,object);
}
Am I right? Thanks! :)
IMHO the framework shouldn't contain methods that work for selected tool
only.
OK, I'm fine with it (I shall make one on my own workspace :) ).
So I'll make a new patch for Harmony-1098 according to new framework.
Thanks,
Stepan.
--
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Best Regards!
Jimmy, Jing Lv
China Software Development Lab, IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: New IBM VME available soon
Oliver Deakin wrote: Hi all, I'm pleased to announce that a new 5.0 level IBM VME will be made available soon at: http://www-128.ibm.com/developerworks/java/jdk/harmony/index.html The new VME downloads are named Harmony-vme-win.IA32-v4.zip and Harmony-vme-linux.IA32-v4.tar.gz. I would like to stress that if you download these packages now, they will *not* work with the class library code currently in Harmony Subversion. I have created a new JIRA (HARMONY-1084) containing patches for Harmony classlib and the Eclipse Harmony plugin which are required to be able to use the new VME. The patches make the following changes: - Change Java build target from jsr14 to 1.5 :) - Change the bootclasspath system property name from com.ibm.oti.system.class.path to org.apache.harmony.boot.class.path - Create a new org.apache.harmony.luni.platform.Environment class that contains two (currently stubbed) getenv() methods. Once these methods are implemented, VM writers will be able to redirect System.getenv() calls to this class. - Rename clearvm.dll/libclearvm.so to harmonyvm.dll/libharmonyvm.so, and update the launchers reference to this library. - Rename clearvm.properties to harmonyvm.properties, and update the Eclipse plugin to find this file. - Update tests.api.java.lang.reflect.ArrayTest and tests.api.java.lang.ThreadGroupTest to reflect changes between 1.4 and 5.0 behaviour. Once the classlib patch has been applied, you will need to download the new VME in order to continue developing with the IBM VM. The previous version of the VME will no longer be compatible. I will send out a further mail when the new VME is available to download and use. Regards, Oliver Great! :) Eager to hear sounds of testNG :) -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][Instrument] Documents for non-unit-tests (was Re:[classlib] Plan on work on java.lang.instrument)
Stepan Mishura wrote:
On 8/7/06, *Jimmy, Jing Lv* wrote:
SNIP
Sounds pretty good :)
exec do helps, it can check simple situations.
What I'm concern is that if the return code is not enough for some
situations, e.g, what exception is thrown exactly, or what cause VM exit
abnormally. IMHO, it is still necessary for us.
Hi Jimmy,
See attached test. It demonstrates VM forking. The test saves VM
output and prints it in the end.
So I expect that unit tests for 'instrument' module can do the same:
fork VM with predefined args, save output and compare it with expected
output.
BWT, we have utility class[1] in 'support' for this task. It makes sense
to improve it for our needs.
Thanks,
Stepan.
Thanks Stepan, this is very attractive to me :)
According to your approach, I believe now it can be automatized well, at
least for many test.
One concern from me is that, how do you handle output comparison? For an
example, if VM halt with a exception, it output some message, so you get
the output, find the exception name in it? And what can we do if it
output some information only, which RI and Harmony may not appear the same?
However this is a good idea, if no objections, I shall follow this
approach in writing some test of instrument.
[1]
http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/support/src/test/java/tests/support/Support_Exec.java?revision=386058view=markup
http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/support/src/test/java/tests/support/Support_Exec.java?revision=386058view=markup
On 8/7/06, Jimmy, Jing Lv [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
Geir Magnusson Jr wrote:
Jimmy, Jing Lv wrote:
Richard Liang wrote:
Jimmy, Jing Lv wrote:
Hi,
As it is hard to write unit test for package
instrument, I now
have an idea: write down some documents for details of
non-unit test
cases for instrument. The detail of such test cases contain:
Do you mean it's hard to *write* unit test or it's hard to
integrate
the tests with Harmony build system?
Hard to write unit test, so record them in some document may be a
better
way :)
Why is it hard to create unit tests?
To test java.lang.instrument, mostly we need to start up a new
VM to see
its behavior. Its function(premain, etc) may be run before most
classes
loaded, and almost all exceptions will cause VM abort. And the
result is
hard to be checked automatic. What's more, extra java/c code is
needed
for the test.
One thought was that we can use exec(java commands) in
junit(is that
OK to run exec in tests?), but how to check its output is still a
problem.
I'll put unit test if any, but I believe most necessary and
important
tests are non-unit tests.
1. The test run on which platform, including special
environment;
2. The test description;
3. How to run test (command line, etc.);
4. test result;
5. resource (or links) for tests, including c/java code for
test if
any.
I hope ensure the code quality in this way. Like unit
test, such
tests can be checked and re-run for regression, though
un-automatically.
And I'll put them in Harmony-wiki[1], and any
test-description is
welcome!. (Geir, I've found an advancement of wiki :) )
Any suggestions? :)
[1]http://wiki.apache.org/harmony/INSTRUMENT
Geir Magnusson Jr wrote:
Never appeal to me using a Wiki as an authority :) It's like
finding
something written in chalk on the sidewalk.
However, if you had pointed out
http://incubator.apache.org/harmony/auth_cont_quest.html
http://incubator.apache.org/harmony/auth_cont_quest.html
I'd have agreed w/o having the opportunity to make fun of
the Wiki.
So I agree :)
geir
--
Thanks,
Stepan Mishura
Intel Middleware Products Division
--
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
import java.io.*;
public class test {
public static void main(String []av) throws Exception {
Runtime r = Runtime.getRuntime();
String[] args = new String[3];
args[0] = System.getProperty(java.home) + /bin/java;
args[1] = -showversion;
args[2] = NoSuchClass;
Process proc = r.exec(args);
MyReader err = new
Re: [classlib][support] Using new framework for testing serialization (was: Re: [jira] Updated: (HARMONY-1098) [classlib][instrument]Add tests for UnmodifiableClassException and IllegalClassFormatExce
Stepan Mishura wrote:
Hi Jimmy,
I expect that we agreed to use new serialization framework for new tests.
But I see that people continue develop tests for serialization using the
old
framework (i.e. SerializationTester).
Could you tell me why you prefer the old framework? Is the new framework
for
testing serialization complex, hard-to-use, bad documented or something
else?
Thank you in advance for your feedback,
Stepan.
Hi Stepan,
Perhaps people are all lazy... (just kidding :P)
In fact, I've try the new framework already some days ago, I find
two problems:
1. I find no method to make the ser file, as you know, in old
framework, if no such file was found, it will create one at once, that
was easy for us to put the file to the proper directory and run again,
this time the test passes successfully. To me, write test once, run
twice, only in two minutes I finish the testing, that was nice :)
2. Perhaps this is my mistake, I write a test[1], though I put ser
file to the directory (e.g,
src/tset/resource/serialization/org/apache/harmony/tests/java/lang/instrument),
the new framework fails to load the file. I've debug into the code, find
the path name correct, but the classloader load null(on eclipse 3.2,
winxp). After that I thought the framework may be still on progress and
not ready yet, so I give up and go on with the old one.
Please correct me if I misuse the new framework.
However I shall agree to use the new framework if no more problem
exists. Indeed the new framework looks good to me :) And the effort to
change test code is not heavy then.
[1]
public void test_compatibilitySerialization() throws Exception {
SerializationTest.verifyGolden(this, new
llegalClassFormatException());
}
On 8/8/06, Jimmy, Jing Lv (JIRA) [EMAIL PROTECTED] wrote:
[ http://issues.apache.org/jira/browse/HARMONY-1098?page=all ]
Jimmy, Jing Lv updated HARMONY-1098:
Attachment: instrument_patch.zip
Hi,
Would you please try my patch?
Please decompress to module\instrument, and run
module\instrument\instrument_patch\filecp.sh
Thanks!
Best regards,
Jimmy
[classlib][instrument]Add tests for UnmodifiableClassException and
IllegalClassFormatException
--
Key: HARMONY-1098
URL: http://issues.apache.org/jira/browse/HARMONY-1098
Project: Harmony
Issue Type: Improvement
Components: Classlib
Reporter: Jimmy, Jing Lv
Attachments: instrument_patch.zip
Add serialization tests for UnmodifiableClassException and
IllegalClassFormatException.
--
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
--
Best Regards!
Jimmy, Jing Lv
China Software Development Lab, IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][Instrument] Documents for non-unit-tests (was Re:[classlib] Plan on work on java.lang.instrument)
Paulex Yang wrote: Jimmy, Jing Lv wrote: Hi, As it is hard to write unit test for package instrument, I now have an idea: write down some documents for details of non-unit test cases for instrument. The detail of such test cases contain: 1. The test run on which platform, including special environment; 2. The test description; 3. How to run test (command line, etc.); 4. test result; 5. resource (or links) for tests, including c/java code for test if any. I hope ensure the code quality in this way. Like unit test, such tests can be checked and re-run for regression, though un-automatically. You mean these tests' result need to be checked manually? I think it is not acceptable. IIUC, the issue here is some instrument agent needs to be specified in JVM args, so these tests are somthing that need special startup configuration, we can find a way to handle these tests, say, specify the configuration in instrument's build.xml, we can even fork a new JVM process per these tests, (Not sure if TestNG has any special support for this?). Sorry I did not explain myself very well. Some of the tests for instrument, IMO, can not be test automatic well. However, other tests of instrument can be certainly written into unit test, or check automatic. The main difference between the tests of instrument and other modules is that it should raise a new VM to run. I believe it can be controlled by ant or something. Most happy paths can be checked automatic, e.g, check if the certain class has been transformed, the size of the object is correct, etc. However, there are still lots of things that can not be checked well: VM crashes, exceptions, and special output by VM, etc. These documented and undocumented behavior should be checked carefully, but is not easy for automatization as I have explained. Only in this situation shall I take action to document them down as tests. After all, any suggestion on these special tests are welcome. I hope we can find out a way to deal these issue without documents, but with an automatic mechanism. And I'll put them in Harmony-wiki[1], and any test-description is welcome!. (Geir, I've found an advancement of wiki :) ) Any suggestions? :) [1]http://wiki.apache.org/harmony/INSTRUMENT Geir Magnusson Jr wrote: Never appeal to me using a Wiki as an authority :) It's like finding something written in chalk on the sidewalk. However, if you had pointed out http://incubator.apache.org/harmony/auth_cont_quest.html I'd have agreed w/o having the opportunity to make fun of the Wiki. So I agree :) geir -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][Instrument] Documents for non-unit-tests (was Re:[classlib] Plan on work on java.lang.instrument)
Leo Li wrote:
Hi, all:
I have some idea to test instrument.
For example, if we would like to test
Instrumentation.addTransformerwill throw NullPointerException if the
argument is null,
we can first write a TestInstrument with premain function.
import java.lang.instrument.Instrumentation;
public class TestInstrument {
public static void premain(String agentArgs, Instrumentation inst)
{
try
{
inst.addTransformer(null);
}
catch(NullPointerException e)
{
//failed, we set error code
System.exit(1);
}
}
}
Normally, the VM will exit with zero as it return value if there is no
exception occurs in main class.
then, we might write an JUnit Test:
public void test() throws Exception
{
Process process = Runtime.getRuntime().exec(java -javaagent
Test.jarTest);
//if premain runs as we expected, the exit code is zero.
assertEquals(0,process.waitFor());
}
(Besides,Test is an ordinary class with a main function that will not throw
error. Test.jar with the manifest to denote the class of TestInstrument as
the premain class.}
Is it all right? :)
Sounds pretty good :)
exec do helps, it can check simple situations.
What I'm concern is that if the return code is not enough for some
situations, e.g, what exception is thrown exactly, or what cause VM exit
abnormally. IMHO, it is still necessary for us.
On 8/7/06, Jimmy, Jing Lv [EMAIL PROTECTED] wrote:
Geir Magnusson Jr wrote:
Jimmy, Jing Lv wrote:
Richard Liang wrote:
Jimmy, Jing Lv wrote:
Hi,
As it is hard to write unit test for package instrument, I now
have an idea: write down some documents for details of non-unit test
cases for instrument. The detail of such test cases contain:
Do you mean it's hard to *write* unit test or it's hard to integrate
the tests with Harmony build system?
Hard to write unit test, so record them in some document may be a
better
way :)
Why is it hard to create unit tests?
To test java.lang.instrument, mostly we need to start up a new VM to see
its behavior. Its function(premain, etc) may be run before most classes
loaded, and almost all exceptions will cause VM abort. And the result is
hard to be checked automatic. What's more, extra java/c code is needed
for the test.
One thought was that we can use exec(java commands) in junit(is that
OK to run exec in tests?), but how to check its output is still a
problem.
I'll put unit test if any, but I believe most necessary and important
tests are non-unit tests.
1. The test run on which platform, including special environment;
2. The test description;
3. How to run test (command line, etc.);
4. test result;
5. resource (or links) for tests, including c/java code for test if
any.
I hope ensure the code quality in this way. Like unit test, such
tests can be checked and re-run for regression, though
un-automatically.
And I'll put them in Harmony-wiki[1], and any
test-description is
welcome!. (Geir, I've found an advancement of wiki :) )
Any suggestions? :)
[1]http://wiki.apache.org/harmony/INSTRUMENT
Geir Magnusson Jr wrote:
Never appeal to me using a Wiki as an authority :) It's like
finding
something written in chalk on the sidewalk.
However, if you had pointed out
http://incubator.apache.org/harmony/auth_cont_quest.html
I'd have agreed w/o having the opportunity to make fun of the Wiki.
So I agree :)
geir
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Best Regards!
Jimmy, Jing Lv
China Software Development Lab, IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Best Regards!
Jimmy, Jing Lv
China Software Development Lab, IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][Instrument] Documents for non-unit-tests (was Re:[classlib] Plan on work on java.lang.instrument)
Richard Liang wrote: Jimmy, Jing Lv wrote: Hi, As it is hard to write unit test for package instrument, I now have an idea: write down some documents for details of non-unit test cases for instrument. The detail of such test cases contain: Do you mean it's hard to *write* unit test or it's hard to integrate the tests with Harmony build system? Hard to write unit test, so record them in some document may be a better way :) 1. The test run on which platform, including special environment; 2. The test description; 3. How to run test (command line, etc.); 4. test result; 5. resource (or links) for tests, including c/java code for test if any. I hope ensure the code quality in this way. Like unit test, such tests can be checked and re-run for regression, though un-automatically. And I'll put them in Harmony-wiki[1], and any test-description is welcome!. (Geir, I've found an advancement of wiki :) ) Any suggestions? :) [1]http://wiki.apache.org/harmony/INSTRUMENT Geir Magnusson Jr wrote: Never appeal to me using a Wiki as an authority :) It's like finding something written in chalk on the sidewalk. However, if you had pointed out http://incubator.apache.org/harmony/auth_cont_quest.html I'd have agreed w/o having the opportunity to make fun of the Wiki. So I agree :) geir -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][Instrument] Documents for non-unit-tests (was Re:[classlib] Plan on work on java.lang.instrument)
Richard Liang wrote: Jimmy, Jing Lv wrote: Richard Liang wrote: Jimmy, Jing Lv wrote: Hi, As it is hard to write unit test for package instrument, I now have an idea: write down some documents for details of non-unit test cases for instrument. The detail of such test cases contain: Do you mean it's hard to *write* unit test or it's hard to integrate the tests with Harmony build system? Hard to write unit test, so record them in some document may be a better way :) Sounds reasonable :-) But what does the test mean in 3. How to run test (command line, etc.); ? Do you mean we will test instrument manually? Please correct me if I'm wrong. Thanks a lot. Yes, if no automatic way can be use to run the documented test, I guess we should setup environment, build java/c code, and run on command lines. In this way, such guide to these special test may be necessary. 1. The test run on which platform, including special environment; 2. The test description; 3. How to run test (command line, etc.); 4. test result; 5. resource (or links) for tests, including c/java code for test if any. I hope ensure the code quality in this way. Like unit test, such tests can be checked and re-run for regression, though un-automatically. And I'll put them in Harmony-wiki[1], and any test-description is welcome!. (Geir, I've found an advancement of wiki :) ) Any suggestions? :) [1]http://wiki.apache.org/harmony/INSTRUMENT Geir Magnusson Jr wrote: Never appeal to me using a Wiki as an authority :) It's like finding something written in chalk on the sidewalk. However, if you had pointed out http://incubator.apache.org/harmony/auth_cont_quest.html I'd have agreed w/o having the opportunity to make fun of the Wiki. So I agree :) geir -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][Instrument] Documents for non-unit-tests (was Re:[classlib] Plan on work on java.lang.instrument)
Geir Magnusson Jr wrote: Jimmy, Jing Lv wrote: Richard Liang wrote: Jimmy, Jing Lv wrote: Hi, As it is hard to write unit test for package instrument, I now have an idea: write down some documents for details of non-unit test cases for instrument. The detail of such test cases contain: Do you mean it's hard to *write* unit test or it's hard to integrate the tests with Harmony build system? Hard to write unit test, so record them in some document may be a better way :) Why is it hard to create unit tests? To test java.lang.instrument, mostly we need to start up a new VM to see its behavior. Its function(premain, etc) may be run before most classes loaded, and almost all exceptions will cause VM abort. And the result is hard to be checked automatic. What's more, extra java/c code is needed for the test. One thought was that we can use exec(java commands) in junit(is that OK to run exec in tests?), but how to check its output is still a problem. I'll put unit test if any, but I believe most necessary and important tests are non-unit tests. 1. The test run on which platform, including special environment; 2. The test description; 3. How to run test (command line, etc.); 4. test result; 5. resource (or links) for tests, including c/java code for test if any. I hope ensure the code quality in this way. Like unit test, such tests can be checked and re-run for regression, though un-automatically. And I'll put them in Harmony-wiki[1], and any test-description is welcome!. (Geir, I've found an advancement of wiki :) ) Any suggestions? :) [1]http://wiki.apache.org/harmony/INSTRUMENT Geir Magnusson Jr wrote: Never appeal to me using a Wiki as an authority :) It's like finding something written in chalk on the sidewalk. However, if you had pointed out http://incubator.apache.org/harmony/auth_cont_quest.html I'd have agreed w/o having the opportunity to make fun of the Wiki. So I agree :) geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[classlib][Instrument] Documents for non-unit-tests (was Re:[classlib] Plan on work on java.lang.instrument)
Hi, As it is hard to write unit test for package instrument, I now have an idea: write down some documents for details of non-unit test cases for instrument. The detail of such test cases contain: 1. The test run on which platform, including special environment; 2. The test description; 3. How to run test (command line, etc.); 4. test result; 5. resource (or links) for tests, including c/java code for test if any. I hope ensure the code quality in this way. Like unit test, such tests can be checked and re-run for regression, though un-automatically. And I'll put them in Harmony-wiki[1], and any test-description is welcome!. (Geir, I've found an advancement of wiki :) ) Any suggestions? :) [1]http://wiki.apache.org/harmony/INSTRUMENT Geir Magnusson Jr wrote: Never appeal to me using a Wiki as an authority :) It's like finding something written in chalk on the sidewalk. However, if you had pointed out http://incubator.apache.org/harmony/auth_cont_quest.html I'd have agreed w/o having the opportunity to make fun of the Wiki. So I agree :) geir -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] Plan on work on java.lang.instrument
Paulex Yang wrote: Gregory Shimansky wrote: On Wednesday 02 August 2006 17:30 Paulex Yang wrote: Alexey Varlamov wrote: [SNIP] For native codes, instrument need a new directory in modules/luni/src/main/native named instrument, in my plan, there should be two native code, one for instrument native implementation, and another for laugher (for parameter -javaagent). Instrument shall be compiled into a .DLL(.so) file alone. Jimmy, Could you please add some details on the launcher part? I'd rather think that common VM launcher should be updated to support -javaagent: option Agree, it should can be handled by common launcher. - which is basically a second class to launch. I think there is some difference, actually I expect it parses the parameters following -javaagent:, then converts it to -agentlib:hyinstrument.dll... and at last passes them to VM. I don't think there is any conversion required. I believe -javaagent is a VM option and should be handled internally by the invocation API in case there is a 3rd party launcher/plugin which tries to use VM's invocation API directly. The agent library may be even linked statically to VM and hidden from direct use on the command line. The agent library (instrument implementation) is implemented in classlib and is independent with VM, why it needs to be linked statically? Even RI, which seems don't think too much on the classlib/VM modulazation, has the instrument.dll separated. Considering 3rd party launcher, I agree that it is convenient to put the -javaagent parsing in VM directly, but then VM must be aware of the agent lib's name, though it may be fine because it is not likely for Harmony to change it frequently. Agreed with Paulex, at least it can be a convenient, VM guys can choose using it or not. So let's make it. :) On a side note, -agentlib specifies agent library in OS independent way so it should be -agentlib:hyinstrument=... Thanks for point it out, I actually meant the same thing. -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][nio-charset] RI is inconsistent with spec when loading charset provider
Paulex Yang wrote:
Andrew Zhang wrote:
Hi, all
Things are a little bit complex when I tried to implement this
workaround.
Consider availableCharsets() method from Charset.java, which loads
provider
classes from configuration file.
Please see my comments inline.
final ClassLoader cl = getContextClassLoader();
if (null != cl) { // what shall we do if context class loader is null?
try {
// context classloader is used to get resources.
Enumeration e = cl
.getResources(PROVIDER_CONFIGURATION_FILE_NAME);
// Examine each configuration file
while (e.hasMoreElements()) {
// here, context classloader is used to load class.
// If system classloader is used as backup when context classloader
fails to
load, it seems illogical, because it's context classloader who get
resources.
// It should be the same classloader who gets resources and loads
corresponding classes.
loadConfiguredCharsets((URL) e.nextElement(), cl, charsets);
}
} catch (IOException ex) {
// Unexpected ClassLoader exception, ignore
}
}
If we put another copy code after this section, using system
classloader
instead of context classloader, it also seems illogical. What shall
we do
if context classloader fails to load a provider charset class? Should it
throw an error as spec requires or pass silently?
Hmm... I think more serious problem here is that the classloader is used
not only to load the CharsetProvider class, but also to load the
configuration files, so if we choose to try context classloader then
system classloader, they may load different config files! IMHO, the
behavior will be contradict with both RI and spec. I suggest we give up
the *third way* and choose one(RI or spec) to follow, from others'
comments, Sun has been aware of this for long time, so they must have
reason not to fix the codes, maybe just because this is a not trivial
difference(it may be significant for server application which has multi
classloaders and special charsets), so I suggest we follow RI.
I notice some lines of spec of CharsetProvider:
in the end of Para 1, it reads clearly:
Charset providers are looked up via the current thread's context class
loader.
and in the Para 3, it reads:
The provider must be accessible from the same class loader that was
initially queried to locate the configuration file; this is *not*
necessarily the class loader that loaded the file.
Seems Spec says nothing about which classloader is used to locate
configuration file, but the tests has shown that it can be the system
classloader.
OK, then I think we can do like this:
use System Classloader to locate the configuration file, then use
thread's context class loader to load providers; if fails, use System
Classloader to load providers; if fails again, throw exception.
This shall not break following RI nor Spec because: 1. we has used
context class(follow spec Para1); 2. we use System Classloader to locate
configuration file, and the provider must be accessible to this
classloader or it will throw exception(follow spec Para3, the first
sentence); 3. spec never forbid us from using difference
classloader(spec Para3, the second sentence); 4. at last we use System
Classloader to load the provider if context classloader fails(we follow RI).
I feel very curious what does sun think about this problem. :) However
let's work around, waiting for RI to correct code, or correct spec.
To sum up, it's hard to follow RI, and comply with spec
simultaneously. We
have to choose one of them. Spec or RI?
I don't think RI would change its behaviour in later release. In fact,
the
bug still exists in SUN 6.0 rc version. Personally, +1 for following
RI.
Any comments or better suggestions?
Thanks!
--
Best Regards!
Jimmy, Jing Lv
China Software Development Lab, IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] Intention to work on java.lang.instrument
Leo Li wrote: On 7/31/06, Gregory Shimansky [EMAIL PROTECTED] wrote: 2006/7/31, Jimmy, Jing Lv [EMAIL PROTECTED]: Besides, Harmony VM now has actually support the feature of JVMTI on which we can implement instrument. Ah, can it work now? It'll be great convenient if so. Hello. The drlvm does support a subset of JVMTI. Class loading events are supported, ClassFileLoadHook which may be used for load time class instrumentation is supported too. But there is no support for RedefineClasses yet if you need to change classes bytecode after the class was loaded already. After some study on this, I find Java interface classes/interfaces are quite easy, but there should be real implement, both in java and native. And the native code requires JVMTI[2], which is a part of VM 5. Though, luckily we can still study and code according to JVMTI and test on RI. So my goal is : 1.define those simple Java classes/interfaces in Harmony; 2. work out implementation of java/native code according to JVMTI and make it run on RI; 3. wait for Harmony VM5 and then make some integration modification/test. As the main function of instruments is to add and remove transformers to some classes, I suggest implement it as an agent of JVMTI. That is to register callback functions, which actually transform the byte stream of some specified classes, to the events that is relevent to instrument in JVMTI including the class loading. Yes, that's the way. I agree with this approach. Do you know which API functions and events you will need for such agent? Thanks you Gregory :) Refer to JVMTI Functions doc[1], I think functions of Memory Management/Class/Capability is necessary. [1]http://java.sun.com/j2se/1.5.0/docs/guide/jvmti/jvmti.html#FunctionIndex Hi, we will need VM Initialization Event to run premain functions and Class File Load Hook Event for agents to instruct the existing class file. As to the jvmti API, we need RedefineClasses,GetObjectSize and Allocate. Besides, AddCapabilities is also required to turn on the capability of the VM, such as can_generate_all_class_hook_events and can_redefine_classes. That's detail, thanks :) Since we have just planned to implement this module, please excuse me if I leave some requirements about it. :) And for VM guys ,the launcher with parameter -javaagent:) -- Gregory Shimansky, Intel Middleware Products Division -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[classlib] Plan on work on java.lang.instrument
Hi, If no objection, I shall go on with the plan of instrument :) Refer to Harmony status page[1], INSTRUMENT is missing, so this module shall named as instrument. I shall open a wiki-page for its status like other modules on [2]. For Java codes, API classes/interfaces can be added to modules/luni/src/main/java/java/lang/instrument, and implementation can be added to modules/luni/src/main/java/org/apache/harmony/luni/internal/lang/instrument For native codes, instrument need a new directory in modules/luni/src/main/native named instrument, in my plan, there should be two native code, one for instrument native implementation, and another for laugher (for parameter -javaagent). Instrument shall be compiled into a .DLL(.so) file alone. Any suggestions? Thanks! :) [1]http://incubator.apache.org/harmony/subcomponents/classlibrary/status.html [2]http://wiki.apache.org/harmony/INSTRUMENT -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] Plan on work on java.lang.instrument
Stepan Mishura wrote: Yes, it is. But accoriding to [1] the code should be put into separate 'instrument' module. So the patch should start with 'modules/'instrument'. Ah ... you are right, thanks very much Stepan! :) So I shall put code to modules/ instrument/ src/main/java/java/lang/instrument Thanks, Stepan. [1]http://wiki.apache.org/harmony/componentization On 8/2/06, Geir Magnusson Jr wrote: It is a lang package, right? Stepan Mishura wrote: On 8/2/06, Jimmy, Jing Lv wrote: Hi, If no objection, I shall go on with the plan of instrument :) Refer to Harmony status page[1], INSTRUMENT is missing, so this module shall named as instrument. I shall open a wiki-page for its status like other modules on [2]. For Java codes, API classes/interfaces can be added to modules/luni/src/main/java/java/lang/instrument, and implementation can be added to modules/luni/src/main/java/org/apache/harmony/luni/internal/lang/instrument Sorry, I didn't catch why you are going to put code to 'luni' module Did you mean: modules/ instrument/ src/main/java/java/lang/instrument src/main/java/org/apache/harmony/luni/internal/lang/instrument Thanks, Stepan. For native codes, instrument need a new directory in modules/luni/src/main/native named instrument, in my plan, there should be two native code, one for instrument native implementation, and another for laugher (for parameter -javaagent). Instrument shall be compiled into a .DLL(.so) file alone. Any suggestions? Thanks! :) [1]http://incubator.apache.org/harmony/subcomponents/classlibrary/status.html [2]http://wiki.apache.org/harmony/INSTRUMENT -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] Plan on work on java.lang.instrument
Stepan Mishura wrote: On 8/2/06, Jimmy, Jing Lv wrote: Hi, If no objection, I shall go on with the plan of instrument :) Refer to Harmony status page[1], INSTRUMENT is missing, so this module shall named as instrument. I shall open a wiki-page for its status like other modules on [2]. For Java codes, API classes/interfaces can be added to modules/luni/src/main/java/java/lang/instrument, and implementation can be added to modules/luni/src/main/java/org/apache/harmony/luni/internal/lang/instrument Sorry, I didn't catch why you are going to put code to 'luni' module Did you mean: modules/ instrument/ src/main/java/java/lang/instrument src/main/java/org/apache/harmony/luni/internal/lang/instrument Hi, It is java.lang.instrument, so IMHO it can be put to luni module. And another reason is that it is rather small to be a single module. :) Thanks, Stepan. For native codes, instrument need a new directory in modules/luni/src/main/native named instrument, in my plan, there should be two native code, one for instrument native implementation, and another for laugher (for parameter -javaagent). Instrument shall be compiled into a .DLL(.so) file alone. Any suggestions? Thanks! :) [1]http://incubator.apache.org/harmony/subcomponents/classlibrary/status.html [2]http://wiki.apache.org/harmony/INSTRUMENT -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] Plan on work on java.lang.instrument
Jimmy, Jing Lv wrote: Stepan Mishura wrote: On 8/2/06, Jimmy, Jing Lv wrote: Hi, If no objection, I shall go on with the plan of instrument :) Refer to Harmony status page[1], INSTRUMENT is missing, so this module shall named as instrument. I shall open a wiki-page for its status like other modules on [2]. For Java codes, API classes/interfaces can be added to modules/luni/src/main/java/java/lang/instrument, and implementation can be added to modules/luni/src/main/java/org/apache/harmony/luni/internal/lang/instrument Sorry, I didn't catch why you are going to put code to 'luni' module Did you mean: modules/ instrument/ src/main/java/java/lang/instrument src/main/java/org/apache/harmony/luni/internal/lang/instrument Hi, It is java.lang.instrument, so IMHO it can be put to luni module. And another reason is that it is rather small to be a single module. :) Oops, my mail server meets some problem. Please ignore this letter, sorry for inconvenience. Thanks, Stepan. For native codes, instrument need a new directory in modules/luni/src/main/native named instrument, in my plan, there should be two native code, one for instrument native implementation, and another for laugher (for parameter -javaagent). Instrument shall be compiled into a .DLL(.so) file alone. Any suggestions? Thanks! :) [1]http://incubator.apache.org/harmony/subcomponents/classlibrary/status.html [2]http://wiki.apache.org/harmony/INSTRUMENT -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[classlib] Intention to work on java.lang.instrument
Hi everyone, Though Harmony VM 5 hasn't appeared yet(I hope it ready in the near further), I'd like to start work on an implementation of the java.lang.instrument[1]. After some study on this, I find Java interface classes/interfaces are quite easy, but there should be real implement, both in java and native. And the native code requires JVMTI[2], which is a part of VM 5. Though, luckily we can still study and code according to JVMTI and test on RI. So my goal is : 1.define those simple Java classes/interfaces in Harmony; 2. work out implementation of java/native code according to JVMTI and make it run on RI; 3. wait for Harmony VM5 and then make some integration modification/test. According to Harmony naming convention, I think the implementation class should be in org.apache.harmony.luni.internal.lang.instrument(a little too long, is it necessary to cut it shorter?). One problem is that it may have no suitable unit test for its implementation(except for some easy ones for exception class, etc), as all tests on this requires starting a VM to run. If I'm not wrong, I remember there's some of implementation also meet this problem, e.g, InheritedChannel. For this non-unit-testable implementation, shall Harmony contain some non-unit-test(some small application), or at least some document(How to use/test) to ensure its quality? Any comments and advices? Thanks! [1]http://java.sun.com/j2se/1.5.0/docs/api/java/lang/instrument/package-summary.html [2]http://java.sun.com/j2se/1.5.0/docs/guide/jvmti/jvmti.html -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] Intention to work on java.lang.instrument
Leo Li wrote: On 7/31/06, Jimmy, Jing Lv [EMAIL PROTECTED] wrote: Hi everyone, Though Harmony VM 5 hasn't appeared yet(I hope it ready in the near further), I'd like to start work on an implementation of the java.lang.instrument[1]. Hi, I am also interested in working on java.lang.instrument. Great! Welcome. :) Besides, Harmony VM now has actually support the feature of JVMTI on which we can implement instrument. Ah, can it work now? It'll be great convenient if so. After some study on this, I find Java interface classes/interfaces are quite easy, but there should be real implement, both in java and native. And the native code requires JVMTI[2], which is a part of VM 5. Though, luckily we can still study and code according to JVMTI and test on RI. So my goal is : 1.define those simple Java classes/interfaces in Harmony; 2. work out implementation of java/native code according to JVMTI and make it run on RI; 3. wait for Harmony VM5 and then make some integration modification/test. As the main function of instruments is to add and remove transformers to some classes, I suggest implement it as an agent of JVMTI. That is to register callback functions, which actually transform the byte stream of some specified classes, to the events that is relevent to instrument in JVMTI including the class loading. Yes, that's the way. According to Harmony naming convention, I think the implementation class should be in org.apache.harmony.luni.internal.lang.instrument(a little too long, is it necessary to cut it shorter?). One problem is that it may have no suitable unit test for its implementation(except for some easy ones for exception class, etc), as all tests on this requires starting a VM to run. If I'm not wrong, I remember there's some of implementation also meet this problem, e.g, InheritedChannel. For this non-unit-testable implementation, shall Harmony contain some non-unit-test(some small application), or at least some document(How to use/test) to ensure its quality? Ya, although we are able to test them both on RI and Harmony now, the testcases of instruments require lauch options of java VM, which lead to the difficult to add them to current Harmony testcases. Yes, Harmony launcher may also be modified (adding parameter for javaagent, etc). However I mean, without unit-test, shall Harmony have some other quality-assurance technique? Any comments and advices? Thanks! [1]http://java.sun.com/j2se/1.5.0/docs/api/java/lang/instrument/package- summary.html [2]http://java.sun.com/j2se/1.5.0/docs/guide/jvmti/jvmti.html -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] imcompatible with RI?
Mikhail Fursov wrote:
If API says (from the forst message message):
If this channel was not created by the same provider as the given
selector
then the way you create the channel but not provider is important.
?
Yes, I'd like to know the difference between channels created by
provider and contain the same provider. My only thought was that RI
may check stick if the class are written by their guys, e.g, see if they
have the same class package. However does it make sense?
I suggest Harmony keep it as it is until we have a meaningful idea about
this.
Any comments?
On 7/27/06, Andrew Zhang [EMAIL PROTECTED] wrote:
On 7/27/06, Paulex Yang [EMAIL PROTECTED] wrote:
Andrew Zhang wrote:
Seems strange.
Following test fails against RI.
The spec of SelectableChannel.register() says:
IllegalSelectorExceptoin
-- If this channel was not created by the same provider as the given
selector.
Same instance or same SelectorProvider subclass?
I think it's same instance. As you may notice, I use assertSame(
channel.provider(), selector.provider()); in the test.
RI passes this assert statement and fails at channel.register(...)
because
of IllegalSelectorException.
That's why I think RI is illogical in this case.
Any comments?
I suggest follow spec for this case. Thanks!
public void test_channel() throws Exception {
SelectorProvider provider = SelectorProvider.provider();
Selector selector = Selector.open();
MockChannel channel = new MockChannel(provider);
channel.configureBlocking(false);
assertSame(channel.provider(), selector.provider());
// test fails here against RI, IllegalSelectorException is thrown
channel.register(selector, SelectionKey.OP_READ);
selector.select();
}
class MockChannel extends SocketChannel {
protected MockChannel(SelectorProvider arg0) {
super(arg0);
}
public Socket socket() {
return null;
}
public boolean isConnected() {
return false;
}
public boolean isConnectionPending() {
return false;
}
public boolean connect(SocketAddress arg0) throws IOException {
return false;
}
public boolean finishConnect() throws IOException {
return false;
}
public int read(ByteBuffer arg0) throws IOException {
return 0;
}
public long read(ByteBuffer[] arg0, int arg1, int arg2) throws
IOException {
return 0;
}
public int write(ByteBuffer arg0) throws IOException {
return 0;
}
public long write(ByteBuffer[] arg0, int arg1, int arg2) throws
IOException {
return 0;
}
protected void implCloseSelectableChannel() throws IOException {
}
protected void implConfigureBlocking(boolean arg0) throws
IOException {
}
}
On 7/27/06, Jimmy, Jing Lv [EMAIL PROTECTED] wrote:
Hi:
I find that RI behaves strange in
java.nio.channels.SelectableChannel.register. in NIO, channels and
selector must be created by Provider. The doc reads: (Invoking
register() should throw) IllegalSelectorException - If this channel
was
not created by the same provider as the given selector. To check if
the
two providers are the same, Harmony use
if(selector.provider()==selector.provider)... , however it seems
not
correct.
If we mock a channel extends SelectableChannel, put the same
provider of selector as its provider, and register this channel to
selector, RI fails with a IllegalSelectorException though two
providers
are the same. I have no idea if how RI do without checking providers
are
the same?
Another thing is that if a selector has no channels register on
it,
invoke an operation of select() surely has nothing to do. In this
way,
Harmony returns immediately even invoking a block select(), however
RI
wait forever there, for nothing. I think Harmony's behavior is
logical,
but not compatible with RI. It seems a bug of RI, I suggest keep it
as
it is.
--
Best Regards!
Jimmy, Jing Lv
China Software Development Lab, IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
--
Paulex Yang
China Software Development Lab
IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Andrew Zhang
China Software Development Lab, IBM
--
Best Regards!
Jimmy, Jing Lv
China Software Development Lab, IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail
Re: [classLib]Given a long value, RI behaves differently on windows and linux (and TestNG?)
Mikhail Fursov wrote: The comments to this bug http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5105464 can give us some additional thoughts. As follows from this comment any (positive or negative) value could be if MAX_INTEGER is passed. So I propose not to follow RI here. The comment: Indeed, FileChannelImpl.transferFromArbitraryChannel casts a long value to an int, it gets a negative value if the long value is bigger than Integer.MAX_VALUE Hi, Thanks, Mikhail :) I read though that bug detail, but I think this is not the same thing we are talking about. That bug was caused by a long-to-integer-cast, Integer.MAX_VALUE + 1 is a integer value that is less than zero. The evaluation of that bug says: ... file.transferFrom(socket, 0, Integer.MAX_VALUE + 1); this is not correct, it should be: file.transferFrom(socket, 0, (long)Integer.MAX_VALUE + 1L); ... And it throws IllegalArgumentException. But in our topic, the IOException was caused by native operation. The question is, shall we modify native code/Harmony portlib to allow system-call deal with the long parameter itself, instead of dealing it in Harmony code? RI seems doing in this way. On 7/26/06, Jimmy, Jing Lv [EMAIL PROTECTED] wrote: Alexei Zakharov wrote: Hi, Is there any known real applications that use NIO for reading stuff with 4GB blocks? I've never heard of that. However, I believe there may be some in the future, or the operation system may support this. That's the reason I suggest Harmony use system call to solve the problem, not cut long to a integer in Harmony's Java or native code. Currently the problem is that the portlib has ignored the difference between Linux and windows, so we see no difference in Harmony, while RI behaves differently. And again, any sounds for TestNG? :) Regards, 2006/7/25, Leo Li [EMAIL PROTECTED]: 2006/7/25, Jimmy, Jing Lv [EMAIL PROTECTED]: Hi: I find another platform-dependent operation FileChannel.transforFrom(ReadableByteChannel src, long position, long count) in java.nio.channels. RI behaves differently if the given count is larger than Integer.MAX_VALUE: on windows, it throws an IOException; on Linux, it return zero silently. It is clear that the difference is caused by system call. Unfortunately Harmony fails to behave like RI as its has the same native code using the port-lib. If it is necessary to make Harmony behaving exactly like RI, I suggest writing native code for transforFrom. This may be a waste-of-effect as it is nearly the same except for this little difference.However, currently people have few chances to use a size larger than Integer.MAX_VALUE(nearly 4G, is it?), and system call does not support long value to pass in. Another thing I'd like to mention is that it'll be great if we can use testNG, or decide some other way to go. At least 2 testcases should be written for different platform as I remember, including the one for this problem. :) -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Dear Jimmy: As spec is not clear about how to deal with the argument greater than Integer.MAX_VALUE, maybe we shall look more closely at what RI does and how the system call behaves. I think it will be a good idea to let native code or even system call itself treat with such affairs, provided that Harmony will support some 64-bit platforms one day. Thus it may be not so wise to throw some exception in java code if encountering the data longer than 32-bits. Besides, whether we should behaves the same as RI, even if it is different on different platforms? :) -- Leo Li China Software Development Lab, IBM -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib]strings externalization
Andrew Zhang wrote: On 7/27/06, Tim Ellison [EMAIL PROTECTED] wrote: Ilya Okomin wrote: On 7/27/06, Tim Ellison [EMAIL PROTECTED] wrote: The other reason we will need some manual intervention is that there is plenty of code that throws exceptions without any message describing the problem, and of course the tooling won't help there. Tim, do you mean, that Exceptions without any messages supposed to be initialized with some corresponding message describing the problem? I thought only already existing in modules messages are to be considered. Just want to dispel doubts. I see plenty of code going in to svn that simply throws a new IllegalArgumentException() or whatever. It would be good if they had an externalized message to explain what the problem was -- i.e. throw new IllegalArgumentException(Parameter foobar should be less than 42) etc. Agree. Meaningful message helps. But all exceptions defined in java.nio and java.nio.channels only have a constructor without any parameter. :) Seems sun is becoming lazy on this issue. :) :) Rather call them clever than lazy in my mind, as an IllegalArgumentException can enough detail for user to know what is wrong (and javadoc also offer some information). Only some exception, like IOException, may need more detail for its cause. After all, now Harmony can use RI's error message, so it is no longer necessary to rack our brains to write error message. :) You might consider this a separate task to that of externalizing the existing messages, but depending on how 'manual' the externalization scan is for each module it may be worth doing both simultaneously. So once we have the basic framework in place for the message handling I think it will require a large manual effort to get all the strings that we want externalized properly. Luckily it is not technically complex work and it is a task that we can easily do in parallel across the modules. Yep, I've chosen the same way to do. Cool -- did you get anywhere with the message handling framework 'template' code? Regards, Tim - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classLib]Given a long value, RI behaves differently on windows and linux (and TestNG?)
Alexei Zakharov wrote: Hi, Is there any known real applications that use NIO for reading stuff with 4GB blocks? I've never heard of that. However, I believe there may be some in the future, or the operation system may support this. That's the reason I suggest Harmony use system call to solve the problem, not cut long to a integer in Harmony's Java or native code. Currently the problem is that the portlib has ignored the difference between Linux and windows, so we see no difference in Harmony, while RI behaves differently. And again, any sounds for TestNG? :) Regards, 2006/7/25, Leo Li [EMAIL PROTECTED]: 2006/7/25, Jimmy, Jing Lv [EMAIL PROTECTED]: Hi: I find another platform-dependent operation FileChannel.transforFrom(ReadableByteChannel src, long position, long count) in java.nio.channels. RI behaves differently if the given count is larger than Integer.MAX_VALUE: on windows, it throws an IOException; on Linux, it return zero silently. It is clear that the difference is caused by system call. Unfortunately Harmony fails to behave like RI as its has the same native code using the port-lib. If it is necessary to make Harmony behaving exactly like RI, I suggest writing native code for transforFrom. This may be a waste-of-effect as it is nearly the same except for this little difference.However, currently people have few chances to use a size larger than Integer.MAX_VALUE(nearly 4G, is it?), and system call does not support long value to pass in. Another thing I'd like to mention is that it'll be great if we can use testNG, or decide some other way to go. At least 2 testcases should be written for different platform as I remember, including the one for this problem. :) -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Dear Jimmy: As spec is not clear about how to deal with the argument greater than Integer.MAX_VALUE, maybe we shall look more closely at what RI does and how the system call behaves. I think it will be a good idea to let native code or even system call itself treat with such affairs, provided that Harmony will support some 64-bit platforms one day. Thus it may be not so wise to throw some exception in java code if encountering the data longer than 32-bits. Besides, whether we should behaves the same as RI, even if it is different on different platforms? :) -- Leo Li China Software Development Lab, IBM -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[classlib] imcompatible with RI?
Hi: I find that RI behaves strange in java.nio.channels.SelectableChannel.register. in NIO, channels and selector must be created by Provider. The doc reads: (Invoking register() should throw) IllegalSelectorException - If this channel was not created by the same provider as the given selector. To check if the two providers are the same, Harmony use if(selector.provider()==selector.provider)... , however it seems not correct. If we mock a channel extends SelectableChannel, put the same provider of selector as its provider, and register this channel to selector, RI fails with a IllegalSelectorException though two providers are the same. I have no idea if how RI do without checking providers are the same? Another thing is that if a selector has no channels register on it, invoke an operation of select() surely has nothing to do. In this way, Harmony returns immediately even invoking a block select(), however RI wait forever there, for nothing. I think Harmony's behavior is logical, but not compatible with RI. It seems a bug of RI, I suggest keep it as it is. -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[classLib]Given a long value, RI behaves differently on windows and linux (and TestNG?)
Hi: I find another platform-dependent operation FileChannel.transforFrom(ReadableByteChannel src, long position, long count) in java.nio.channels. RI behaves differently if the given count is larger than Integer.MAX_VALUE: on windows, it throws an IOException; on Linux, it return zero silently. It is clear that the difference is caused by system call. Unfortunately Harmony fails to behave like RI as its has the same native code using the port-lib. If it is necessary to make Harmony behaving exactly like RI, I suggest writing native code for transforFrom. This may be a waste-of-effect as it is nearly the same except for this little difference.However, currently people have few chances to use a size larger than Integer.MAX_VALUE(nearly 4G, is it?), and system call does not support long value to pass in. Another thing I'd like to mention is that it'll be great if we can use testNG, or decide some other way to go. At least 2 testcases should be written for different platform as I remember, including the one for this problem. :) -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][nio][discussion] Implementation of java.nio.channels.spi.SelectorProvider.inheritedChannel()
Leo Li wrote: 2006/7/24, Jimmy, Jing Lv [EMAIL PROTECTED]: Andrew Zhang wrote: Hello everybody, I plan to implement java.nio.channels.spi.SelectorProvider.inheritedChannel() method. Currently Harmony simply returns null. Spec doesn not specify how to detect inheritedChannel clearly, Returns the channel inherited from the entity that created this Java virtual machine. For example, on UNIX systems, the Internet services daemon (*inetd*) is used to start programs to service requests when a request arrives on an associated network port. In this example, the process that is started, inherits a channel representing a network socket. As my understanding, what inherited channel does is redirect socket to standard input. Therefore, my solution looks like following: 1. get standard input file descriptor 2. assert the file descriptor. If it is a socket type descriptor, then returns a channel which wraps the descriptor. Hi Andrew: I believe it is correct behavior Harmony should follow. What's more, it is necessary to detect Socket type, especially socket and ServerSocket (luckily datagram is easy to tell). There are two states of socket, bound and connected. In semantic, one socket that is bound and not connected should be wrapped as ServerSocket, and wrapped as Socket if connected. So how to wrap a socket that is not bound nor connected? It seems we need a test then. :) I also wrote some samples for ensuring my understanding. It seems OK on linux, but not the case on Window. RI always returns null on Windows (maybe because there is no service daemon program on Windows? or my understanding is totally wrong?) Therefore, I want to hear suggestions from our community, espeically folks experienced in network! Interesting, seems Bill Gates forgets inetd? :) Many thanks in advance! Best regards, -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Hi, Jimmy: It is right. According to my tests on Linux, if stdin is redirected to a socket that is SOCK_STREAM and is connected, the inheritedChannel gets a SocketChannel; if it is SOCK_STREAM and is not connected, the inheritedChannel gets a ServerSocketChannel. Cool! :) And according to Paulex's suggestion, I do a further study on windows with Services for UNIX(SFU), however I still get a null channel though SFU. So RI do nothing for windows? Who has different result than mine? -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][nio][discussion] Implementation of java.nio.channels.spi.SelectorProvider.inheritedChannel()
Andrew Zhang wrote: Hello everybody, I plan to implement java.nio.channels.spi.SelectorProvider.inheritedChannel() method. Currently Harmony simply returns null. Spec doesn not specify how to detect inheritedChannel clearly, Returns the channel inherited from the entity that created this Java virtual machine. For example, on UNIX systems, the Internet services daemon (*inetd*) is used to start programs to service requests when a request arrives on an associated network port. In this example, the process that is started, inherits a channel representing a network socket. As my understanding, what inherited channel does is redirect socket to standard input. Therefore, my solution looks like following: 1. get standard input file descriptor 2. assert the file descriptor. If it is a socket type descriptor, then returns a channel which wraps the descriptor. Hi Andrew: I believe it is correct behavior Harmony should follow. What's more, it is necessary to detect Socket type, especially socket and ServerSocket (luckily datagram is easy to tell). There are two states of socket, bound and connected. In semantic, one socket that is bound and not connected should be wrapped as ServerSocket, and wrapped as Socket if connected. So how to wrap a socket that is not bound nor connected? It seems we need a test then. :) I also wrote some samples for ensuring my understanding. It seems OK on linux, but not the case on Window. RI always returns null on Windows (maybe because there is no service daemon program on Windows? or my understanding is totally wrong?) Therefore, I want to hear suggestions from our community, espeically folks experienced in network! Interesting, seems Bill Gates forgets inetd? :) Many thanks in advance! Best regards, -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][nio]the conflict of RI and spec?
Anton Luht wrote:
Jimmy,
Please add readFile.delete() and writeFile.delete() in the end of test
or .deleteOnExit() in any place. Files created by createTempFile are
not cleaned up automatically.
Ah yes, sorry for that, thanks!
So temp files may not controlled by OS itself even they are in temp
directory of OS?
On 7/19/06, Jimmy, Jing Lv [EMAIL PROTECTED] wrote:
Hi:
I find a conflict that RI does not behave as spec says in
java.nio.channels.FileChannel.transforFrom(ReadableByteChannel src,
long position,long count).
The spec says:...Fewer than the requested number of bytes will be
transferred if the source channel has fewer than count bytes
remaining...[1]. As expected, invoking this method with a count larger
than the number of bytes remaining in the ReadableByteChannel, RI should
return a number of bytes exactly transfered. But in fact, RI throws an
IOException. I run the test[2] on windowsXP SP2 with RI1.5.0_01 and
RI1.5.0_06, and on Linux(redhat 9) with RI1.5.0_02 and RI1.5.0_06, and
get the same result.
Currently Harmony behave well on this. I guess this is a bug of RI,
and Harmony implementation is good. If no objection, I suggest add this
test to Harmony.
Any opinions? Thanks!
[1] spec of FileChannel:
http://java.sun.com/j2se/1.5.0/docs/api/java/nio/channels/FileChannel.html
[2] the test:
public void test_transferFromLReadableByteChannelJJ_overflow()
throws Exception {
String content = test content;
int length = content.length();
File readFile = File.createTempFile(testfile1, tmp);
File writeFile = File.createTempFile(testfile2, tmp);
FileOutputStream fos = new FileOutputStream(readFile);
try {
fos.write(content.getBytes());
} finally {
fos.close();
}
FileChannel fc1 = new FileInputStream(readFile).getChannel();
FileChannel fc2 = new FileOutputStream(writeFile).getChannel();
try {
long result = fc2.transferFrom(fc1, 0, length * 2);
assertEquals(length, result);
} finally {
fc1.close();
fc2.close();
}
}
--
Best Regards!
Jimmy, Jing Lv
China Software Development Lab, IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Best Regards!
Jimmy, Jing Lv
China Software Development Lab, IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Solution on Harmony-815 (was Re: [jira] Commented: (HARMONY-815) [classlib][nio] Refine implConfigureBlocking(boolean) method of DatagramChannel and SocketChannel.)
Alexey Varlamov wrote: IMHO, throwing a subclass certainly fits to specification and can hardly break compatibility with RI. I consider this is the proper workaround for now. Just my $0.02 :) Thanks Alexey, I have no objection if it does not break compatibility guideline :) -- Alexey Varlamov In this case, I guess if we set the cause to null when catching the SocketException will properly solve the problem. However it seems difficult as Throwable.initCause() can be called only once. If throwing a subclass may also break compatibility guideline, I still suggest return value, though it may break the current infrastructure(currently, all errors throw exception), it is still easy to deal with, only some of operation, read/write, require a little change, and we no longer need try...catch in Java code BTW, I find the code shall also deal with InterruptIOException. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[classlib][nio]the conflict of RI and spec?
Hi:
I find a conflict that RI does not behave as spec says in
java.nio.channels.FileChannel.transforFrom(ReadableByteChannel src,
long position,long count).
The spec says:...Fewer than the requested number of bytes will be
transferred if the source channel has fewer than count bytes
remaining...[1]. As expected, invoking this method with a count larger
than the number of bytes remaining in the ReadableByteChannel, RI should
return a number of bytes exactly transfered. But in fact, RI throws an
IOException. I run the test[2] on windowsXP SP2 with RI1.5.0_01 and
RI1.5.0_06, and on Linux(redhat 9) with RI1.5.0_02 and RI1.5.0_06, and
get the same result.
Currently Harmony behave well on this. I guess this is a bug of RI,
and Harmony implementation is good. If no objection, I suggest add this
test to Harmony.
Any opinions? Thanks!
[1] spec of FileChannel:
http://java.sun.com/j2se/1.5.0/docs/api/java/nio/channels/FileChannel.html
[2] the test:
public void test_transferFromLReadableByteChannelJJ_overflow()
throws Exception {
String content = test content;
int length = content.length();
File readFile = File.createTempFile(testfile1, tmp);
File writeFile = File.createTempFile(testfile2, tmp);
FileOutputStream fos = new FileOutputStream(readFile);
try {
fos.write(content.getBytes());
} finally {
fos.close();
}
FileChannel fc1 = new FileInputStream(readFile).getChannel();
FileChannel fc2 = new FileOutputStream(writeFile).getChannel();
try {
long result = fc2.transferFrom(fc1, 0, length * 2);
assertEquals(length, result);
} finally {
fc1.close();
fc2.close();
}
}
--
Best Regards!
Jimmy, Jing Lv
China Software Development Lab, IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Solution on Harmony-815 (was Re: [jira] Commented: (HARMONY-815) [classlib][nio] Refine implConfigureBlocking(boolean) method of DatagramChannel and SocketChannel.)
David Tanzer wrote:
On 17.07.2006, at 14:09, Richard Liang wrote:
LvJimmy,Jing wrote:
Hi Andrew:
Sorry for late, but as this solution does not resolve I18N (working
aound for 815 only?) , I guess we may have another way.
If I understand correctly, this solution try to analysis error code in
native code, throws ErrorCodeException; and java code catch this
exception,
get error code, and throw another exception.
If so, why not just return the error code directly instead? :)
Hello Jimmy,
IIRC, It's SocketException that is thrown in native code, not
ErrorCodeException. And we will set the ErrorCodeException as cause of
the SocketException.
Yes, this is how I remember it too. The idea was to do the equivalent of
the
following code in the native code (correct me if I'm wrong):
ErrorCodeException ece = new ErrorCodeException(SOME_ERROR_CODE);
throw new SocketException(Some Message, ece);
Yes, sorry for my mistake :)
I don't think it is semantically correct to set the ErrorCodeException
as the cause
of the SocketException - the error code provides additional info, it is
not the cause
of the problem. For example, this code:
try {
ErrorCodeException ece = new ErrorCodeException(13);
throw new TestException(Something went wrong, ece);
} catch(TestException e) {
e.printStackTrace();
}
Yields the following stack trace:
net.guglhupf.test.TestException: Something went wrong
at net.guglhupf.test.ExceptionTest.main(ExceptionTest.java:7)
Caused by: Error Code 13
at net.guglhupf.test.ExceptionTest.main(ExceptionTest.java:6)
which might be confusing for some application developer so personally
I like the subclass - approach described by Andrew Zhang [1] better.
In this case, I guess if we set the cause to null when catching the
SocketException will properly solve the problem. However it seems
difficult as Throwable.initCause() can be called only once.
If throwing a subclass may also break compatibility guideline, I still
suggest return value, though it may break the current
infrastructure(currently, all errors throw exception), it is still easy
to deal with, only some of operation, read/write, require a little
change, and we no longer need try...catch in Java code
BTW, I find the code shall also deal with InterruptIOException.
Regards,
David
[1]
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200607.mbox/[EMAIL PROTECTED]
I18N is anther issue, we shall have full discussion in community to
mature our thoughts. :-)
Do I miss something?
Best regards,
Richard.
2006/7/14, Mikhail Loenko [EMAIL PROTECTED]:
Hi Andrew
this seems reasonable
Thanks,
Mikhail
2006/7/14, Andrew Zhang [EMAIL PROTECTED]:
Hi folks,
I'd like to adopt Tim's suggestion to solve Harmony-815. It avoids
message
comparison while keeps current luni native architecture.
Before I upload a new patch to JIRA, I want to hear more voices from
the community. Any better suggestions? Any comments?
Mikhail, what's your opnion? Do you think it makes sense?
Thanks in advance!
Best regards,
Andrew
On 7/14/06, Tim Ellison [EMAIL PROTECTED] wrote:
Andrew Zhang wrote:
How about design a subclass which extends from SocketException,
looks
like:
If you want to preserve the throwable type you could create a
o.a.h.luni.ErrorCodeException that has a errorCode field set by the
native, and then make that the cause of the SocketException.
The calling code would then do something like:
((ErrorCodeException)ex.getCause()).getErrorCode()
Just a thought.
Regards,
Tim
class SocketWithErrorCodeException extends SocketException {
SocketWithErrorCodeException (String message, int errorCode) {
super(message); this.errorCode = errorCode; }
private int errorCode;
public void get/setErrorCode() ;
}
Native code throws SocketWithErrorCodeException instead of
SocketException
so that java code could process different error by invoking
e.getErrorCode
().
Does that make sense?
Thanks!
On 7/13/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote:
I agree with the reason why (I think I understand it - you don't
want
to
rely on the result of getMessage() to determine the problem...)
Could you wrap the socket exception to carry a simple integer
error
code?
geir
Mikhail Loenko wrote:
-1 for applying the patch
Applying this patch means creating a hidden problem
Thanks,
Mikhail
2006/7/12, Jimmy, Jing Lv [EMAIL PROTECTED]:
Andrew Zhang wrote:
Hello Mikhail,
Please see my comments inline.
Thanks!
On 7/12/06, Mikhail Loenko [EMAIL PROTECTED] wrote:
2006/7/12, Andrew Zhang [EMAIL PROTECTED]:
Hi Mikhail,
It's a NON-NLS message.
Native code is designed in this way. Currently, Harmony
socket
native
code
uses messages in SocketException to identify
Re: [jira] Commented: (HARMONY-815) [classlib][nio] Refine implConfigureBlocking(boolean) method of DatagramChannel and SocketChannel.
:
return No buffer space is available;
case HYPORT_ERROR_SOCKET_HOSTNOTFOUND:
return Authoritative Answer Host not found;
case HYPORT_ERROR_SOCKET_NODATA:
return Valid name, no data record of requested type;
case HYPORT_ERROR_SOCKET_BOUNDORCONN:
return The socket has not been bound or is already connected;
case HYPORT_ERROR_SOCKET_OPNOTSUPP:
return The socket does not support the operation;
case HYPORT_ERROR_SOCKET_OPTUNSUPP:
return The socket option is not supported;
case HYPORT_ERROR_SOCKET_OPTARGSINVALID:
return The socket option arguments are invalid;
case HYPORT_ERROR_SOCKET_SOCKLEVELINVALID:
return The socket level is invalid;
case HYPORT_ERROR_SOCKET_TIMEOUTFAILURE:
return The timeout operation failed;
case HYPORT_ERROR_SOCKET_SOCKADDRALLOCFAIL:
return Failed to allocate address structure;
case HYPORT_ERROR_SOCKET_FDSET_SIZEBAD:
return The calculated maximum size of the file descriptor set is
bad;
case HYPORT_ERROR_SOCKET_UNKNOWNFLAG:
return The flag is unknown;
case HYPORT_ERROR_SOCKET_MSGSIZE:
return
The datagram was too big to fit the specified buffer, so truncated;
case HYPORT_ERROR_SOCKET_NORECOVERY:
return The operation failed with no recovery possible;
case HYPORT_ERROR_SOCKET_ARGSINVALID:
return The arguments are invalid;
case HYPORT_ERROR_SOCKET_BADDESC:
return The socket argument is not a valid file descriptor;
case HYPORT_ERROR_SOCKET_NOTSOCK:
return The socket argument is not a socket;
case HYPORT_ERROR_SOCKET_HOSTENTALLOCFAIL:
return Unable to allocate the hostent structure;
case HYPORT_ERROR_SOCKET_TIMEVALALLOCFAIL:
return Unable to allocate the timeval structure;
case HYPORT_ERROR_SOCKET_LINGERALLOCFAIL:
return Unable to allocate the linger structure;
case HYPORT_ERROR_SOCKET_IPMREQALLOCFAIL:
return Unable to allocate the ipmreq structure;
case HYPORT_ERROR_SOCKET_FDSETALLOCFAIL:
return Unable to allocate the fdset structure;
case HYPORT_ERROR_SOCKET_CONNECTION_REFUSED:
return Connection refused;
default:
return (char *) hysock_error_message ();
}
}
Thanks,
Mikhail
Best regards,
Andrew
On 7/11/06, Mikhail Loenko (JIRA) [EMAIL PROTECTED] wrote:
[
http://issues.apache.org/jira/browse/HARMONY-815?page=comments#action_12420281
]
Mikhail Loenko commented on HARMONY-815:
Hi Andrew
I think it's rather dangerous:
} catch (SocketException e) {
if (ERRMSG_NONBLOKING_OUT.equals(e.getMessage())) {
return sendCount;
}
throw e;
Once we internationilize our code that won't work
[classlib][nio] Refine implConfigureBlocking(boolean) method of
DatagramChannel and SocketChannel.
--
Key: HARMONY-815
URL: http://issues.apache.org/jira/browse/HARMONY-815
Project: Harmony
Type: Improvement
Components: Classlib
Reporter: Andrew Zhang
Assignee: Mikhail Loenko
Attachments: nio.diff
Currently, Harmony DatagramChannel.implConfigureBlocking(boolean)
does
nothing.
It doesn't cause any problem of read operation because Harmony uses
select+blocking read to ensure nonblocking reading.
But it affects write operations, although it is difficult to test
the
difference between blocking write and blocking write.
Another defect is introduced by portlib bug. As discussed on
mailing
list[1], connect_with_timeout always changes the fd to blocking mode
after
invocation.
I'll upload a patch to fix these problems.
Thanks!
Best regards,
Andrew
--
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
--
Andrew Zhang
China Software Development Lab, IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Best Regards!
Jimmy, Jing Lv
China Software Development Lab, IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
I18N on native (was:Re: [jira] Commented: (HARMONY-815) [classlib][nio] Refine implConfigureBlocking(boolean) method of DatagramChannel and SocketChannel.)
Hi: I'd like to raise the topic on I18N of native code. As discussed about patch-815, we found there are exceptions thrown by native code with un-internationalized error message. To resolve this problem, there may be two solutions: 1) make native code return error code instead of throw exceptions, and let Java code deal with these errors. This seems pretty good, and also resolve such problems like 815, but require much more effort to refactor all native and Java codes. What's more, as some native methods do not return an integer at all, we may add an output parameter to them, at least for network-related luni/nio, there are about 10 methods like this. 2) As it is still easy for native code to call Java code, so rewrite error-message-lookup native method to lookup internationalized message, e.g., call MsgUtil.getString(). This refactor may be easy, but to JIRA-815 and other message-dependent Java code, it do no help. So it still requires other refactoring, e.g., return error code in some situation like suggested in (1). Another solution can be: catch exceptions on Java code, replace its message, and throw out again, this may be too ugly, so I do not suggest so. Any suggestions? Thanks! -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: portlib functionality
Marina Goldburt wrote: Tim, Paulex, Will look at the file locking later...And I'm sure there are other things worthing evaluation to be portlib extension. And what is the way to extend the portlib functionality? If we add all the missing functions to the HyPortLibrary structure, the structure will grow awfully. And, as I understand, every change in the structure leads to vm recompilation. I can prepare a patch that moves platform-dependent file I/O operations from luni/luni to luni/port submodule. Is it will be useful? Marina A great idea! :) But as I know, some of the methods are a bit complex and require well-design on api, e.g., selectImpl() in luni, which was written into one method in Harmony native code, but IMHO if removes into portlib, it must be separated into two or three methods, and should be design carefully. So I suggest more discussion on this. :) -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][nio] Modify ServerSocketChannel.implConfigureBlocking() method
Andrew Zhang wrote: Hello everybody, I changed the subject to make things clear. Jimmy, as you mentioned, What's more, I find some operations related to network are also written in this way, first select and then read/write/accept/connect, so I guess all implementation in java.nio.channels shall remove setNonblocking() in implConfigureBlocking(). I agree with you. That's what I suggested in solution 1. So if no objects, I'll adopt solution 1 to fix the problem. Hi Andrew: I have some new discovery and remove setNonblocking() may be a bad suggestion. Though in native code read operation uses a select() for non-blocking mode, write operation are implemented in the other way, it uses blocking write always. As a result, setNonBlocking here are still reasonable. All the complex come from connect_with_timeout() in portlib, which set nonblocking and did not set back to ordinary mode, this is properly a bug. But before its fixing, we should work around. I have noticed that Harmony-779 on JIRA, it removes setNonBlocking. This may causes some bugs, especially in send/write, however to datagramSocket, this may be trifling as its send/write can be hardly blocked (I have not got a testcase for blocking send yet). But I also notice JIRA-778 also require removing setNonblocking(),I suggest not. For socket.write, it will block until system underlying buffer is large enough. As a result, keep it as it is, and a fix to portlib shall be an improvement. Any ideas and comments? Thanks! On 7/3/06, Jimmy, Jing Lv [EMAIL PROTECTED] wrote: Andrew Zhang wrote: Hello Tim I think I have found where the problem is. When I ran the test with latest code, the test failed again on my machine. How lucky am I :) Lucky dog :) The failure trace[1] tells us it fails because of ServerSocketChannel.accept(). Message The socket is marked as nonblocking operation would block means The socket is marked non-blocking and no connections are present to be accepted.. On linux, the return value is EAGAIN or EWOULDBLOCK. It happens when the native file descriptor is configured as nonblocking and no connections are pending. Therefore, we have two ways to fix the bug in ServerSocketChannel.accept(): 1. Don't configure native file descriptor as nonblocking, and use select + blocking accept to implement non blocking accept, which is similiar with nonblocking read/write implementaion of SocketChannel. The fix is rather simple, leave implConfigureBlocking as empty is ok. 2. Check the exception thrown by native code. Harmony throws BindException with The socket is marked as nonblocking operation would block message. We could catch BindException and check exception message to know whether the accept is successful. Such check is ugly, but native code acts in this way. :( If error code is returned, the things wil be much easier. (Of course, it's not a good idea either, since error code is platform dependent.) Therefore, in my opnion, solution 1 sounds more reasonable. Any suggestions? Thanks a lot! Interesting, trace into native code, it just do as you said in (1). :) Seems it is unnecessary to set real blocking/nonblocking to OS level, so remove setNonblocking() in implConfigureBlocking() is correct. What's more, I find some operations related to network are also written in this way, first select and then read/write/accept/connect, so I guess all implementation in java.nio.channels shall remove setNonblocking() in implConfigureBlocking(). And what you said in (2) may be correct as well. And I find setNonblocking() shall not be effective sometimes if it call a timeout connect(). The native code of connect() is rather strange, it set socket to nonblocking mode as first and set it to blocking mode at the end (But not set it back to the origin mode!), in this way it cause confusion. Luckily we found try...catch to catch such exception in Harmony Java code, that's why Harmony is still correct in logic(Maybe accept() is not, as it does not deal with this exception at all). The reason why should deal this problem is the native function for both java.net and net-related java.nio.channels, and I guess some methods were written for java.net(blocking network I/O) and re-used by NIO(non-blocking network I/O). It works properly except for a few differences between java.net and NIO, these differences rise the complexity, luckily most of them are resloved. [1] java.net.BindException: The socket is marked as nonblocking operation would block at org.apache.harmony.luni.platform.OSNetworkSystem.acceptStreamSocketImpl (Native Method) at org.apache.harmony.luni.platform.OSNetworkSystem.acceptStreamSocket( OSNetworkSystem.java:219) at org.apache.harmony.luni.net.PlainSocketImpl.accept(PlainSocketImpl.java :96) at java.net.ServerSocket.implAccept(ServerSocket.java:252) at org.apache.harmony.nio.internal.ServerSocketChannelImpl
Re: [announce] New Apache Harmony Committer : Weldon Washburn
Geir Magnusson Jr wrote: Please join the Apache Harmony PPMC in welcoming the project's newest committer, Weldon Washburn. Weldon was one of the initial committers listed on the original Harmony proposal. Incubator tradition is such that listed committers be granted committer status immediately, but we've altered that process a little and look for continued commitment, participation, alignment and contribution. Weldon certainly has participated beyond the initial proposal in both our community discussions as well as code contributions, most significantly in the classpath library adapter, which we hope this committer status will make it easier to finish :) We all expect continued participation and contribution. Weldon, as a first step to test your almighty powers of committership, please update the committers page on the website. That should be a good (and harmless) exercise to test if everything is working. Things to do : 1) test ssh-ing to the server people.apache.org. 2) Change your login password on the machine as per the account email 3) Add a public key to .ssh so you can stop using the password 4) Change your svn password as described in the account email At this point, you should be good to go. Checkout the website from svn and update it. See if you can figure out how. Also, for your main harmony/enhanced/classlib/trunk please be sure that you have checked out via 'https' and not 'http' or you can't check in. You can switch using svn switch. (See the manual) Finally, although you now have the ability to commit, please remember : 1) continue being as transparent and communicative as possible. You earned committer status in part because of your engagement with others. While it was a have to situation because you had to submit patches and defend them, but we believe it is a want to. Community is the key to any Apache project. 2)We don't want anyone going off and doing lots of work locally, and then committing. Committing is like voting in Chicago - do it early and often. Of course, you don't want to break the build, but keep the commit bombs to an absolute minimum, and warn the community if you are going to do it - we may suggest it goes into a branch at first. Use branches if you need to. 3) Always remember that you can **never** commit code that comes from someone else, even a co-worker. All code from someone else must be submitted by the copyright holder (either the author or author's employer, depending) as a JIRA, and then follow up with the required ACQs and BCC. Again, thanks for your hard work so far, and welcome. The Apache Harmony PPMC - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Congratulations! :) -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][nio][question] Peek on DatagramChannel.receive(ByteBuffer) ?
Andrew Zhang wrote:
Hello everybody,
When I reviewed o.a.h.nio.internal.DatagramChannelImpl, I found following
FIXME:
// // FIXME donot peek at time,see if can improve
// DatagramPacket peekPack = new DatagramPacket(new byte[1], 1);
// synchronized (dataLock) {
// networkSystem.receiveDatagram(fd, peekPack, peekPack.getData
(),
// peekPack.getOffset(), peekPack.getLength(),
// isBlocking() ? 0 : DEFAULT_TIMEOUT, true);
// }
// if (null == peekPack.getAddress()) {
// // if no new packet peeked
// return null;
// }
I feel a little puzzled by this FIXME. After writing several tests, I don't
think peek is necessary.
Could anyone tell me whether peek operation makes any sense here?
It seems the code tries to peek if any datagram packages arrived and
returns immediately if none. I guess it also wants to see where does the
package come from and do some security check as many network programs
do(currently it does the check after recieve). However, DatagramChannel
will discards all packages that fail in security check, so IMHO peek
here is not necessary. I agree that these lines can be removed.
Thanks!
Best regards,
--
Best Regards!
Jimmy, Jing Lv
China Software Development Lab, IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][nio] [question] Synchronization issue on MappedByteBuffer ?
Andrew Zhang wrote: Hello everyone, I noticed there are several FIXMEs in MappedByteBufferAdapter.java, which are related to synchronization issue. Following FIXME is for getChar() method: // FIXME Need synchronization as far as the update of this.position is concerned of the following methods? Spec does not say whether MappedByteBuffer is thread safe. It is the decision we should make. I read through MappedByteBuffer javadoc, and didn't find any description about concurrent synchronization. The spec on MappedByteBuffer emphasizes All or part of a mapped byte buffer may become inaccessible at any time, and in the end, it mentions Mapped byte buffers otherwise behave no differently than ordinary direct byte buffers. Seems few Buffer Classes apply synchronization. And according to our Compatibility-Guidelines, javadoc says nothing and we should follow RI, so maybe removing the FIXMEs is a good choice. :) It'll be better if some test cases can be written. Spec doesn't mention any synchronization issues on direct byte buffers either. Therefore, in my opnion, only synchronizing for MappedByteBuffer is unnecessary. Any comments? or may I miss something? Thanks! Best regards, -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [continuum] BUILD FAILURE: Classlib/win.ia32 Build/Test
[EMAIL PROTECTED] wrote: Latest Windows build just failed a test: java.nio.channels.ClosedChannelException at java.nio.channels.spi.AbstractSelectableChannel.configureBlocking( AbstractSelectableChannel.java:208) at org.apache.harmony.tests.java.nio.channels.SelectorTest.assert_select_OP_READ (SelectorTest.java:416) at org.apache.harmony.tests.java.nio.channels.SelectorTest.test_selectNow( SelectorTest.java:200) at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:205) Apache Harmony Build wrote: Online report : http://ibmonly.hursley.ibm.com/continuum/win.ia32/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/6/buildId/1507 Build statistics: State: Failed Previous State: Ok Started at: Fri, 30 Jun 2006 09:05:23 +0100 Finished at: Fri, 30 Jun 2006 09:14:47 +0100 Total time: 9m 23s Build Trigger: Schedule Exit code: 1 Building machine hostname: hy1 Operating system : Windows XP(Service Pack 2) Java version : 1.5.0_06(Sun Microsystems Inc.) Changes classlib\modules\tools\src\main\java\org\apache\harmony\tools\javac\Compiler.java classlib\modules\beans\src\main\java\java\beans\PropertyChangeSupport.java classlib\modules\security\src\test\api\java\org\apache\harmony\security\tests\java\security\serialization\KeyPairTest.java classlib\modules\security\src\test\resources\serialization\org\apache\harmony\security\tests\java\security\serialization\KeyPairTest.golden.ser classlib\modules\security\build.xml Output: Buildfile: build.xml -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[classlib] trying new framework for testing serialization (was:Merging frameworks for testing serialization - first step)
Hi Stepan:
Seems the new framework for serialization has added to Harmony, I'm
trying it and find it interesting. However I have a few questions:
1. It is strange that SerializationTest is an abstract class extends
junit.framework.testcase, in this case I can either (a) extends
SerializationTest directly, implements getData() and run, it shall run
testSelf and testGolden, but how to control more complex situation
in this way? or (b) write a test extends testcase, and use static
methods verifySelf and verifyGolden in SerializationTest as
Guidelines says, however I wonder why it extends testcase?
2. It is strange verifyGolden(test, object) has two parameter, but in
the example in the Guidelines says:
public void testSerializationCompatibility()
throws Exception {
SerializationTest.verifyGolden(new SomeSerializableClass());
} something lost?
And I guess the first parameter is used only to parse the name of
resource file. If so, may it change the parameter to a String, or
something else?
3. The test needs ser-files, so it may be necessary to add a method to
create this file easily just like the old framework. I find a protected
method produceGoldenFiles(), is that used for it (why protected?)? This
may be necessary to guildance.
What's more, the ser-file must be end with .ser, but in new framework,
I still find it uses .dat . And the path is test/common/unit/... but
in Harmony's Test Guildance tells:/src/test/resources/serialization...
Your comments? Thanks!
--
Best Regards!
Jimmy, Jing Lv
China Software Development Lab, IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] trying new framework for testing serialization
Jimmy, Jing Lv wrote:
Hi Stepan:
Seems the new framework for serialization has added to Harmony, I'm
trying it and find it interesting. However I have a few questions:
1. It is strange that SerializationTest is an abstract class extends
junit.framework.testcase, in this case I can either (a) extends
SerializationTest directly, implements getData() and run, it shall run
testSelf and testGolden, but how to control more complex situation
in this way? or (b) write a test extends testcase, and use static
methods verifySelf and verifyGolden in SerializationTest as
Guidelines says, however I wonder why it extends testcase?
By reading old threads, I've aware that these two ways are both OK, but
the Guidelines say nothing about it, so may you tell me some detail
about it? Thanks! :)
2. It is strange verifyGolden(test, object) has two parameter, but in
the example in the Guidelines says:
public void testSerializationCompatibility()
throws Exception {
SerializationTest.verifyGolden(new SomeSerializableClass());
} something lost?
And I guess the first parameter is used only to parse the name of
resource file. If so, may it change the parameter to a String, or
something else?
3. The test needs ser-files, so it may be necessary to add a method to
create this file easily just like the old framework. I find a protected
method produceGoldenFiles(), is that used for it (why protected?)? This
may be necessary to guildance.
What's more, the ser-file must be end with .ser, but in new framework,
I still find it uses .dat . And the path is test/common/unit/... but
in Harmony's Test Guildance tells:/src/test/resources/serialization...
Your comments? Thanks!
--
Best Regards!
Jimmy, Jing Lv
China Software Development Lab, IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] trying new framework for testing serialization
Stepan Mishura wrote:
Hi Jimmy,
On 6/30/06, Jimmy, Jing Lv wrote:
Hi Stepan:
Seems the new framework for serialization has added to Harmony, I'm
trying it and find it interesting. However I have a few questions:
1. It is strange that SerializationTest is an abstract class extends
junit.framework.testcase, in this case I can either (a) extends
SerializationTest directly, implements getData() and run, it shall run
testSelf and testGolden, but how to control more complex situation
in this way? or (b) write a test extends testcase, and use static
methods verifySelf and verifyGolden in SerializationTest as
Guidelines says, however I wonder why it extends testcase?
You should use approach described in [1]. The second way (i.e. extending
SerializationTest) is used by 'security' serialization tests only. As we
agreed we won't use it and all 'security' serialization tests should be
refactored to avoid extending SerializationTest. However it hard to do at
once. So I put stubs to testSelf and testGolden methods to let
'security' tests smoothly migrate to the new testing approach.
Please follow conventions in [1] for creating new serialization tests.
2. It is strange verifyGolden(test, object) has two parameter, but in
the example in the Guidelines says:
public void testSerializationCompatibility()
throws Exception {
SerializationTest.verifyGolden(new SomeSerializableClass());
} something lost?
And I guess the first parameter is used only to parse the name of
resource file. If so, may it change the parameter to a String, or
something else?
Yes, it is a mistake. Somebody already caught it and I fixed it in r417133
but the page on the web-site didn't updated yet. So I should say:
public void testSerializationCompatibility()
throws Exception {
SerializationTest.verifyGolden(this, new SomeSerializableClass());
}
The first param is TestCase instance that is used to locate golden file.
3. The test needs ser-files, so it may be necessary to add a method to
create this file easily just like the old framework. I find a protected
method produceGoldenFiles(), is that used for it (why protected?)? This
may be necessary to guildance.
What's more, the ser-file must be end with .ser, but in new framework,
I still find it uses .dat . And the path is test/common/unit/... but
in Harmony's Test Guildance tells:/src/test/resources/serialization...
Yes, I agree that utility method for producing golden files will be useful.
I didn't think how to implement it yet - so suggestion and patches are
welcome.
I see now, thank you very much Stepan! :)
To produce golden files, I believe a little change to
produceGoldenFiles() may meet this requirement. I'd like to help.:)
But first of all it may change its search path, as when I create a new
test and try verifyGolden(), I find a FileNotFoundException. It seems
trying to search test/common/unit/.../SomeTest.golden.dat, is that
because of serialization-test for security? Waiting for your refactoring :)
Thanks,
Stepan.
[1]
http://incubator.apache.org/harmony/subcomponents/classlibrary/ser_testing.html
Your comments? Thanks!
--
Best Regards!
Jimmy, Jing Lv
China Software Development Lab, IBM
--
Best Regards!
Jimmy, Jing Lv
China Software Development Lab, IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][nio] Platform dependent tests in SocketChannelTest
Andrew Zhang wrote:
Hello everybody,
I noticed there are 8 FIXMEs in SocketChannelTest, which are mainly caused
by platform differences.
Take following FIXME as example:
public void testCFII_ServerStartLater_NonBlock() throws Exception {
// ensure
ensureServerClosed();
this.channel1.configureBlocking(false);
statusNotConnected_NotPending();
// connect
assertFalse(this.channel1.connect(localAddr1));
statusNotConnected_Pending();
ensureServerOpen();
try {
assertFalse(this.channel1.finishConnect());
statusNotConnected_Pending();
this.channel1.close();
} catch (ConnectException e) {
// FIXME: assertEquals(e.getMessage(), Connection refused);
}
}
The process of this test looks like:
client socket connect (server is closed) - open server - finishConnect .
RI acts differently on windows and Linux:
On windows, finishConnect returns false.
On Linux, finishConnect throws ConnectException instead of returning false.
and Harmony acts the exactly SAME as RI.
Deeply trace into Harmony code, I find it is the difference of
windows/Linux system call. In both platform the test try to call a
select to detect whether connected, however the return value differs,
(Linux return a value means connect refused ,which cause a exception).
I believe Harmony is correct in code as it behaves the same as RI.
Maybe the testcase shall be refactored, I remember there's discussion on
mailing but draw no good conclusion, though there are 3 idea about
platform dependent testcase in my memory:
1. add it to platform dependent list, like Harmony's exclude list, run
only on certain platform. Is it Mark or George's idea?
2. check platform in the testcase and run, e.g., check system property
OS.name. But it seems a bad practice;
3. remove them all until we find a better way.
IMO, the first way suggests here is reasonable, but need a modification
on build.xml. Otherwise let's remove them until we find a better way.
However it is very interesting, Java says it build once, run
everywhere, but it does not always appear the same in the same operation :)
Could anyone give some suggestions on such platform dependent tests?
Remove them? or other solutions?
Personally, I prefer to remove these tests.
Any suggestions are highly appreciated!
Thanks!
Best regards,
--
Best Regards!
Jimmy, Jing Lv
China Software Development Lab, IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] mem
Geir Magnusson Jr wrote:
Why would I use
portLib-mem_allocate_memory(portLib)
over just calling
hymem_allocate_memory(portlib, )
Hi Geir:
Not sure if the later is hymem_allocate_memory(int size)? If so,
they are the same indeed, and the later is the a macro. Everytime before
we use the macro, call PORT_ACCESS_FROM_ENV (env)
e.g.:
somemethod(JNIEnv * env, ...){
PORT_ACCESS_FROM_ENV (env);
...
hymem_allocate_memory(sizeof(something));
...
}
And they are defined in hyport.h. :)
geir
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Best Regards!
Jimmy, Jing Lv
China Software Development Lab, IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][LUNI | NIO] How to write stable tests for blocking write/read operations of Socket and SocketChannel
To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Andrew Zhang China Software Development Lab, IBM -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] moving to 1.5 for real - discuss
Tim Ellison wrote: Alexey Varlamov wrote: So we need answers from DRLVM and jchevm guys... Archie has expressed the jchevm opinion in favour of the change -- anyone familiar with DRLVM care to comment? (Of course this would be after Geir's VM build work, just asking) Regards, Tim DRLVM needs some (minor) changes to support 1.5-targeted classfiles, this is quite easy. Full-fledged implementation of 1.5 kernel classes (annotations, reflection, etc) requires some more efforts but also should not take too long. Understood, I wasn't expecting those to be working -- just the effort to let DRLVM grok the v49 files. So +1 from me. Well it isn't a formal vote, but glad to see you are in favor too. Regards, Tim Seems everyone is glad to move to 1.5, so I'd like to know when will Harmony reach this milestone? I can hardly wait :) -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Fwd: [classlib][NIO|VMI]Interruptible channel implementation - how to interact with Thread?]
Archie Cobbs wrote: Paulex Yang wrote: Seems Thread's implementation must be aware of what operation it is blocking on. So I propose the following solution: I don't think the VM or java.lang.Thread needs to be involved. First of all, the code performing the blocking operation knows what kind of operation it is, so when it wakes up abnormally it can take the appropriate action. This code doesn't necessarily reside in java.lang.Thread. In Classpath the java.nio stuff is all implemented in native libraries without the VM or java.lang.Thread being specially aware of anything. However, classlib's design may be different enough to need it (I haven't studied it as much as you guys). E.g., the java.nio native code does invoke Thread.interrupt() and Thread.interrupted(), but these are normal, API-specified methods. Might be worth taking a look for some design ideas. Thanks Archie, it sounds interesting :). As I study few about Classpath, I still have a question here. As we know, there are three states of blocking on a thread. One is wait(), sleep() and so forth, thread class handle them itself, it is easy to interrupt; and one is blocking on I/O, invoke Thread.interrupt() may be not enough as it is blocked on a system call, e.g., call read on socket may not return until it receive something or it is closed. In this way, the Thread.interrupt should know how to close the socket to perform the real interruption. The question is: how can the thread know if it is blocked on wait() or I/O operation currently? I think this is the reason why Paulex require Thread to be involved. So I'm very interested in what does Classpath do here to stop I/O operation without get involved? Here is the spec about Thread.interrupt(): ... If this thread is blocked in an invocation of the wait(), wait(long), or wait(long, int) methods of the Object class, or of the join(), join(long), join(long, int), sleep(long), or sleep(long, int), methods of this class, then its interrupt status will be cleared and it will receive an InterruptedException. If this thread is blocked in an I/O operation upon an interruptible channel then the channel will be closed, the thread's interrupt status will be set, and the thread will receive a ClosedByInterruptException. ... -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][NIO|VMI]JNI 1.4 enhancement on ByteBuffer
Paulex Yang wrote: There is some enhancement on JNI spec in JDK 1.4[1], and three methods are related to java.nio.ByteBuffer. * |NewDirectByteBuffer| http://java.sun.com/j2se/1.4.2/docs/guide/jni/jni-14.html#NewDirectByteBuffer * |GetDirectBufferAddress| http://java.sun.com/j2se/1.4.2/docs/guide/jni/jni-14.html#GetDirectBufferAddress * |GetDirectBufferCapacity| http://java.sun.com/j2se/1.4.2/docs/guide/jni/jni-14.html#GetDirectBufferCapacity Because these methods are actually classlib dependent and JNI implementation must know some details of ByteBuffer implementation, current IBM VME hasn't them implemented, and seems DRLVM doesn't implemented thoroughly(please correct me if I made mistake here, seems DRLVM tries to get some non-api method/field of ByteBuffer, and if fails, it return NULL or -1 as JNI spec says). And I have no idea how Sable/JCHEVM/BootJVM deals with this issue yet.(anyone kindly let me know?) I propose to provide the implementation in NIO component, and I raise Harmony-578 for it. The idea is: export these three methods in NIO module as hynio.dll(.so), which is loaded by Harmony launcher, and add these methods to VMI in some way, so that the VM vendor(i.e., JNI implementation vendor) can add these methods to JNI function table. Other choices I can imagine now include: 1. Add related direct buffers class to kernel class, so that the VM vendor can implement it as well as the JNI methods. IMO this is not good choice because buffers are actually VM independent, it's not reasonable to let VM vendor to implement these classes. By reading the spec, it seems RI prefer this way, take direct-buffer as kernel class ,like class String(Though maybe it is hard to tell kernel and normal classes in RI's implementation, they're always together there :) ). And in Harmony, there's an interface named DirectBuffer (o.a.h.nio.internal), abstract class Buffer(java.nio) and an implementation class ReadWriteDirectByteBuffer (java.nio),which contains fields and methods for JNI methods. So an easy way may be: take these as kernel classes, and get Address from DirectBuffer.getBaseAddress(), get Capacity from Buffer.capacity, and new a ReadWriteDirectByteBuffer as basic direct buffer in three JNI methods. 2. Provides some utility methods in o.a.h.nio, add these methods to VMI, so that VM vendor can get inside knowledge on the direct buffers by these utilities. This option is acceptable, but it also needs to modify VMI, and the modification is based on some Harmony specific contract, while my proposal above is based on public JNI spec, so this one is not preferred. Any ideas and comments are highly welcome. [1]http://java.sun.com/j2se/1.4.2/docs/guide/jni/jni-14.html -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [announce] New Apache Harmony Committer : Mark Hindess
Geir Magnusson Jr wrote: Please join the Apache Harmony PPMC in welcoming the project's newest committer, Mark Hindess. Mark has demonstrated the elements that help build a healthy community, namely his ability to work together with others, continued dedication to the project, an understanding of our overall goals of the project, and some amazing ability in creating build systems :) We all continue to expect great things from him. Mark, as a first step to test your almighty powers of committership, please update the committers page on the website. That should be a good (and harmless) exercise to test if everything is working. Things to do : 1) test ssh-ing to the server people.apache.org. 2) Change your login password on the machine as per the account email 3) Add a public key to .ssh so you can stop using the password 4) Change your svn password as described in the account email At this point, you should be good to go. Checkout the website from svn and update it. See if you can figure out how. Also, for your main harmony/enhanced/classlib/trunk please be sure that you have checked out via 'https' and not 'http' or you can't check in. You can switch using svn switch. (See the manual) Finally, although you now have the ability to commit, please remember : 1) continue being as transparent and communicative as possible. You earned committer status in part because of your engagement with others. While it was a have to situation because you had to submit patches and defend them, but we believe it is a want to. Community is the key to any Apache project. 2)We don't want anyone going off and doing lots of work locally, and then committing. Committing is like voting in Chicago - do it early and often. Of course, you don't want to break the build, but keep the commit bombs to an absolute minimum, and warn the community if you are going to do it - we may suggest it goes into a branch at first. Use branches if you need to. 3) Always remember that you can **never** commit code that comes from someone else, even a co-worker. All code from someone else must be submitted by the copyright holder (either the author or author's employer, depending) as a JIRA, and then follow up with the required ACQs and BCC. Again, thanks for your hard work so far, and welcome. The Apache Harmony PPMC - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Congratulations, Mark! :) -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] Enum ready to go
Stepan Mishura wrote: I found the reason - tests expect NPE when valueOf(null) is invoked but IAE is thrown instead. For example, java.lang.IllegalArgumentException at org.apache.harmony.tests.java.lang.EnumTest$Sample.valueOf(EnumTest.java :22) at org.apache.harmony.tests.java.lang.EnumTest.test_valueOfLjava_lang_String (EnumTest.java:113) at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:205) Thanks, Stepan. Hi: It works well on my workspace, with windows XP sp2, RI (1.5.0_06, the latest version). By the way, it also passes all test on RI 1.5.0_01, and on Linux(kernel 2.4.2, RI 1.5.0_02). Look into code, I doubt perhaps it is compiler who cause the problem. I would try an early version of RI 1.5.0, but currently I can not find one. On 6/7/06, Andrew Zhang wrote: Hello Stepan and Mikhail, All tests passed on my machine. Which test case was failed in your environment, on RI or Harmony? Thanks! On 6/7/06, Stepan Mishura [EMAIL PROTECTED] wrote: Hi Tim, On 6/7/06, Tim Ellison wrote: Heads up that I completed the implementation of j.l.Enum today; so you can go mad and use enum types in classlib code for real now. Cool! I wrote a bunch of tests but if you could hammer on it and try to break it that would be good :-) And did you run it? :-) It fails for me :-( Thanks, Stepan. If you take a look at the implementation [1] of valueOf(Class, String) it uses reflection to get the enum constant values. I'm not sure how 'popular' the valueOf() method is, but since the values don't change they are a good candidate for being cached if it proves to be called frequently. I'm happy to do that if people think it is worthwhile. Regards, Tim [1] http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java/lang/Enum.java?revision=412166view=markup -- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] Enum ready to go
commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [announce] New Apache Harmony Committer : Nathan Beyer
Geir Magnusson Jr wrote: Please join the Apache Harmony PPMC in welcoming the project's newest committer, Nathan Beyer. Nathan has shown sustained dedication to the project, an ability to work well with others, and share the common vision we have for Harmony. We all continue to expect great things from him. Nathan, as a first step to test your almighty powers of committership, please update the committers page on the website. That should be a good (and harmless) exercise to test if everything is working. Things to do : 1) test ssh-ing to the server people.apache.org. 2) Change your login password on the machine as per the account email 3) Add a public key to .ssh so you can stop using the password 4) Set your SVN password : just type 'svnpasswd' At this point, you should be good to go. Checkout the website from svn and update it. See if you can figure out how. Also, for your main harmony/enhanced/classlib/trunk please be sure that you have checked out via 'https' and not 'http' or you can't check in. You can switch using svn switch. (See the manual) Finally, although you now have the ability to commit, please remember : 1) continue being as transparent and communicative as possible. You earned committer status in part because of your engagement with others. While it was a have to situation because you had to submit patches and defend them, but we believe it is a want to. Community is the key to any Apache project. 2)We don't want anyone going off and doing lots of work locally, and then committing. Committing is like voting in Chicago - do it early and often. Of course, you don't want to break the build, but keep the commit bombs to an absolute minimum, and warn the community if you are going to do it - we may suggest it goes into a branch at first. Use branches if you need to. 3) Always remember that you can **never** commit code that comes from someone else, even a co-worker. All code from someone else must be submitted by the copyright holder (either the author or author's employer, depending) as a JIRA, and then follow up with the required ACQs and BCC. Again, thanks for your hard work so far, and welcome. The Apache Harmony PPMC - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Congratulations! :) -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Intention to work on Pack200 uncompressor/compressor
Alex Blewitt wrote: On 26/05/06, Jimmy, Jing Lv [EMAIL PROTECTED] wrote: I know little about Mac, though I love its appearance :) I wonder if you would write the implementation by pure java or native code. IMHO, write them in native may be a help in performance, and maybe easy to merge (And we see, RI create a excuteable pack200.exe in its jre). The code can be put in native-src\(win.IA32/share/Linux.IA32/Mac?) \archive, naming pack200.c or so. I'm aiming to implement it in pure Java, because one of the other goals is to allow other clients (e.g. Eclipse) to be able to bundle the pack/unpack code. To tell the truth, I was interested in it and planning until something defers my plan. Why I planed to wrote it into native was that: 1. C code of such arithmetic may be faster and 2. Harmony may also contain a executable Pack200 as RI does. And to allow Eclipse-like clients to bundle the code, maybe you can use JNI to port the native codes into Java. IMHO it'll be easy. However I'm just suggesting, it all depends on you. :) BTW, I don't know if Harmony can be run on Mac currently. However, that is an aim :) Yes, it certainly is :-) You may document the interpret of the algorithm, and offer some testcases :) Actually, it would be good to have some packed Jars that I could then test my unpacking algorithm on. Does anyone know if I can run the Sun-supplied packer to compress Jar files and then use that as an input into my unpacker algorithm? I'm guessing it's OK to do that, but I need to be able to demonstrate that I've not used any internal knowledge of the implementation to achieve the goal of a clean-room implementation. The other alternative is for others to pack some simple Jars, and then verify that the unpacking algorithm works independently -- but I could use some sample 'hello world' type Jars for my own testing. As far as I understand the algorithm, it was a little complex and may take a period of time to implement. So good luck, and let's discuss on mailing-list if there's something hard. :) It's certainly fun :-) Most of the encodings are variable length, which makes it fun for trying to run through a compressed Jar (it also means that I have to complete the unpacker for the first bits before I can work on unpacking the remainder). Yes, algorithm-analysis and coding are really fun, especially in such community like Harmony. Let's enjoy it :) Mind you, one neat feature (which I didn't appreciate before) is that the algorithm is designed such that you can concatenate two pack200 files together and it's still a valid file. So you can pack a bunch of Jars independently, and then concatenate them all into one big file for subsequent compression/transmission. Alex. -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] jetty based tests
- will the test suite run slow down if we'll use jetty instead of mock objects? How much? 3) Testing Quoting Tim from 'local server thread': There is no way to force a server to send you a chunked response using regular HTTP headers, so in this case the server and client have an understanding that when the client asks for a particular resource the server will send it back in chunks. With mock objects this can be done with no problems and HARMONY-164 demonstrates the possible way. Also are we going to create negative tests, for example, for broken server response? I think yes. Can jetty server be used for negative testing? See other comments below On 5/22/06, George Harley wrote: Stepan Mishura wrote: On 5/19/06, Tim Ellison wrote: Stepan Mishura wrote: snip I'm OK only if we separate tests with Jetty from common test suite run. Why? Because each external dependency complicates 'normal' test suite run ( I don't want to face with situation when to run Harmony test suite I have to configure and run 20 different external servers even they are easy configurable). As far as I remember we agreed to use mock objects - so let's use them! For example, in this case there is no need in jetty server. I'm not against 'jetty based tests' but I'd prefer to separate such tests. Thanks, Stepan. Hi Stepan, Just seen this note and think that my previous append on the Re: svn commit: r407752 thread sums up my thoughts. Allow me to quote myself: paste Jetty or equivalent is a good basis for such local server stubs. It is fast, it is lightweight, Fast and lightweight as what? I saw sometimes ago java server that has jar size 4k. And jetty-6.0.0beta6.jar is 423k size. it can be started and stopped very simply from within Ant (so that it only runs for the duration of a specified batch of unit tests) and may also be completely controlled from Java test code so that we can configure its behaviour for any test case from within that test case. Good. It's architecture means that we do not have to run it as a complete web server but can stub out any aspect of its runtime behaviour we wish in order to suit the purposes of the test(s). What about 'chunked response'? Can a testcase force jetty server to send it a chunked response? I don't really understand why such network tests making use of a small, embedded server running locally would need to be considered as outside of the normal test flow. /paste Because I consider adding jetty server as precedent for adding other dependencies to the normal test flow. I believe that normal test flow should be fast and lightweight as much as possible. Each additional dependency or configuration step adds a brick(even it light) to developer's large. As the result classlib test suite may become very slow and hard to configure. All I want is to understand - do we really need jetty server inside it. Thanks, Stepan. We are not talking about an external server here and we are not talking about developers having to carry out complex configuration manoeuvres when running the tests. That is something that nobody wants. The motivation here is purely to get more of the java.net tests out of the excludes sin bin. Best regards, George Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. -- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Intention to work on Pack200 uncompressor/compressor
Alex Blewitt wrote: Hi everyone, I'd like to start work on an implementation of the pack200 decompression algorithm, from the specification which is available at http://www.jcp.org/aboutJava/communityprocess/first/jsr200/ I shall give you a warm welcome for implementation of Pach200! :) But as I know few about the legality, I wonder it is legal for us(Harmony developers) to read such algorithm directly from jcp.org? Can anyone give an answer? Let's go ahead if there's no obstacle. The actual java class/interface is relatively simple, but the implementation behind the unpack() and pack() methods decidedly isn't :-) My goal will be to provide the unpacking algorithm first, and then work on a packer subsequently. I'll probably try to write it in an o.a.h module first, and then hook it into the java.util.jar classes/packages later. Yes, we have a Pack200.java in java.util.jar, and can write its implementation in a internal pachage. According to Tim's guidance: http://incubator.apache.org/harmony/subcomponents/classlibrary/pkgnaming.html a naming of org.apache.harmony.util.jar .internal maybe appropriate. And there's a package private factory class PackFactory, for hooking the implementation class. You may read them for more information for how to initialation. The only problem is that I'm building this on a Mac (primarily) and so I don't have the ability to download the IBM VM for bootstrapping the VM process (though a later task is to see if I can help with the migration of the VM to Mac OS X). Can I develop it against the Java 1.4 on my machine for the o.a.h module first, and then contribute it in stages? I know little about Mac, though I love its appearance :) I wonder if you would write the implementation by pure java or native code. IMHO, write them in native may be a help in performance, and maybe easy to merge (And we see, RI create a excuteable pack200.exe in its jre). The code can be put in native-src\(win.IA32/share/Linux.IA32/Mac?) \archive, naming pack200.c or so. BTW, I don't know if Harmony can be run on Mac currently. However, that is an aim :) The other problem is that the API is pretty sparse; the packer either unpacks, or it doesn't :-) So from a contribution point of view, there may not be much to publically show, but I'd like (if possible) to have some of the implementation work made available as I go, in case anyone else wants to help out :-) You may document the interpret of the algorithm, and offer some testcases :) I'd also like to try and design the implementation such that it could be downloaded and used by other OSGi implementations (e.g. Eclipse). If someone can give me some advice as to a suitable package name I can make an initial start on an implementation, and then in stages can post it to Jira. As far as I understand the algorithm, it was a little complex and may take a period of time to implement. So good luck, and let's discuss on mailing-list if there's something hard. :) Thanks, Alex. -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Repackaged IBM VME
Oliver Deakin wrote: Hi all, There is now a repackaged version of the IBM VME available at: https://www14.software.ibm.com/webapp/iwm/web/preLogin.do?lang=en_USsource=ahdk The new VME archives are called Harmony-vme-win.IA32-v3.zip for Windows and Harmony-vme-linux.IA32-v3.tar.gz for Linux. Following discussion on the mailing list [1], the IBM VME has been reorganised into the following directory layout: EXTRACT_DIR | +---jre || |\---bin | | | \---default | \---vme_license The actual VME binaries are still the same as the previous version, but the new layout means it can be dropped into both the current development environment and also any future classlib jre/jdk/hdk snapshots that are taken. Since this is purely a directory layout update, those who already have a version of the IBM VME in their environment will *not* need to get the new packages. Regards, Oliver [1] http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200605.mbox/[EMAIL PROTECTED] That's great! And we are solicitous of a new VM of Java 5. :) -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] resource files for testing serialization - location and name?
Stepan Mishura wrote: On 5/18/06, Jimmy, Jing Lv wrote: Stepan Mishura wrote: SNIP 4)Resource file name MUST contain some index. In general, a test may use a set of resource files To summarize: for test org.apache.harmony.tests.java.lang.SomeClassTestwe have the following structure modules/luni/src/test/resources org/apache/harmony/tests/java/lang SomeClassTest.golden.0.ser SomeClassTest.golden.1.ser SomeClassTest.golden.2.ser SomeClassTest.harmony.0.ser SomeClassTest.harmony.1.ser For they are ser-files of a certain class, why not name it with the class's name, e.g. someclass.X.X.ser? We may wish to create a number of tests for a class with names like SomeClass1Test, SomeClass2Test So it will be clear from ser-file name which test use it if the ser-file name starts with test's name. In the discussion we have a position for index in the name, maybe it is better to use that. .ser suggests it is a ser-file of one class, after all it is not the ser-file of the test itself, right? :) However IMHO, in most cases, we need no more than two ser-files (one for RI and one for Harmony). Add more postfix seems unnecessary. Is that OK if we have only two file, we just name them as SomeClass.harmony/RI.ser? And if there's only one ser-file, just name it as someclass.ser? Thanks, Stepan -- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] resource files for testing serialization - location and name?
Stepan Mishura wrote: Hi, During the last discussion no agreements were made - though it was very useful for me. And I'd like to start new round for serialization testing. I want to define rules for locating and naming resource files for serialization. There is only agreement that we put all files for testing serialization to folder: modules/module name/src/test/resources/ and I'd like to work out a rules where to locate ser files for a test inside that folder and how to name them. I want to propose the following rules: 1)Path to resource files MUST match a test's package I think it will be easier to find all test's resource files. 2)Resource file name MUST starts with a test's name IMHO, it should be clear from resource file name which test use it 3)Resource file name MUST contain keywords pointing out to implementation Keyword is intended to signal on which implementation a resource file was generated – so we can track Harmony backward compatibility and compatibility with RI. For example, for files generated on RI we may use 'golden' keyword and for Harmony – 'harmony'. 4)Resource file name MUST contain some index. In general, a test may use a set of resource files To summarize: for test org.apache.harmony.tests.java.lang.SomeClassTest we have the following structure modules/luni/src/test/resources org/apache/harmony/tests/java/lang SomeClassTest.golden.0.ser SomeClassTest.golden.1.ser SomeClassTest.golden.2.ser SomeClassTest.harmony.0.ser SomeClassTest.harmony.1.ser For they are ser-files of a certain class, why not name it with the class's name, e.g. someclass.X.X.ser? Thanks, Stepan Mishura Intel Middleware Products Division -- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Supporting working on a single module?
/ ... and alter build scripts? Perhaps only scripts are important to rewrite. If I am right, what we really need is: we can download one single module native source, e.g., Luni, and all other stubs, libs, DLL/so files or something, then modify Luni native source, and build them all and create a new hyluni.dll/so. In this way we no longer need to download other source code besides Luni but still get a success build. 2) Alter the global build scripts to start creating an hdk under the deploy directory, which contains a jdk which contains a jre. As Mark described before, this hdk would probably look something like: deploy/hdk/ |jdk/ | |---jre/(already being created at the moment as deploy/jre) | +--include/(already being created at the moment as deploy/include) |include/ +---lib/ The hdk/include directory would be much like the current native-src/platform/include directories, and would contain a minimal set of header files that define an interface between native modules. It would be the responsibility of the individual module to copy its required headers to this directory as a prerequisite for building. The hdk/lib directory would exist on Windows platforms, and would contain .lib files for each native component. An hdk snapshot would then be a zip of the hdk directory, and should provide everything necessary for a developer to build both native and Java code against. 3) Modularise native and Java build scripts so that the individual module's Ant scripts are capable of building native and Java source against an hdk, rather than having its code compiled as part of a global build. The rebuilt libraries would be placed back into the hdk directory, so that the developers local hdk always contains their latest built code (much as the current deploy/jre does). Additionally, I agree with Nathan [2] that allowing a developer working in a modular way to run the entire test suite against their work-in-progress code would be a good thing, and this could be done by bundling tests and their resources in with an hdk. Regards, Oliver [1] http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200602.mbox/[EMAIL PROTECTED] [2] http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200605.mbox/[EMAIL PROTECTED] -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] Exception throwing compatibility
Stepan Mishura wrote:
On 5/12/06, Jimmy, Jing Lv wrote:
Mikhail Fursov wrote:
I agree that the easiest way for us is to throw RI or subclass.
+1.
Is it 'bad' practice to fix this bug (replace subclass with RI) on
user
request and do not think about this problem today?
In this case, though replace StringIndexOutOfBoundsException with
ArrayIndexOutOfBoundsException is surely better, it seems it is internal
implementation what cause the problem. According to the code it use
String.valueof(str), which writes:
try {
System.arraycopy(data, start, value, 0, count);
} catch (IndexOutOfBoundsException e) {
throw new StringIndexOutOfBoundsException();
}
IMHO this try-catch block is redandunt - the method code already contains
checks to verify that all parameters are valid:
if (start = 0 0 = length length = data.length - start) {
else
throw new StringIndexOutOfBoundsException();
I believe you are right, but there may be some reasons for the author
to write such try{...}catch(){}, perhaps he do follow RI's exception in
the class String.
Is it right to StringIndexOutOfBoundsException in String.valueof()? Then
to fix this, we shall write another
try{ ...
}catch(StringIndexOutOfBoundsException){
throw new ArrayIndexOutOfBoundsException();
}
It is not so beautiful...
Hmm, there is also no need in try-catch block, so the code should looks
like
the following:
if( parameters are invalid ){
throw new ArrayIndexOutOfBoundsException();
}
return append(String.valueof());
Thanks,
Stepan.
However according to
http://incubator.apache.org/harmony/subcomponents/classlibrary/compat.html
it has already draw a conclusion that:
1) throw according to spec
2) when we discover RI throw difference exception which is not internal
class, follow RI.
What real matters is how can developers know what RI throws exactly in
all situations? Maybe a possible solution is that we fix one by one only
when we find the difference.
On 5/11/06, Richard Liang [EMAIL PROTECTED] wrote:
George Harley wrote:
Hi,
I would like to start a little discussion around JIRA issue 436 [1]
which deals with exception throwing compatibility between Harmony
and
the RI. I feel it is important to reach a concrete agreement on this
as so far all of the participants in the issue seem to disagree
about
the interpretation of the compatibility guidelines on our web site
[2].
You can read the discussion for yourself on the JIRA page (it is
only
a handful of comments) but if you are pressed for time the
essentials
are this (IMHO - Nathan and Dmitry please feel free to fill in the
gaps) :
* Currently the Harmony implementation of a few public methods in
StringBuffer and StringBuilder throw different runtime exceptions
from
the RI under certain failure scenarios.
* Where the Javadoc mentions the exception type that ought to be
thrown it mentions a type (j.l.IndexOutOfBoundsException) but the
Harmony and RI implementations differ in that they are throwing
different *sub-types* of j.l.IndexOutOfBoundsException. The RI tends
to throw j.l.ArrayIndexOutOfBoundsException while Harmony tends to
throw j.l.StringIndexOutOfBoundsException.
* Dmitry (who raised the issue) believes that we should change the
Harmony code to throw the type named in the Javadoc/specification
(i.e. the supertype j.l.IndexOutOfBoundsException).
* Nathan believes that the code already abides by the specification
and that there is no need for any change in this area.
* Little old me thinks that there *is* a problem here but that the
solution is to do as the RI does and throw exceptions with the very
same runtime type as the RI. That's based on my interpretation of
the
exception-throwing compatibility guidelines [2], in particular the
fragment Harmony class library code should throw exceptions of the
same type as the RI.
If I recall correctly we did agree to discuss such compatibility
matters on a case-by-case basis. So, dear reader, what do you think
is
the correct course of action in this case ?
Best regards,
George
[1] http://issues.apache.org/jira/browse/HARMONY-436
[2]
http://incubator.apache.org/harmony/subcomponents/classlibrary/compat.html
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
Hello,
Let me support Mikhail we should throw either what RI throws or a
sub-class.
--
Richard Liang
China Software Development Lab, IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Best Regards!
Jimmy, Jing Lv
China Software Development
Re: [classlib] Exception throwing compatibility
Chris Gray wrote:
More generally, from a performance point of view it is best not to write
if (index 0 || index = array.length || etc. etc.) {
throw new FooIndexOutOfBoundsException();
}
if there is a method call or an array access which will throw the exception
anyway. (Many null parameter checks can be omitted for the same reason).
Looks like Sun have followed this policy, and dealt with the not-quite-right
exception type by fudging the spec to throw the common supertype. :-
That hits the point. What RI throws is natural, just because they write
that way. However we will never know what RI writes, we just implement
the spec in our way, that's why there are many
if(...){
throw new exception();
}
and
try{
...
}catch(){
throw new exception();
}
in Harmony.
After all, our mission is to make it compatible, right? :)
Chris
On Friday 12 May 2006 09:11, Mikhail Fursov wrote:
Note that this is not only beautiful but also performance oriented way -
do not create extra rethrows if it's possible
On 5/12/06, Semukhina, Elena V [EMAIL PROTECTED] wrote:
To have a beautiful fix, why don't you just write
System.arraycopy(data, start, value, 0, count);
without trying to catch any exception and rethrow another one?
ArrayIndexOutOfBoundsException, if happened, would be thrown by
System.arraycopy().
--
Best Regards!
Jimmy, Jing Lv
China Software Development Lab, IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] Exception throwing compatibility
Mikhail Fursov wrote:
I agree that the easiest way for us is to throw RI or subclass.
+1.
Is it 'bad' practice to fix this bug (replace subclass with RI) on user
request and do not think about this problem today?
In this case, though replace StringIndexOutOfBoundsException with
ArrayIndexOutOfBoundsException is surely better, it seems it is internal
implementation what cause the problem. According to the code it use
String.valueof(str), which writes:
try {
System.arraycopy(data, start, value, 0, count);
} catch (IndexOutOfBoundsException e) {
throw new StringIndexOutOfBoundsException();
}
Is it right to StringIndexOutOfBoundsException in String.valueof()? Then
to fix this, we shall write another
try{ ...
}catch(StringIndexOutOfBoundsException){
throw new ArrayIndexOutOfBoundsException();
}
It is not so beautiful...
However according to
http://incubator.apache.org/harmony/subcomponents/classlibrary/compat.html
it has already draw a conclusion that:
1) throw according to spec
2) when we discover RI throw difference exception which is not internal
class, follow RI.
What real matters is how can developers know what RI throws exactly in
all situations? Maybe a possible solution is that we fix one by one only
when we find the difference.
On 5/11/06, Richard Liang [EMAIL PROTECTED] wrote:
George Harley wrote:
Hi,
I would like to start a little discussion around JIRA issue 436 [1]
which deals with exception throwing compatibility between Harmony and
the RI. I feel it is important to reach a concrete agreement on this
as so far all of the participants in the issue seem to disagree about
the interpretation of the compatibility guidelines on our web site [2].
You can read the discussion for yourself on the JIRA page (it is only
a handful of comments) but if you are pressed for time the essentials
are this (IMHO - Nathan and Dmitry please feel free to fill in the
gaps) :
* Currently the Harmony implementation of a few public methods in
StringBuffer and StringBuilder throw different runtime exceptions from
the RI under certain failure scenarios.
* Where the Javadoc mentions the exception type that ought to be
thrown it mentions a type (j.l.IndexOutOfBoundsException) but the
Harmony and RI implementations differ in that they are throwing
different *sub-types* of j.l.IndexOutOfBoundsException. The RI tends
to throw j.l.ArrayIndexOutOfBoundsException while Harmony tends to
throw j.l.StringIndexOutOfBoundsException.
* Dmitry (who raised the issue) believes that we should change the
Harmony code to throw the type named in the Javadoc/specification
(i.e. the supertype j.l.IndexOutOfBoundsException).
* Nathan believes that the code already abides by the specification
and that there is no need for any change in this area.
* Little old me thinks that there *is* a problem here but that the
solution is to do as the RI does and throw exceptions with the very
same runtime type as the RI. That's based on my interpretation of the
exception-throwing compatibility guidelines [2], in particular the
fragment Harmony class library code should throw exceptions of the
same type as the RI.
If I recall correctly we did agree to discuss such compatibility
matters on a case-by-case basis. So, dear reader, what do you think is
the correct course of action in this case ?
Best regards,
George
[1] http://issues.apache.org/jira/browse/HARMONY-436
[2]
http://incubator.apache.org/harmony/subcomponents/classlibrary/compat.html
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Hello,
Let me support Mikhail we should throw either what RI throws or a
sub-class.
--
Richard Liang
China Software Development Lab, IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Best Regards!
Jimmy, Jing Lv
China Software Development Lab, IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] matching RI exceptions -- are we required to have this type of compatibility?
Anton Avtamonov wrote:
On 4/25/06, Dmitry M. Kononov [EMAIL PROTECTED] wrote:
On 4/25/06, Tim Ellison [EMAIL PROTECTED] wrote:
Jimmy, Jing Lv wrote:
I agree.
But there are at least two exceptional situation:
1) several exceptions throws from one method, which extend one parent
class, e.g. ConnectionException and UnknownHostException, javadoc writes
throws IOException rather than throws
ConnectionException,UnknownHostException. And in implementation, we
shall throw them out directly instead of
try{...
}catch(UnknownHostException e){
throw new IOException();
}
catch(ConnectionException e){
throw new IOException();
}
right? :)
+1, and other instances where super-types or super-interfaces declare
compatible throws clauses that are implemented in subclasses that throw
more specific subtypes. I do not agree that we should be bound to throw
and exception of the identical type as the declaration.
If we want to follow the spec and if we want to restrain ourself from
improving the spec, I think we really need to throw IOException. If
this exception can be caused by different ways we apparently have to
throw IOException with an appropriate cause.
From the general perspective, in the example above re-throwing
IOException looks quite ugly. Besides, it hides some important
information (since Java uses exception sub-classing to represent the
particular type of problem). However we are not free with design, I
think. Could someone please remind me an idea: for the example above
do we mean that the spec states IOException and RI throws exactly
IOException (I traversed the thread, but still not sure what was
meant)?
For the example 1) I mean the spec usually merge several exceptions into
one parent exception. In this situation, commonly RI throws child
exception itself, although it is hard to tell what RI exactly throw in
some special situation.
And I think we are not improving the spec if we throw child
exceptions, it is just convention or something writing throws
IOException instead of writing throws connectionException,
UnknownHostException. We do follow spec if we throw child exception.
The idea behind the question is: why not just copy RI in this case
(conforming Tim's guidelines)?
Yes,I firmly agree with Tim's guidelines. We should first follow spec
and then RI. In this case, we still follow the spec, right? :)
--
Anton Avtamonov,
Intel Middleware Products Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Best Regards!
Jimmy, Jing Lv
China Software Development Lab, IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] matching RI exceptions -- are we required to have this type of compatibility?
Geir Magnusson Jr wrote:
Vladimir Gorr wrote:
Mikhail,
I also thought about this scenario. However, if any TCK tests will
fail due
to this reason
we cannot certify our product. Nobody will talk about the invalidity
of TCK.
Most likely we will update our sources.
1) I hadn't thought about this before, but it seems much cleaner to
throw A (rather than B extends A) if the spec says to throw A.
I agree.
But there are at least two exceptional situation:
1) several exceptions throws from one method, which extend one parent
class, e.g. ConnectionException and UnknownHostException, javadoc writes
throws IOException rather than throws
ConnectionException,UnknownHostException. And in implementation, we
shall throw them out directly instead of
try{...
}catch(UnknownHostException e){
throw new IOException();
}
catch(ConnectionException e){
throw new IOException();
}
right? :)
2) and we may find some javadoc as ...then an unspecified error is
thrown. For an example, in java.util.jar.Pack200.newPacker(). We can do
nothing to meet such compatibility.
In summary, I think we shall follow doc in throwing exception; but if we
find it inconvenient indeed or even impossible, let it be. :)
2) You can challenge TCK tests and have them eliminated. We've done it
for J2EE and other specs. I believe that we're going to be in for quite
a bit of it because for all practical purposes, we'll be the first use
of the TCK on an independent implementation of Java SE.
geir
Thanks,
Vladimir.
On 4/24/06, Mikhail Loenko [EMAIL PROTECTED] wrote:
There is nothing about TCK here: if the spec requires to throw A
and we throw B that extends A then we follow the spec
And if there is a TCK test that verifies that we throw A and only A
then the test is invalid and we will not have to pass it
Sometimes it is an easy fix to throw A rather then B.
But there could be two RI methods - one throwing A and another one
throwing B
such that in our implementation they both refer to some third method.
In this case if we throw B in that 3rd method - then we conform the
spec,
we won't break existing apps and it might cause design weakening
if we choose to go coping how RI works.
So if the fix is easy then I'd agree to what folks say here, but in
general case
I'd not set the rule to follow RI this way.
Thanks,
Mikhail
2006/4/24, Vladimir Gorr [EMAIL PROTECTED]:
The answer to this question (in my opinion) depends on how TCK
processes
similar situations.
If we want to successfully perform this suite on Harmony we should be
compatible with RI.
For certain there are a lot of tests into TCK will fail due to this
reason
and we should be ready for this.
Thanks,
Vladimir.
On 4/24/06, Mikhail Loenko [EMAIL PROTECTED] wrote:
Look at HARMONY-387.
Example:
1) java.io.ByteArrayOutputStream.write(byte[] b , int off, int len):
Harmony throws ArrayIndexOutOfBoundsException when off0 or/and len
0, while RI throws IndexOutOfBoundsException.
Specification mentions neither ArrayIndexOutOfBoundsException nor
IndexOutOfBoundsException.
Actually ArrayIndexOutOfBoundsException is a sub class of
IndexOutOfBoundsException.
So the statement both Harmony and RI throw IndexOutOfBoundsException
is
true.
But do we have to throw exactly those exceptions that are thrown by
RI?
Can we throw
o.a.h.VMRisenNPE that extends NullPointerException?
What if they throw kind of
sun.internal.SunFavoriteSubClassOfNullPointerException ?
Thanks,
Mikhail
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Best Regards!
Jimmy, Jing Lv
China Software Development Lab, IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: should strings in exceptions match the reference implementation?
Anton Avtamonov wrote: On 4/18/06, Mark Hindess [EMAIL PROTECTED] wrote: I thought my first message in this thread made this clear but obviously not. I'm not suggesting that code would care if the exception messages are identical. I was suggesting that it is probably now quite common for users to type error messages straight in to google. Therefore having messages match those of existing implementations would help our users find the cause of an exception. Er... that really matters. So shall we start write a list of such messages and give a little more information, and then put it on webpages or wiki, and then as a result, every user of Harmony get a result if he google? There can be more solutions. However it can not be the reason that we should match the string with RI, as many user also copy exception track trace to google, so there'll be com.ibm... or com.sun... or something else if they use RI, Harmony shall never match them, right? :) Yes, right. I saw several times like people did that and even did by myself for javac. If I remember we decided not to copy the mesages because it is *possibly* a legal isssue and maybe copyrightable. Is it possible to ask apache legal? Probably the answer will solve our problems :-). That's the point. Agree. Wishes, -- Anton Avtamonov, Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: assertEquals in tests with incorrect argument order
Hi Geir: Sorry for that, I'm trying Mozilla Thunderbird instead of Gmail on firefox, perhaps I've mis-displaced something. It looks proper on my Gmail. Try to fix it , shall I add a ? Geir Magnusson Jr wrote: Can you fix your mailer so that it quotes properly? Down below, you wrote Good idea. :) and Mark wrote I'm going to submit and they have the same level of quoting... we can't follow the thread... thanks geir LvJimmy，Jing wrote: 2006/4/17, Mark Hindess [EMAIL PROTECTED]: Another type of test that could be improved are those using assertTrue to compare two objects for equality. Most of them should be using assertEquals, assertNull or assertNotNull. Using assertEquals automatically gives more meaningful error messages. It saves people writing asserts like: assertTrue(Size should return 100, returned: + map.size(), map.size() == 100); when this would do just as well: assertEquals(Incorrect size, 100, map.size()); Good idea. :) I'm going to submit a few (big) patches to fix some of these. I think there's a lot of them, even, few of our testcases is written in this style, so, good luck :) Anyway, we can discuss about this, and see if we can agree on some convention. Regards, Mark. On 4/15/06, Mark Hindess [EMAIL PROTECTED] wrote: Trying to fix/enable the PatternSyntaxExceptionTest (HARMONY-352) was quite confusing. If you get the arguments to assertEquals the wrong way around you get errors like: error expected actual but got expected rather than: error expected expected but got actual The correct way around is to have the expected value before the actual value. We should all try make sure we get the arguments to assertEquals in the correct order. And fix any we spot that are the wrong way around. ;-) I've fixed a few of the more obviously incorrect method calls in HARMONY-353. Regards, Mark. -- Mark Hindess [EMAIL PROTECTED] IBM Java Technology Centre, UK. -- Mark Hindess [EMAIL PROTECTED] IBM Java Technology Centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
