Re: [vote] acceptance of HARMONY-609 : AWT, Java2D, Swing TESTS
+1 -Stepan. On 7/6/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: All is in order and in SVN for Harmony-609 wrt BCC and ACQ. Please vote to accept or reject this codebase into the Apache Harmony class library : [ ] + 1 Accept [ ] -1 Reject (provide reason below) Lets let this run a minimum of 3 days unless a) someone states they need more time or b) we get all committer votes before then. geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] acceptance of HARMONY-536 : JSEE provider contribution
+1 -Stepan. On 7/6/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: All is in order and in SVN for Harmony-536 wrt BCC and ACQ. Please vote to accept or reject this codebase into the Apache Harmony class library : [ ] + 1 Accept [ ] -1 Reject (provide reason below) Lets let this run a minimum of 3 days unless a) someone states they need more time or b) we get all committer votes before then. geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r419293 - in /incubator/harmony/enhanced/drlvm/trunk/build: build.bat build.sh make/lnx.properties make/setup.xml make/win.properties
Hi all.
The DRLVM build is broken for the last two days because of the absence
of org/apache/xml/serializer/SerializerTrace in the ant classpath.
I've open the JIRA issue HARMONY-795 about this. The problem is that
this class was in serializer.jar that was removed after this commit.
And this class is absent in xalan.jar (whicj DRLVM build takes) and
present in classlib xalan.jar. Xalan's (in DRLVM and classlib) are
taken from the different places.
This issue was not mentioned till now I think, because a lot of people
use their own xalan (with serializer), just stored in ant/lib. So
there are no errors when building such way.
I think that the better soltion is to use the classlib xalan.jar
unstead the old one in DRLVM build.
Thanks.
--
Nataly Naumova,
Intel Middleware Products Division
On 7/5/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Author: hindessm
Date: Wed Jul 5 10:31:18 2006
New Revision: 419293
URL: http://svn.apache.org/viewvc?rev=419293view=rev
Log:
Removing a couple of references to things removed by [#HARMONY-753] DRLVM
build cleanup: remove some of classlib tasks.
Modified:
incubator/harmony/enhanced/drlvm/trunk/build/build.bat
incubator/harmony/enhanced/drlvm/trunk/build/build.sh
incubator/harmony/enhanced/drlvm/trunk/build/make/lnx.properties
incubator/harmony/enhanced/drlvm/trunk/build/make/setup.xml
incubator/harmony/enhanced/drlvm/trunk/build/make/win.properties
Modified: incubator/harmony/enhanced/drlvm/trunk/build/build.bat
URL:
http://svn.apache.org/viewvc/incubator/harmony/enhanced/drlvm/trunk/build/build.bat?rev=419293r1=419292r2=419293view=diff
==
--- incubator/harmony/enhanced/drlvm/trunk/build/build.bat (original)
+++ incubator/harmony/enhanced/drlvm/trunk/build/build.bat Wed Jul 5 10:31:18
2006
@@ -126,7 +126,6 @@
SET CLASSPATH=%CLASSPATH%;.\make\tmp\jdtCompilerAdapter.jar
SET CLASSPATH=%CLASSPATH%;.\make\tmp\junit.jar
SET CLASSPATH=%CLASSPATH%;.\make\tmp\xalan.jar
-SET CLASSPATH=%CLASSPATH%;.\make\tmp\serializer.jar
SET CLASSPATH=%CD%\make\tmp\cpptasks\patched.classes;%CLASSPATH%
SET CLASSPATH=.\make\tmp\ant-contrib.jar;%CLASSPATH%
Modified: incubator/harmony/enhanced/drlvm/trunk/build/build.sh
URL:
http://svn.apache.org/viewvc/incubator/harmony/enhanced/drlvm/trunk/build/build.sh?rev=419293r1=419292r2=419293view=diff
==
--- incubator/harmony/enhanced/drlvm/trunk/build/build.sh (original)
+++ incubator/harmony/enhanced/drlvm/trunk/build/build.sh Wed Jul 5 10:31:18
2006
@@ -77,7 +77,6 @@
CLASSPATH=$CLASSPATH:`pwd`/make/tmp/jdtCompilerAdapter.jar
CLASSPATH=$CLASSPATH:`pwd`/make/tmp/junit.jar
CLASSPATH=$CLASSPATH:`pwd`/make/tmp/xalan.jar
-CLASSPATH=$CLASSPATH:`pwd`/make/tmp/serializer.jar
CLASSPATH=`pwd`/make/tmp/cpptasks/patched.classes:$CLASSPATH
CLASSPATH=`pwd`/make/tmp/ant-contrib.jar:$CLASSPATH
export CLASSPATH
Modified: incubator/harmony/enhanced/drlvm/trunk/build/make/lnx.properties
URL:
http://svn.apache.org/viewvc/incubator/harmony/enhanced/drlvm/trunk/build/make/lnx.properties?rev=419293r1=419292r2=419293view=diff
==
--- incubator/harmony/enhanced/drlvm/trunk/build/make/lnx.properties (original)
+++ incubator/harmony/enhanced/drlvm/trunk/build/make/lnx.properties Wed Jul 5
10:31:18 2006
@@ -78,15 +78,6 @@
# http://archive.apache.org/dist/xml/xalan-j
remote.XALAN.archive=http://www.reverse.net/pub/apache/xml/xalan-j/xalan-j_2_7_0-bin.zip
-# BouncyCastle Crypto API
-# http://www.bouncycastle.org/download/bcprov-jdk14-129.jar
-remote.BCPROV.archive=http://www.bouncycastle.org/download/bcprov-jdk14-129.jar
-remote.BCPROV.archive.type=asis
-
-# Apache common resolver xml utils
-# http://www.reverse.net/pub/apache/xml/commons/xml-commons-resolver-1.1.zip
-remote.RESOLVER.archive=http://www.reverse.net/pub/apache/xml/commons/xml-commons-resolver-1.1.zip
-
# Location for VM sources (can be handy if building different versions of VM)
VM_HOME=../../vm
PATCHES_HOME=../patches
Modified: incubator/harmony/enhanced/drlvm/trunk/build/make/setup.xml
URL:
http://svn.apache.org/viewvc/incubator/harmony/enhanced/drlvm/trunk/build/make/setup.xml?rev=419293r1=419292r2=419293view=diff
==
--- incubator/harmony/enhanced/drlvm/trunk/build/make/setup.xml (original)
+++ incubator/harmony/enhanced/drlvm/trunk/build/make/setup.xml Wed Jul 5
10:31:18 2006
@@ -165,19 +165,6 @@
propertyregex property=build.XALAN.path input=${if.XALAN.exist}
regexp=(.*)/${XALAN.check.file} select=\1 /
copy file=${build.XALAN.path}/xalan.jar todir=tmp /
-fail
-condition
-not
-available file=${build.XALAN.path}/serializer.jar /
-/not
-/conditionError:
-* Your
Re: portlib functionality
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
Re: portlib functionality
And the short answer is yes. The additional file system functionality such as file locking and memory mapping required by the (newly authored within this project) NIO code should be put into the port library. And what about hythread platform-dependent code? Have the thread and process routines to be the part of the portlib? Marina
Re: [classlib] debug compilation as default
On 7 July 2006 at 2:25, Ivan Volosyuk [EMAIL PROTECTED] wrote: On 7/7/06, Gregory Shimansky [EMAIL PROTECTED] wrote: On Friday 07 July 2006 01:28 Ivan Volosyuk wrote: I'm happy with release and debug but the top-level interface (and the module-level interface too for that matter) is ant - make should not be called directly - so it will probably need to be an ant property. I was thinking: 1) adding a 'hy.native.cfg' property to make/properties.xml The drlvm build already has ant property called build.cfg and build.cxx for the debug or release build and the compiler name. The properties is initialized from BUILD_CFG and CXX environment variables. IMHO, it will be convenient to have the same property for drlvm and classlib build. Is it ok to have _this_ property names? I don't think the word 'native' in property make sense as this switch can be used somehow even in java build (?) eventually. The names are not important, they could be changed in drlvm build as well if we find those that most of us like. I think word native is ok or there may be a confusion that the same rule applies to java sources (this of course depends on what hy.native.cfg, be it compilation flags, then it should not apply to java, or just debug/release, then it is ok for java). Well, I will stick to corresponding names from drlvm then. Somebody who will commit the changes can rename both of them if needed. Not sure how this follows from what Gregory wrote. I still think (as Gregory suggested above) if it only affects native code it should include the word native. Or are you going to modify how the corresponding hy.javac.debug flags is derived? Personally, I think the hy.native.cfg variable is more in keeping with the existing variables - e.g. hy.javac.*. If we decide to modify the way hy.javac.debug is setup then perhaps we could use something without native in the name but I think that is out of scope of the current change. 3) adding !if/ifeq directives in defines.mak and makefile.include to define the CFG_CFLAGS and CFG_LDFLAGS with just the subset of flags for debug/optimisation. I would also like to have CFLAGS and LDFLAGS to be used in the defines.mak. People can set corresponding environment variables for extra compiler switches they want. This seems like a separate issue. I think that #4 covers this. 4) breaking up the existing flags variables and defining them in terms of separate defines for different types of flags CFG flags, warning flags, etc. Could you reformulate this, I think I not quite catch the idea. This is something that I was thinking about, separate groups of flags for debug info control, optimization flags, warning level and just user additional flags (which should probably go the last to take the precedence). (hopefully I clarified this paragraph correctly for Ivan from how I understood it myself) Yes. Gregory's interpretation was accurate. I will do that as I understood :) Great, but please use variable names in keeping with what is in classlib already unless you want to have the discussion about renaming all of the classlib variables. Personally I'd leave that issue to another day. ;-) 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]
Re: [classlib] Testing conventions - a proposal
On 6 July 2006 at 21:02, Nathan Beyer [EMAIL PROTECTED] wrote: I think Tim has a valid point, or at least the point I'm inferring seems valid: the testing technology is not the real issue. This problem can be solved by either JUnit or TestNG. More specifically, this problem can be solved utilizing the grouping of arbitrary tests. I'm happy with either JUnit or TestNG. My only concerns about TestNG are non-technical. (Can we use TestNG without adding to the burden for the developer looking at Harmony for the first time? I think we can automate the download as we do for other dependencies. TestNG is under the Apache License but I'm not sure what the licenses are like for the third party code it includes. This may not be immediately important, but it might be if we wanted to include tests - ready to run - in the hdk.) I'm been playing with reorganizing the 'luni' module using the suggested directory layout and it really doesn't seem to provide much value. Also, I'm a bit partial to the concept of one source directory (src/main/java), one test source directory (src/test/java) and any number of resource (src/main/resources/*) and test resource directories (src/test/resources/*) as defined by the Maven 2 POM. +1 The only practical value I saw in the directory layout was that in Eclipse I could just select a single folder and run all of the API tests against an RI. The same can be said for any of the other test folders, but this same feature can also be achieved via TestSuites. As such, I'm in alignment with Tim's thoughts on just using TestSuites to define the major groupings. I think the proposed naming conventions of 'o.a.h.test.module.java.package' are fine. The only addition I would make is to at guidelines on class name, so that pure API tests, Harmony tests and failing tests can live in the same package. Something as trivial as XXXAPITest, XXXImplTest and XXXFailingTest would work. Perhaps a similar approach can be used for platform-specific tests. These tests would then be grouped, per-module into an APITestSuite, an ImplTestSuite, a FailingTestSuite and Platform-specificTestSuites. This is where I think TestNG has the edge. XXXFailingTest could contain both failing API and failing Impl tests? With TestNG these failing tests would not have to be moved out of the code base, but could simply be annotated in-place. I also like the idea of being able to write tests (API tests) for code that we don't have yet put them in place and annotate them appropriately until the code is written. For instance, when someone raises a JIRA with a test (that passes on RI) but no fix we can add the test right away. In regards to tests that must be on the bootclasspath, I would say either just put everything on the bootclasspath (any real harm) Testing this way means we are doing API testing in a way that is different from the typical way a user will use the API. This seems wrong to me. or use pattern sets for bootclasspath tests (80% of the time the classes will be java*/*). That might work. In regards to stress tests, performance tests and integration tests, I believe these are patently different and should be developed in their own projects. I'm inclined to agree. Regards, Mark. -Original Message- From: Tim Ellison [mailto:[EMAIL PROTECTED] snip/ Considering just the JUnit tests that we have at the moment... Do I understand you correctly that you agree with the idea of creating 'suites of tests' using metadata (such as TestNG's annotations or whatever) and not by using the file system layout currently being proposed? I know that you are also thinking about integration tests, stress tests, performance tests, etc. as well but just leaving those aside at the moment. Regards, Tim Thanks Mikhail Stress ...and so on... If you weigh up all of the different possible permutations and then consider that the above list is highly likely to be extended as things progress it is obvious that we are eventually heading for large amounts of related test code scattered or possibly duplicated across numerous hard wired source directories. How maintainable is that going to be ? If we want to run different tests in different configurations then IMHO we need to be thinking a whole lot smarter. We need to be thinking about keeping tests for specific areas of functionality together (thus easing maintenance); we need something quick and simple to re-configure if necessary (pushing whole directories of files around the place does not seem a particularly lightweight approach); and something that is not going to potentially mess up contributed patches when the file they patch is found to have been recently pushed from source folder A to B. To connect into another recent thread, there have been some posts lately about handling some test methods that fail on Harmony
Re: [classlib] debug compilation as default
On 6 July 2006 at 23:42, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Mark Hindess wrote: On 7 July 2006 at 0:43, Ivan Volosyuk [EMAIL PROTECTED] wrote: On 7/7/06, Gregory Shimansky [EMAIL PROTECTED] wrote: I can make this patch. One question, is it ok to have same property as DRLVM for release mode? Like this: BUILD_CFG=release I'm happy with release and debug but the top-level interface (and the module-level interface too for that matter) is ant - make should not be called directly - so it will probably need to be an ant property. I'm perfectly happy w/ this at high level. I was thinking: 1) adding a 'hy.native.cfg' property to make/properties.xml 2) converting this in to an environment variable so what like hy.hdk gets converted to HY_HDK. Can we please stop with this HY stuff? The project is Harmony. I'm only going along with what is already there. IMHO, it would be even worse to have some hy varaibles and some harmony variables. Changing them all is definitely out-of-scope for this specific problem. Personally, I really don't care either way. (I'll just put an entry in the global-abbrev-table in emacs to expand hy to harmony. ;-) 3) adding !if/ifeq directives in defines.mak and makefile.include to define the CFG_CFLAGS and CFG_LDFLAGS with just the subset of flags for debug/optimisation. 4) breaking up the existing flags variables and defining them in terms of separate defines for different types of flags CFG flags, warning flags, etc. That's just my first thoughts I'd might not end up doing it quite like that if I actually tried to do it. ;-) Is that overspecifying it for a first run? Just having debug/release would be cool to start. Perhaps a little. You need to do 3) and at least enough of 4) to extract the debug/optimization options but you could leave the remainder in a single variable. 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]
Re: [vm-kernel][testing] Where to put VM-agnostic tests for kernel classes?
On 7 July 2006 at 12:55, Alexey Varlamov [EMAIL PROTECTED] wrote: I know the topic of test layouts is too popular here, but let me offer some more grounds :) I think classlib tests should include a suite for VM-independent kernel tests, like recently created testcases in H-765 and H-721. The latter has gone to drlvm/vm/tests/smoke suite, which also has a number of good candidates for moving to a common place. I see classlib/luni-kernel as the most natural location for now, but maybe it worths a separate module altogether? Yes. I think tests that should pass on any VM's kernel classes should live in the classlib modules (luni-kernel or security-kernel). 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]
Re: [testing] Peace
Tim Ellison wrote: May I tactfully suggest that we get this back to a discussion of the pros and cons of JUnit test suites and/or TestNG metadata vs. directory layout. It sounds like we all want to resolve that problem asap. Regards, Tim +1 -- George George Harley wrote: Mark Hindess wrote: On 6 July 2006 at 18:05, George Harley [EMAIL PROTECTED] wrote: Mark Hindess wrote: On 6 July 2006 at 12:55, George Harley [EMAIL PROTECTED] wrote: Hi Mark, From what I can tell this JIRA hasn't really achieved much apart from pushing code around the repository and breaking at least one patch (HARMONY-755). Well, obviously that wasn't my motivation! ;-) Hi Mark, No one was saying it was. BTW, good to hear you have some motivation :-) From the description, it was clear (to me anyway) that the patch was to enable the use of platform-specific test code. While the directories for the platform-specific test code are currently empty, I'm certain Paulex plans to rectify this pretty soon. Creating empty directories is not the issue here. The patch also entailed moving a whole bunch of other files around the source tree for reasons that are currently being discussed in the dev list. I think Paulex was correct to separate the process of allowing for platform-specific tests (HARMONY-782) from any JIRA containing new tests. The process of allowing for new platform-specific tests is precisely what is being currently discussed on the dev-list in the referenced thread. I thought it was categorisation of tests in general. Hi Mark, Since platform-specific is one important category of test then discussion and agreement on the general topic is important. The JIRA comment by Paulex mentioned that it would break two existing JIRA issues - HARMONY-775 and HARMONY-767. I applied the former but the latter was already assigned to Tim and marked 'In Progress' so I didn't feel it was right to steal it. However I have made the trivial change to the patch metadata to fix the HARMONY-767 patch. Unfortunately it didn't mention the HARMONY-775 patch, otherwise I might have checked with you first. It was HARMONY-755. I know, now I'm just being picky :-) Yes. :-) It would be great if you or Paulex (and everyone in fact) could comment in the [classlib] Testing conventions - a proposal thread [1] about this. Certainly - though this seems to me to be orthogonal to the purpose of the HARMONY-782 patch. The summary of HARMONY-782 is Relayout NIO test cases to platform dependent. That is orthogonal to the dev-list discussion on proposed test layout ??? Are you serious ?? Ok so maybe not orthogonal but the JIRA (regardless of the exact title) was an enabler to allow additional platform-specific tests to be added. And adding new tests is something that is independent of the need to restructure. Or are you saying we shouldn't create any more tests (or fix existing tests) until the restructuring issue is decided? If adding new platform-specific tests is independent of the need to restructure then why did you restructure the NIO tests ? No, I am not saying that we shouldn't create any more tests. No, I am not saying that we should stop fixing existing ones. This is not a restructuring issue. If anything, this is an anti-restructuring issue. This is about pausing to consider a different approach to the existing proposal for how we manage our tests. It deserves to be considered as it has the potential to save us all a lot of time and effort pushing files around. While I see the importance of the restructuring I'm also keen not to prevent the problematic nio tests to be fixed. Ditto. But what is the urgency here ? Are you suggesting that applying the JIRA made the state of the tests any worse than it was before? (I even made an effort to ensure that the change was made in a way that was more consistent with the current state of another module - to make it easier to programmatically fix them later when the test structure issue is resolved.) Regards, Mark. IMHO this is not really about just HARMONY 782 and I would be genuinely upset if the impression was that I was getting at you or Paulex because it's not true. This is about asking you, Paulex and everyone to think about what our tests structure is going to look like eventually, how much effort is going to be required to maintain its labyrinth layout, the amount of overhead that is going to mean for our infrastructure (Ant scripts, IDE metadata files etc) and whether or not we can do better. Best regards, George - Terms of use :
Re: portlib functionality
Marina, 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. Totally agree with you that the portlib modification is serious, so I think the extension should be considered and discussed on the mailing list carefully at first... 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? That of course will be useful, thank you for the initiative. But it will be even better if you, before creating the patch, propose your plan on the mailing list at first:) Marina -- 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]
Re: [vm-kernel][testing] Where to put VM-agnostic tests for kernel classes?
On 7/7/06, Mark Hindess [EMAIL PROTECTED] wrote: On 7 July 2006 at 12:55, Alexey Varlamov [EMAIL PROTECTED] wrote: I know the topic of test layouts is too popular here, but let me offer some more grounds :) I think classlib tests should include a suite for VM-independent kernel tests, like recently created testcases in H-765 and H-721. The latter has gone to drlvm/vm/tests/smoke suite, which also has a number of good candidates for moving to a common place. I see classlib/luni-kernel as the most natural location for now, but maybe it worths a separate module altogether? Yes. I think tests that should pass on any VM's kernel classes should live in the classlib modules (luni-kernel or security-kernel). Agree. However we should have the possibility to run the class library tests against any VM. AFAIK we cannot provide this thing right now (java launcher requests the clearvm library). All class library tests are run under J9 as default VM. I'd be not bad to start running these tests against DRLVM as well. Otherwise the tests for the JIRA issues mentioned in this thread will be useless if we put them on the class lib modules. Correct? Thanks, Vladimir. 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]
Re: [classlib] Exception throwing compatibility: java.util.Scanner
It seems like the RI is doing random crap, and it wouldn't be something that someone would depend on... can you imagine? Easily :) One more example: Pattern.compile((?![^\\xB5]), Pattern.CASE_INSENSITIVE); exposes implementation problems: java.lang.ArrayIndexOutOfBoundsException at java.util.regex.Pattern$BitClass.add(Pattern.java:2861) . though it works without Pattern.CASE_INSENSITIVE -- Regards, Anton Luht, Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] Exception throwing compatibility: java.util.Scanner
Richard Liang wrote: Geir Magnusson Jr wrote: This is a great example. The last two aren't even legal exceptions for that method. It seems like the RI is doing random crap, and it wouldn't be something that someone would depend on... can you imagine? Thanks a lot, Geir. There may be a great deal of these great examples. ;-) This makes our discussion about Exception throwing compatibility more complex. No one said this was going to be easy :) geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] Exception throwing compatibility: java.util.Scanner
Richard Liang wrote: For this case, I decide to follow useRadix(int radix). Please correct me if I'm wrong. Thanks a lot. Do you mean that you're going to follow the spec? If so, we should note that we're making a conscious decision to differ from the RI. geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vm-kernel][testing] Where to put VM-agnostic tests for kernel classes?
Vladimir Gorr wrote: On 7/7/06, Mark Hindess [EMAIL PROTECTED] wrote: On 7 July 2006 at 12:55, Alexey Varlamov [EMAIL PROTECTED] wrote: I know the topic of test layouts is too popular here, but let me offer some more grounds :) I think classlib tests should include a suite for VM-independent kernel tests, like recently created testcases in H-765 and H-721. The latter has gone to drlvm/vm/tests/smoke suite, which also has a number of good candidates for moving to a common place. I see classlib/luni-kernel as the most natural location for now, but maybe it worths a separate module altogether? Yes. I think tests that should pass on any VM's kernel classes should live in the classlib modules (luni-kernel or security-kernel). Agree. However we should have the possibility to run the class library tests against any VM. Yah, I was pondering the same question, and thinking that we should put spec and intergration-ish tests outside of classlib, maybe in the if-I-keep-wishing-it-will-happen /testing subcomponent, but I don't really care too strongly. AFAIK we cannot provide this thing right now (java launcher requests the clearvm library). All class library tests are run under J9 as default VM. I'd be not bad to start running these tests against DRLVM as well. Otherwise the tests for the JIRA issues mentioned in this thread The tests don't care. I've been playing with running things under DRLVM. will be useless if we put them on the class lib modules. Correct? I don't actually see why. geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: portlib functionality
putting on MailListNag hat can we please try to remember to categorize our subject lines? :) geir Marina Goldburt wrote: Hi, As I see the main idea of the port library is isolates all platform specific knowledge to one area, as written at http://svn.apache.org/viewvc /incubator/harmony/enhanced/classlib/trunk/doc/vm_doc/html/group__Port.html . However, I've noticed that the code for sig, thread and luni modules also contain the platform-dependent code. For example, Java_org_apache_harmony_luni_platform_OSFileSystem_unlockImpl function contains: rc = UnlockFileEx ((HANDLE) handle, (DWORD) 0, nNumberOfBytesToUnlockLow, nNumberOfBytesToUnlockHigh, (LPOVERLAPPED) overlapped); Where the handle was produced by hyfile_open function. It will lead to problems when somebody tries to replace the portlib with a different implementation, that can use not os-handles. Will it make sense to extend the portlib functionality and move such platform-dependent code from sig, thread, luni modules to the portlib? Marina. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vm-kernel][testing] Where to put VM-agnostic tests for kernel classes?
On 7 July 2006 at 10:50, Mark Hindess [EMAIL PROTECTED] wrote: On 7 July 2006 at 16:18, Vladimir Gorr [EMAIL PROTECTED] wrote: On 7/7/06, Mark Hindess [EMAIL PROTECTED] wrote: On 7 July 2006 at 12:55, Alexey Varlamov [EMAIL PROTECTED] wrote: I know the topic of test layouts is too popular here, but let me offer some more grounds :) I think classlib tests should include a suite for VM-independent kernel tests, like recently created testcases in H-765 and H-721. The latter has gone to drlvm/vm/tests/smoke suite, which also has a number of good candidates for moving to a common place. I see classlib/luni-kernel as the most natural location for now, but maybe it worths a separate module altogether? Yes. I think tests that should pass on any VM's kernel classes should live in the classlib modules (luni-kernel or security-kernel). Agree. However we should have the possibility to run the class library tests against any VM. AFAIK we cannot provide this thing right now (java launcher requests the clearvm library). All class library tests are run under J9 as default VM. I'd be not bad to start running these tests against DRLVM as well. Otherwise the tests for the JIRA issues mentioned in this thread will be useless if we put them on the class lib modules. Correct? Well, I'm hoping someone will look at getting drlvm working under the launcher - so that there is more chance that people will run the classlib tests with something other than the IBM VME. However, in the meantime, I am running them on linux with: DRL=/path/to/drlvm/build/lnx_ia32_gcc_debug/deploy/jre ln -s $DRL/bin/ij $DRL/bin/java LD_LIBRARY_PATH=$DRL/bin ant -Dtest.jre.home=$DRL test under linux, and I'm sure you can do something similar under windows. Sadly lots of tests fail and some hang. I've not really had chance to investigate. I've put the result of a recent test run at: http://people.apache.org/~hindessm/drlvm/test/20060706/ the tests hung at tests.api.java.lang.CompilerTest and I killed junit so subsequent luni tests were not run. 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]
Re: [vm-kernel][testing] Where to put VM-agnostic tests for kernel classes?
On 7/7/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Vladimir Gorr wrote: On 7/7/06, Mark Hindess [EMAIL PROTECTED] wrote: On 7 July 2006 at 12:55, Alexey Varlamov [EMAIL PROTECTED] wrote: I know the topic of test layouts is too popular here, but let me offer some more grounds :) I think classlib tests should include a suite for VM-independent kernel tests, like recently created testcases in H-765 and H-721. The latter has gone to drlvm/vm/tests/smoke suite, which also has a number of good candidates for moving to a common place. I see classlib/luni-kernel as the most natural location for now, but maybe it worths a separate module altogether? Yes. I think tests that should pass on any VM's kernel classes should live in the classlib modules (luni-kernel or security-kernel). Agree. However we should have the possibility to run the class library tests against any VM. Yah, I was pondering the same question, and thinking that we should put spec and intergration-ish tests outside of classlib, maybe in the if-I-keep-wishing-it-will-happen /testing subcomponent, but I don't really care too strongly. AFAIK we cannot provide this thing right now (java launcher requests the clearvm library). All class library tests are run under J9 as default VM. I'd be not bad to start running these tests against DRLVM as well. Otherwise the tests for the JIRA issues mentioned in this thread The tests don't care. I've been playing with running things under DRLVM. I have no doubts it was done. will be useless if we put them on the class lib modules. Correct? I don't actually see why. I thought we cannot run the class library tests under DRLVM. I mean * automatically*. Now I see there is such way (thanks Mark for coaching). Therefore moving the VM-independent test to the luni-kernel module is very useful thingJ. Thanks, Vladimir. geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] Is it OK for VM kernel class to call internal classlib API?
Andrey Chernyshev wrote:
I was trying to compile the kernel classes set from DRLVM independently
from the classlib and found it difficult because kernel classes set
currently have a dependence on the internal classlib API, e.g.
org.apache.harmony.luni.internal.net.www.protocol.jar.JarURLConnection
and org.apache.harmony.luni.util.DeleteOnExit classes.
I've found the spec for kernel class org.apache.harmony.kernel.vm.VM
(l'm looking at
classlib\trunk\modules\luni-kernel\src\main\java\org\apache\harmony\kernel\vm\VM.java)
assumes that VM is calling excplicitly
JarURLConnection.closeCachedFiles()
and DeleteOnExit.deleteOnExit() during VM shutdown.
On the other hand, there is standard API in J2SE called
java.lang.Runtime.addShutdownHook(Thread) which can be used to specify
the
tasks that have to be done during VM shutdown.
BTW, this is exactly how DRLVM implements these methods in it's
VM.java. For example, for VM.closeJars() it currently does like:
public static void closeJars() {
class CloseJarsHook implements Runnable {
public void run() {
JarURLConnection.closeCachedFiles();
}
}
...
Runtime.getRuntime().addShutdownHook(new Thread(new
CloseJarsHook()));
}
Are there any problems with this approach, should the DRLVM (or other
Vm's) implement these methods differently?
There is a potential problem with this approach. The code that is run by the
shutdown hooks is not restricted in its behaviour and the order that the
shutdown hooks are executed in is not guaranteed. If the deleteOnExit()
and/or closeCachedFiles are not the last hooks to be executed, it is quite
possible that a subsequent shutdown hook could try to access files that
have already been deleted. The only way to guarantee that this will
never happen is to make sure that deleteOnExit() and closeCachedFiles()
are called after all shutdown hooks have completed.
Of course, how this is implemented is down to the VM developer - but
I would strongly recommend not using shutdown hooks for this purpose.
May be it makes sense just to move VM.closeJars() and
VM.deleteOnExit() methods and their drlvm implementation to the luni
classlib component, under assumption that they do not really contain
any VM-specific code?
The version of VM.java currently under luni-kernel does not contain
any VM specific code either, as all its methods simply return null :)
It does, however, give hints as to how to implement the methods
in the javadoc comments (perhaps it should clarify the reason
for not using shutdown hooks).
As described above, I think there is a problem with this implementation,
so I would not like to see it used as an example for other VM
developers.
I have noticed that the Javadoc comments for the DRLVM implementation
of deleteOnExit() and closeJars() both say:
/**
* 1) This is temporary implementation
* 2) We've proposed another approach to perform shutdown actions.
*/
Have I missed the proposal of this other approach, or are the comments
inaccurate?
I guess it will simplify a bit the org.apache.harmony.kernel.vm.VM
interface as well as would allow to avoid extra dependencies between
VM and classlib.
IMHO there is no problem for kernel classes to have dependencies on
classlib - they are, after all, just another part of the class library that
happens to get developed separately due to their nature.
Regards,
Oliver
--
Oliver Deakin
IBM United Kingdom Limited
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vm-kernel][testing] Where to put VM-agnostic tests for kernel classes?
Alexey Varlamov wrote: I know the topic of test layouts is too popular here, but let me offer some more grounds :) I think classlib tests should include a suite for VM-independent kernel tests, like recently created testcases in H-765 and H-721. The latter has gone to drlvm/vm/tests/smoke suite, which also has a number of good candidates for moving to a common place. I see classlib/luni-kernel as the most natural location for now, but maybe it worths a separate module altogether? If they are Java API tests then pop them into LUNI. The Kernel distinction is only for the physical separation of VM-specific types, they are still logically part of LUNI. 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]
Re: [classlib] Exception throwing compatibility: java.util.Scanner
Geir Magnusson Jr wrote: Richard Liang wrote: For this case, I decide to follow useRadix(int radix). Please correct me if I'm wrong. Thanks a lot. Do you mean that you're going to follow the spec? If so, we should note that we're making a conscious decision to differ from the RI. Yes, Geir. For this case I think we have to differ from RI. 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
Re: [vm-kernel][testing] Where to put VM-agnostic tests for kernel classes?
2006/7/7, Tim Ellison [EMAIL PROTECTED]: Alexey Varlamov wrote: I know the topic of test layouts is too popular here, but let me offer some more grounds :) I think classlib tests should include a suite for VM-independent kernel tests, like recently created testcases in H-765 and H-721. The latter has gone to drlvm/vm/tests/smoke suite, which also has a number of good candidates for moving to a common place. I see classlib/luni-kernel as the most natural location for now, but maybe it worths a separate module altogether? If they are Java API tests then pop them into LUNI. The Kernel distinction is only for the physical separation of VM-specific types, they are still logically part of LUNI. Well, my perception was that we strive for keeping (unit) tests within the same module with tested entities, that's why I suggested luni-kernel. But indeed, the distinction here is subtle - consider InternString test, for example... So for now it seems that we agreed to put such tests to classlib, whatever module is appropriate in common sense. In the long-term outlook, I corroborate Geir's wishes for the (sub)component for integration tests. -- Alexey Varlamov 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]
Re: Strategy for Harmony to work with Visual Studio 2005?
Matt Benson skrev den 06-07-2006 19:25: Some particulars may be slightly different from one machine to the next, but in general this works; we need to get this info in the wiki IMHO Agreed. I have starting to write such an entry, but is currently stopped by the VSMCR8.DLL problem of VS2005 Express so the compiled java.exe will not start. When I have a fully working compilation path of classlib with the IBM VM I'll get it finished. -- THorbjørn - 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: java.util.Scanner
Richard Liang wrote: Geir Magnusson Jr wrote: Richard Liang wrote: For this case, I decide to follow useRadix(int radix). Please correct me if I'm wrong. Thanks a lot. Do you mean that you're going to follow the spec? If so, we should note that we're making a conscious decision to differ from the RI. Yes, Geir. For this case I think we have to differ from RI. I agree. I just had no clue what your post meant. And we'll document? :) geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] Testing conventions - a proposal
Oliver Deakin wrote: George Harley wrote: Hi, Just seen Tim's note on test support classes and it really caught my attention as I have been mulling over this issue for a little while now. I think that it is a good time for us to return to the topic of class library test layouts. The current proposal [1] sets out to segment our different types of test by placing them in different file locations. ok - on closer reading of this document, I have a few gripes... First, what happened to the Maven layout we agreed on a while ago? Maven layout? We were doing that layout in Jakarta projects long before maven This is a fun thread. I plan to read it from end to end later today and comment. Initial thoughts are that I've been wanting to use TestNG for months (hence my resistance to any JUnit deps more than we needed to) and second, annotations won't solve our problems. More later :) geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Strategy for Harmony to work with Visual Studio 2005?
On Friday 07 July 2006 16:00 Thorbjørn Ravn Andersen wrote: Matt Benson skrev den 06-07-2006 19:25: Some particulars may be slightly different from one machine to the next, but in general this works; we need to get this info in the wiki IMHO Agreed. I have starting to write such an entry, but is currently stopped by the VSMCR8.DLL problem of VS2005 Express so the compiled java.exe will not start. When I have a fully working compilation path of classlib with the IBM VM I'll get it finished. Do you mean you have an error that there is no manifest file present? This has been answered too in the same threads about using VC 8.0. I just copied all the manifests created in native-src/win.IA32 to deloy/jdk/jre/bin manually to see if it works. Rana also found 2 (using mt tool and using resource compiler) recipes how to embed this stuff into executables and DLLs but I didn't try them. To make this work out of the box the build of classlib should be improved, probably it is easier to do from ant after native sources compilation is done by make. -- Gregory Shimansky, Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] trying new framework for testing serialization
Stepan, I think that there's no need in SerializableAssert interface - just put assertDeserialized(Serializable, Serializable) method to SerializationTest class with default implementation based on current code from defineComparator (if there's equals(), use it, if it's instance of Throwable, use some other scheme, etc). If a developer needs his own comparing method, he just redefines this method. If he's happy with equals(), he does nothing. So, verifySelf will look like: ByteArrayOutputStream out = new ByteArrayOutputStream(); putObjectToStream(object, out); ByteArrayInputStream in = new ByteArrayInputStream(out.toByteArray()); assertDeserialized((Serializable) object, (Serializable) getObjectFromStream(in)); This will help us remove methods with SerializableAsset as a third parameter. And a small note: we don't need flush() before close() :) -- Regards, Anton Luht, Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Strategy for Harmony to work with Visual Studio 2005?
Gregory Shimansky skrev den 07-07-2006 15:01: Do you mean you have an error that there is no manifest file present? This has been answered too in the same threads about using VC 8.0. I just copied all the manifests created in native-src/win.IA32 to deloy/jdk/jre/bin manually to see if it works. Well, it just complains that the msvcr8.dll is not present, and I am aware that this has been discussed earlier but have not had the time to grok the answers yet. I am currently reading up on the matter, but as I am used to the gcc toolchain there is a lot to get right in the mind. If it is sufficient to copy manifests I will try that, and if needed add it to the deployment part in the appropriate build.xml -- Thorbjørn - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vm-kernel][testing] Where to put VM-agnostic tests for kernel classes?
Alexey Varlamov wrote: 2006/7/7, Tim Ellison [EMAIL PROTECTED]: Alexey Varlamov wrote: I know the topic of test layouts is too popular here, but let me offer some more grounds :) I think classlib tests should include a suite for VM-independent kernel tests, like recently created testcases in H-765 and H-721. The latter has gone to drlvm/vm/tests/smoke suite, which also has a number of good candidates for moving to a common place. I see classlib/luni-kernel as the most natural location for now, but maybe it worths a separate module altogether? If they are Java API tests then pop them into LUNI. The Kernel distinction is only for the physical separation of VM-specific types, they are still logically part of LUNI. Well, my perception was that we strive for keeping (unit) tests within the same module with tested entities, that's why I suggested luni-kernel. But indeed, the distinction here is subtle - consider InternString test, for example... The kernel modules, luni-kernel and security-kernel, are fragments of the LUNI and SECURITY modules respectively. They are simply broken out for packaging so they can be replaced by particular VMs, but at runtime but they are logically the same thing. So for now it seems that we agreed to put such tests to classlib, whatever module is appropriate in common sense. In the long-term outlook, I corroborate Geir's wishes for the (sub)component for integration tests. The classlib doesn't have any tests that pass without a VM present, so they are all integration tests to a first approximation. 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]
Re: [classlib][security] crypto provider: implementation of SHA-1 algorithm
Yuri,
I'm trying to test serialization but the simple test:
import java.io.*;
public class Test {
public static void main(String[] args) throws Throwable {
ObjectOutputStream oos = new ObjectOutputStream(new
ByteArrayOutputStream());
oos.writeObject(new Object());
}
}
fails:
java.lang.Error: java.security.NoSuchAlgorithmException: MessageDigest SHA imple
mentation not found
at java.io.ObjectStreamClass.computeSerialVersionUID(ObjectStreamClass.j
ava:345)
I've built a version of classlib with your patch but the test still
fails. Is it because I didn't apply it correctly or maybe something
else is missing?
--
Regards,
Anton Luht,
Intel Middleware Products Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] DRLVM segfaults in hythread_tls_get()
On 7/7/06, Tim Ellison [EMAIL PROTECTED] wrote: Geir Magnusson Jr wrote: Actually, let me flip this the other way... What are the differences between the impl of the threading lib in DRLVM vs that in classlib? Yep, that is the right question. I don't know the answer, perhaps whoever made those changes can enlighten us. I guess these are the key differences: hythread in drlvm: - lightweight library which implements just the minimal set of functions that appeared to be needed for classlib to work, e.g. monitor_enter/exit and TLS support. - contains almost no code and delegates directly to APR threading API. original hythread included with the classlib: - contains much more extensive threading API, e.g. it adds wait/notify, interrupt, suspend, sleep, resume e.t.c. - the full set of threading API which is described in java.lang.Thread and java.lang.Object classes; - is platform-dependent, there are two versions for Linux and Windows, it seems it is written directly on top of win32 API / pthreads respectively. Personally, I would prefer to have classlib accessing threading functionality through the standard Java API like java.lang.Thread or Object and not using hythread at all, at least this will help VM's to show more useful debugging information for classlib. For example, VM knows nothing about hythread native monitors unless VM is building it's internal threading subsystem on top of the same hythread. Synchronization problems are tricky to identify and debug and I would prefer to face them in Java rather than in the native code. Thanks, Andrey. 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] -- Andrey Chernyshev Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][security] crypto provider: implementation of SHA-1 algorithm
On 7 July 2006 at 18:34, Anton Luht [EMAIL PROTECTED] wrote:
Yuri,
I'm trying to test serialization but the simple test:
import java.io.*;
public class Test {
public static void main(String[] args) throws Throwable {
ObjectOutputStream oos = new ObjectOutputStream(new
ByteArrayOutputStream());
oos.writeObject(new Object());
}
}
fails:
java.lang.Error: java.security.NoSuchAlgorithmException: MessageDigest SHA im
ple
mentation not found
at java.io.ObjectStreamClass.computeSerialVersionUID(ObjectStreamClas
s.j
ava:345)
I've built a version of classlib with your patch but the test still
fails. Is it because I didn't apply it correctly or maybe something
else is missing?
Yes. jre/lib/security. Oddly enough I was just looking at this.
-Mark.
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vm-kernel][testing] Where to put VM-agnostic tests for kernel classes?
This is something I think we should do sooner rather than later... geir Tim Ellison wrote: Vladimir Gorr wrote: Agree. However we should have the possibility to run the class library tests against any VM. AFAIK we cannot provide this thing right now (java launcher requests the clearvm library). That is the default name, but you can change it with a command line option -vm: and put it in a directory specified by -vmdir:, e.g. java -vmdir:drlvm -vm:foo look in jre/bin/drlvm for a library called foo.[so|dll] that exports the JNI_CreateJavaVM etc. The idea is that you can have multiple VMs in deploy and choose which you use at runtime. Regards, Tim All class library tests are run under J9 as default VM. I'd be not bad to start running these tests against DRLVM as well. Otherwise the tests for the JIRA issues mentioned in this thread will be useless if we put them on the class lib modules. Correct? Thanks, Vladimir. 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] - 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 : Weldon Washburn
Congratulations :-) Rana
Re: [classlib] Is it OK for VM kernel class to call internal classlib API?
On 7/7/06, Oliver Deakin [EMAIL PROTECTED] wrote:
Andrey Chernyshev wrote:
I was trying to compile the kernel classes set from DRLVM independently
from the classlib and found it difficult because kernel classes set
currently have a dependence on the internal classlib API, e.g.
org.apache.harmony.luni.internal.net.www.protocol.jar.JarURLConnection
and org.apache.harmony.luni.util.DeleteOnExit classes.
I've found the spec for kernel class org.apache.harmony.kernel.vm.VM
(l'm looking at
classlib\trunk\modules\luni-kernel\src\main\java\org\apache\harmony\kernel\vm\VM.java)
assumes that VM is calling excplicitly
JarURLConnection.closeCachedFiles()
and DeleteOnExit.deleteOnExit() during VM shutdown.
On the other hand, there is standard API in J2SE called
java.lang.Runtime.addShutdownHook(Thread) which can be used to specify
the
tasks that have to be done during VM shutdown.
BTW, this is exactly how DRLVM implements these methods in it's
VM.java. For example, for VM.closeJars() it currently does like:
public static void closeJars() {
class CloseJarsHook implements Runnable {
public void run() {
JarURLConnection.closeCachedFiles();
}
}
...
Runtime.getRuntime().addShutdownHook(new Thread(new
CloseJarsHook()));
}
Are there any problems with this approach, should the DRLVM (or other
Vm's) implement these methods differently?
There is a potential problem with this approach. The code that is run by the
shutdown hooks is not restricted in its behaviour and the order that the
shutdown hooks are executed in is not guaranteed. If the deleteOnExit()
and/or closeCachedFiles are not the last hooks to be executed, it is quite
possible that a subsequent shutdown hook could try to access files that
have already been deleted. The only way to guarantee that this will
never happen is to make sure that deleteOnExit() and closeCachedFiles()
are called after all shutdown hooks have completed.
Of course, how this is implemented is down to the VM developer - but
I would strongly recommend not using shutdown hooks for this purpose.
Thanks Oliver, this explanation sounds reasonable.
If the issue is just in the shutdown hooks order, then, still may be
it makes sense to add VM.addClasslibShutdownHook(Runnable) method or
something like that, which can be:
- used by the classlib to do whatever resource cleanup / shutdown
works they need;
- guaranteed by VM to be executed always after Runtime's shutdown
hooks are done (can be specified in the contract)?
This approach looks more universal than having two specific methods
cloaseJars() and deletOnExit(). It will also allow VM to do not call
internal classlib API explicitly.
May be it makes sense just to move VM.closeJars() and
VM.deleteOnExit() methods and their drlvm implementation to the luni
classlib component, under assumption that they do not really contain
any VM-specific code?
The version of VM.java currently under luni-kernel does not contain
any VM specific code either, as all its methods simply return null :)
It does, however, give hints as to how to implement the methods
in the javadoc comments (perhaps it should clarify the reason
for not using shutdown hooks).
As described above, I think there is a problem with this implementation,
so I would not like to see it used as an example for other VM
developers.
I have noticed that the Javadoc comments for the DRLVM implementation
of deleteOnExit() and closeJars() both say:
/**
* 1) This is temporary implementation
* 2) We've proposed another approach to perform shutdown actions.
*/
Have I missed the proposal of this other approach, or are the comments
inaccurate?
I guess there were no one on the mailing list, this seems to be a
history of the past internal discussions within drlvm development
team.
I guess it will simplify a bit the org.apache.harmony.kernel.vm.VM
interface as well as would allow to avoid extra dependencies between
VM and classlib.
IMHO there is no problem for kernel classes to have dependencies on
classlib - they are, after all, just another part of the class library that
happens to get developed separately due to their nature.
Actually I thought of the kernel classes being part of VM since they
are tied to VM-specific functionality. If this is true, then it may be
good if we can keep the interface between VM and classlib clean,
e.g. without dependencies on the API which doesn't appear in J2SE.
Thanks,
Andrey.
Regards,
Oliver
--
Oliver Deakin
IBM United Kingdom Limited
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Andrey Chernyshev
Intel Middleware Products Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe,
Re: [classlib] trying new framework for testing serialization
Anton, You suggestion works only if a test extends SerializationTest but we agree avoid this (i.e. a test should invoke only static utility methods of SerializationTest) Thanks, Stepan. On 7/7/06, Anton Luht wrote: Stepan, I think that there's no need in SerializableAssert interface - just put assertDeserialized(Serializable, Serializable) method to SerializationTest class with default implementation based on current code from defineComparator (if there's equals(), use it, if it's instance of Throwable, use some other scheme, etc). If a developer needs his own comparing method, he just redefines this method. If he's happy with equals(), he does nothing. So, verifySelf will look like: ByteArrayOutputStream out = new ByteArrayOutputStream(); putObjectToStream(object, out); ByteArrayInputStream in = new ByteArrayInputStream(out.toByteArray()); assertDeserialized((Serializable) object, (Serializable) getObjectFromStream(in)); This will help us remove methods with SerializableAsset as a third parameter. And a small note: we don't need flush() before close() :) -- Regards, Anton Luht, Intel Middleware Products Division -- 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]
Re: Re: [classlib] compatibility of toString
On 06/07/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Alex Blewitt wrote: IMNSHO I don't think we should by default copy the toString() behaviour from the RI, unless mandated by the spec in JavaDoc. Ok. Good rant, and I agree with it, but I still don't see a reason here why we shouldn't, other than to teach people a lesson? If people are relying on one implementation that's undocumented behaviour, then it's bad code. It may well fail on any other system (inc. embedded systems, or other OS, or even between different versions). But the real reason is one of defense; how can you say that you've implemented a clean-room version of the code from the spec, when all the toString() results are identical with a proprietary implementation that you have no way of knowing what the result should be, except by running the propetary version to find out? Obviously, some cases it will be obvious (e.g. we can guess what a java.net.URL looks like) but in most cases it won't be (e.g. java.net.URLConnection). I say that we follow the spec, and if the spec doesn't list an explicit format, we use our own. If it is amazingly obvious (e.g. a Point may be printed (1,2)) and it happens to correspond with the Sun RI, then great, but we shouldn't be striving to be the same in all cases. Alex. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: [classlib] compatibility of toString
On 06/07/06, Tim Ellison [EMAIL PROTECTED] wrote: Here here; if only the API was printOn(OutputStream) then we'd all be happy(er). I suspect that it's hear, hear, at least there (in Parliament). :-) Alex. - 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] crypto provider: implementation of SHA-1 algorithm
On 7 July 2006 at 16:07, Mark Hindess [EMAIL PROTECTED] wrote:
On 7 July 2006 at 18:34, Anton Luht [EMAIL PROTECTED] wrote:
Yuri,
I'm trying to test serialization but the simple test:
import java.io.*;
public class Test {
public static void main(String[] args) throws Throwable {
ObjectOutputStream oos = new ObjectOutputStream(new
ByteArrayOutputStream());
oos.writeObject(new Object());
}
}
fails:
java.lang.Error: java.security.NoSuchAlgorithmException: MessageDigest SHA
implementation not found
at java.io.ObjectStreamClass.computeSerialVersionUID
(ObjectStreamClass.java:345)
I've built a version of classlib with your patch but the test still
fails. Is it because I didn't apply it correctly or maybe something
else is missing?
Yes. jre/lib/security. Oddly enough I was just looking at this.
Fixed in r419914. I've removed the multiple copy tasks that we listing
everything drlvm wanted from classlib and replaced it with a copy
that copies everything except they things we *don't* need. This should
be more reliable. Hopefully it will become obsolete when we have a
top-level build.
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]
Re: [vm-kernel][testing] Where to put VM-agnostic tests for kernel classes?
On 7 July 2006 at 10:33, Tim Ellison [EMAIL PROTECTED] wrote: Alexey Varlamov wrote: I know the topic of test layouts is too popular here, but let me offer some more grounds :) I think classlib tests should include a suite for VM-independent kernel tests, like recently created testcases in H-765 and H-721. The latter has gone to drlvm/vm/tests/smoke suite, which also has a number of good candidates for moving to a common place. I see classlib/luni-kernel as the most natural location for now, but maybe it worths a separate module altogether? If they are Java API tests then pop them into LUNI. The Kernel distinction is only for the physical separation of VM-specific types, they are still logically part of LUNI. Yeah. That makes sense. I'll add the test from HARMONY-765 later. -Mark. - 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] debug compilation as default
On 7/7/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Ivan Volosyuk wrote: The drlvm build already has ant property called build.cfg and build.cxx for the debug or release build and the compiler name. The properties is initialized from BUILD_CFG and CXX environment variables. IMHO, it will be convenient to have the same property for drlvm and classlib build. Is it ok to have _this_ property names? I don't think the word 'native' in property make sense as this switch can be used somehow even in java build (?) eventually. I do think we should agree on something, to make federation easier. geir Linux version of the makefiles update is already in http://issues.apache.org/jira/browse/HARMONY-803 I didn't touch ant build system. It allows to pass environment to makefiles. That's enough. Makefiles will do the rest. -- Regards, Ivan - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RE: Re: [classlib] compatibility of toString
On 07/07/06, Magnusson, Geir [EMAIL PROTECTED] wrote: If people are relying on one implementation that's undocumented behaviour, then it's bad code. It may well fail on any other system (inc. embedded systems, or other OS, or even between different versions). No kidding. Welcome to the real world :) People do all sorts of stupid things. Yup, I've done a few myself ... 1) We are asking Sun about this, so it's clear we're bringing it up as an issue to them. Yes, and if Sun give the OK then there's no issue. 2) We try to get it from the RI via black-box, and if we can't, we can't and use our best judgement. Providing Sun don't have problems, I'd say that's fine. If they do, then it might be less desirable. I say that we follow the spec, and if the spec doesn't list an explicit format, we use our own. If it is amazingly obvious (e.g. a Point may be printed (1,2)) and it happens to correspond with the Sun RI, then great, but we shouldn't be striving to be the same in all cases. So if we are satisfied that it doesn't put us at risk from defense-of-cleanroom perspective, do you still have a problem if we at least try? If we're satisfied that there's no problems, then like I said, there's no problems if it's the same as the RI. Maybe we should pick this thread up again when Sun get back to you regarding the toString() and exception messages, and in the meantime, only follow what's in the JavaDoc/spec? Alex. - 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] java.nio.ByteBuffer.order((ByteOrder) null) throws unspecified NPE
Vladimir,
My simple tests on the RI show that passing null to
ByteBuffer.order(ByteOrder) causes the order to be set to LITTLE_ENDIAN,
or maybe even the opposite of the natural order.
This is the output from a simple test on my machine:
Natural order = BIG_ENDIAN
Set BE order = BIG_ENDIAN
Set LE order = LITTLE_ENDIAN
Set null order = LITTLE_ENDIAN
Set BE order = BIG_ENDIAN
Set null order = LITTLE_ENDIAN
Harmony currently throws a NPE, and your proposed patch would leave the
proposed order unmodified.
The behavior of passing null is undefined in the spec, but it is
possible that throwing an exception will break apps that inadvertently
pass null to this method, so unless anyone objects I'll take null to
mean LITTLE_ENDIAN.
Regards,
Tim
Vladimir Ivanov (JIRA) wrote:
[classlib][nio] java.nio.ByteBuffer.order((ByteOrder) null) throws
unspecified NPE
Key: HARMONY-798
URL: http://issues.apache.org/jira/browse/HARMONY-798
Project: Harmony
Type: Bug
Components: Classlib
Reporter: Vladimir Ivanov
The Harmony method java.nio.ByteBuffer.order(ByteOrder bo) throws
unspecified NPE for 'null' while RI does not.
=== test.java =
import java.nio.*;
public class test {
public static void main (String[] args) {
try {
ByteBuffer buf = ByteBuffer.wrap(new byte[10]);
System.out.println(buf = + buf + , order(null) = +
buf.order(null));
} catch (Exception e) {
e.printStackTrace();
}
}
}
===
Output:
C:\tmp\tmp17C:\jrockit-jdk1.5.0-windows-ia32\bin\java.exe -showversion test
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))
buf = java.nio.HeapByteBuffer[pos=0 lim=10 cap=10], order(null) =
java.nio.HeapByteBuffer[pos=0 lim=10 cap=10]
C:\tmp\tmp17C:\harmony\trunk_0427\deploy\jdk\jre\bin\java.exe -showversion
test
java version 1.5 (subset)
(c) Copyright 1991, 2006 The Apache Software Foundation or its licensors, as
applicable.
java.lang.NullPointerException
at java.nio.ByteBuffer.orderImpl(ByteBuffer.java:699)
at java.nio.ByteBuffer.order(ByteBuffer.java:694)
at test.main(test.java:7)
--
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]
Re: [classlib] debug compilation as default
On 7 July 2006 at 21:29, Ivan Volosyuk [EMAIL PROTECTED] wrote: On 7/7/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Ivan Volosyuk wrote: The drlvm build already has ant property called build.cfg and build.cxx for the debug or release build and the compiler name. The properties is initialized from BUILD_CFG and CXX environment variables. IMHO, it will be convenient to have the same property for drlvm and classlib build. Is it ok to have _this_ property names? I don't think the word 'native' in property make sense as this switch can be used somehow even in java build (?) eventually. I do think we should agree on something, to make federation easier. geir Linux version of the makefiles update is already in http://issues.apache.org/jira/browse/HARMONY-803 The DEFINES and INCLUDES is exactly the kind of thing I was thinking about. However: 1) I think we've somehow lost the default '-O1' option 2) I think the $(shell uname -m) is overkill, we'll handle this a better way when the time comes in the meantime forking/execing sh and uname for each call to make is just overhead. I didn't touch ant build system. It allows to pass environment to makefiles. That's enough. Makefiles will do the rest. Sorry, but I don't like this for reasons I discussed yesterday. It was late and I guess I wasn't clear enough. It should be done via ant because ant is the interface that developers should be using to execute the build - either using the top-level ant file or the module ant file (or via some federation calling ant). Even if they are only building native code in a module developers should still use the ant file. We may change[0] the way native code is built if handle things like this configuration issue via ant then the interface for developers can remain the same even when we change what happens under the covers. Regards, Mark. [0] Probably sooner rather than later if we start ports to other platforms. - 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] debug compilation as default
On 7/7/06, Mark Hindess [EMAIL PROTECTED] wrote: On 7 July 2006 at 21:29, Ivan Volosyuk [EMAIL PROTECTED] wrote: On 7/7/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Ivan Volosyuk wrote: The drlvm build already has ant property called build.cfg and build.cxx for the debug or release build and the compiler name. The properties is initialized from BUILD_CFG and CXX environment variables. IMHO, it will be convenient to have the same property for drlvm and classlib build. Is it ok to have _this_ property names? I don't think the word 'native' in property make sense as this switch can be used somehow even in java build (?) eventually. I do think we should agree on something, to make federation easier. geir Linux version of the makefiles update is already in http://issues.apache.org/jira/browse/HARMONY-803 The DEFINES and INCLUDES is exactly the kind of thing I was thinking about. However: 1) I think we've somehow lost the default '-O1' option Yes. I'll fix it. 2) I think the $(shell uname -m) is overkill, we'll handle this a better way when the time comes in the meantime forking/execing sh and uname for each call to make is just overhead. I know that fork/exec operation is quite efficient on linux, more over the compilation of sources uses much more time. I didn't touch ant build system. It allows to pass environment to makefiles. That's enough. Makefiles will do the rest. Sorry, but I don't like this for reasons I discussed yesterday. It was late and I guess I wasn't clear enough. It should be done via ant because ant is the interface that developers should be using to execute the build - either using the top-level ant file or the module ant file (or via some federation calling ant). Even if they are only building native code in a module developers should still use the ant file. Working on different projects, I've found out that Java programmers and C programmers have different habits. Java programmers likes ant, Linux/C programmers - make. I am C programmer :) If we going to do all the build ant-way, let's use cpptask as DRLVM does. But I will not sign up under that task - I can deal with makefile based build system, but I have quite little knowledge of ant to do that task. We may change[0] the way native code is built if handle things like this configuration issue via ant then the interface for developers can remain the same even when we change what happens under the covers. Regards, Mark. [0] Probably sooner rather than later if we start ports to other platforms. -- Ivan Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [classlib] Testing conventions - a proposal
-Original Message- From: Geir Magnusson Jr [mailto:[EMAIL PROTECTED] Maven layout? We were doing that layout in Jakarta projects long before maven And I would guess the Maven designers would agree. Much of their documentation talks about how the conventions inferred in the super POMs came from Jakarta projects and others. This is a fun thread. I plan to read it from end to end later today and comment. Initial thoughts are that I've been wanting to use TestNG for months (hence my resistance to any JUnit deps more than we needed to) and second, annotations won't solve our problems. More later :) I find this to be an extremely interesting comment. What value do you see TestNG offering? Most of the conversations pushing for TestNG as a solution have been all about the annotations. geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [classlib] trying new framework for testing serialization
-Original Message- From: Stepan Mishura [mailto:[EMAIL PROTECTED] * When loading the resource, the name is assembled using File.separatorChar as the separator, but you should just be using the character / since that's the normative class path separator. I didn't catch what the problem with File.separatorChar. The field java.io.File.separatorChar varies from platform to platform \ on windows, / on Unix/Linux/etc and is intended for file system use. The resource paths of a class loader use the separator /; it doesn't vary by platform. The ClassLoader is probably being agreeable and letting this code get away with it, but it's not required to. -Nathan - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
