Re: [vote] acceptance of HARMONY-536 : JSEE provider contribution
+1 2006/7/6, Nathan Beyer [EMAIL PROTECTED]: +1 -Original Message- From: Geir Magnusson Jr [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 05, 2006 6:29 PM To: harmony-dev@incubator.apache.org Subject: [vote] acceptance of HARMONY-536 : JSEE provider contribution 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] - 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] Testing conventions - a proposal
2006/7/5, George Harley [EMAIL PROTECTED]: 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. After looking at the recent changes to the LUNI module tests (where the layout guidelines were applied) I have a real concern that there are serious problems with this approach. We have started down a track of just continually growing the number of test source folders as new categories of test are identified and IMHO that is going to bring complexity and maintenance issues with these tests. Consider the dimensions of tests that we have ... API Harmony-specific Platform-specific Run on classpath Run on bootclasspath Behaves different between Harmony and RI BTW, these are Harmony-specific... I see your point. And I think we need this directory-level split to make it possible to run variuous kinds of tests with different frameworks. We were already discussing that JUnit extensions are not very good for performance testing. In the future we might find out that some new test contribution is inconsistent with the framework we have chosen. So I'm for directory-level separation of the tests. (Probably some categories should have their own build) 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 and have meant that entire test case classes have been excluded from our test runs. I have also been noticing some API test methods that pass fine on Harmony but fail when run against the RI. Are the different behaviours down to errors in the Harmony implementation ? An error in the RI implementation ? A bug in the RI Javadoc ? Only after some investigation has been carried out do we know for sure. That takes time. What do we do with the test methods in the meantime ? Do we push them round the file system into yet another new source folder ? IMHO we need a testing strategy that enables such problem methods to be tracked easily without disruption to the rest of the other tests. A couple of weeks ago I mentioned that the TestNG framework [2] seemed like a reasonably good way of allowing us to both group together different kinds of tests and permit the exclusion of individual tests/groups of tests [3]. I would like to strongly propose that we consider using TestNG as a means of providing the different test configurations required by Harmony. Using a combination of annotations and XML to capture the kinds of sophisticated test configurations that people need, and that allows us to specify down to the individual method, has got to be more scalable and flexible than where we are headed now. Thanks for reading this far. Best regards, George [1] http://incubator.apache.org/harmony/subcomponents/classlibrary/testing.html [2] http://testng.org [3] http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200606.mbox/[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]
Re: [vote] acceptance of HARMONY-609 : AWT, Java2D, Swing TESTS
+1 2006/7/6, Geir Magnusson Jr [EMAIL PROTECTED]: 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] - 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-609 : AWT, Java2D, Swing TESTS
+1 -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 5 July 2006 at 19:46, Geir Magnusson Jr [EMAIL PROTECTED] wrote: In HARMONY-681, I applied the patch to build DRLVM as debug by default, but 'rejected' the classlib patch, as it's not overridable as the DRLVM one is. I think that we'd like to be able to set a flag for release build, rather than have to rummage about in each makefile and include. Yea? Nea? I looked at this patch and thought the same thing. It should be quite easy to add an ant property that gets converted to an environment variable[0] - as hy.hdk does - that gets added to the *FLAGS. And the patch was right, it should default to debug on. Regards, -Mark. [0] Maybe two - one for compilation and one for linking. - 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] milestones and roadmap
On 6 July 2006 at 0:46, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Mark Hindess wrote: On 20 June 2006 at 19:24, Mikhail Loenko [EMAIL PROTECTED] wrote: 2006/6/20, Geir Magnusson Jr [EMAIL PROTECTED]: I'd like to start assembling a high-level roadmap of the milestones we'd like to achieve in the next 12 months. I volunteer to track and organize, but this clearly is a community activity so lets start by just tossing out ideas. 1) By ApcheCon EU - a combined snapshot that is a pure open source VM + classlib. Issues - I assume we'll use DRLVM. 1.5) Reduce classlib code to one implementation per module. What does this mean, exactly? One rmi, crypto, and math. That is, either derive a new implementation with the lessons-learnt from the existing implementations or just pick one and move the others to archive. -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: Using Visual Studio C++ Express to compile classlib - fails.
On 5 July 2006 at 13:39, =?ISO-8859-1?Q?Thorbj=F8rn_Ravn_Andersen?= [EMAIL PROTECTED] wrote: Oliver Deakin skrev den 27-06-2006 12:25: Do you mean the header files in deploy/include? If so, the reason they are copied there is so that they are in a shared location for all modules. (In fact it's the same reason that libs are built into deploy/lib and makefile includes are copied into deploy/build/make). So it is basically a platform agnostic symbolic link? No. It is intended that modules can build against the resulting deploy tree without having to know about the structure/location of the other modules. Personally I do not like doing it so, would it be possible to do it with -I's instead so we do not have redundant copies lying around? You could use -I flags but then each module would need to know the location of the header files of the other modules. It would also mean we'd need to separate the header that describe internal APIs and external APIs within modules making the include paths within modules more complicated. Now it is quite clear what represents the external API - only the headers in deploy. As a consequence, they could also *only* checkout the module they are interested in, rather than the whole of classlib/trunk, and still be able to rebuild their altered code. I have heard this discussion, but I am not convinced that having lots of different building enviroments is a good idea. But the key here is that since even when you check out everything you are still building against deploy so in fact the build environment from the perspective of a single module is actually identical _not_ different. (Thaft is, no matter how a module is built it's always building against what is in deploy and never peek directly in to other modules.) I think this is important to ensure that modules are always a well-defined unit that can be replaced. I can however also appreciate tolerable build times :) Agreed, but I don't think that is the main motivation. 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: svn commit: r418195 - /incubator/harmony/enhanced/classlib/trunk/modules/tools/src/main/java/org/apache/harmony/tools/javac/Compiler.java
On 5 July 2006 at 10:06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Mark Hindess wrote: Sorry to interrupt your game, Umpire, can you get this streaker off the court, please? :) :-) but is there any reason why the jar must have the version number in the name - it's in the MANIFEST after all. Couldn't we just copy it to deploy/jdk/lib/ecj.jar? After all, we don't put a version number in the names of any other jars? And I've always found that to be a nightmare when trying to sort out what is what. It's so much easier to just look at the filename. I think the filename should be irrelevant, btw, hence the proposal for the services idea. I wonder what users expect? For instance, people are used to tools.jar not tools-1.0.jar. Having a consistent name makes it easier for people to point to it. (The truth comes out ... ) I guess the reason I mention this is that I was try to set up an ant script to use the ecj.jar from the Harmony JDK and it was simpler to write the script to point to ecj.jar than to have to locate ecj-*.jar. Regards, Mark. (We'd still want to allow the user to override the location.) Regards, Mark. On 4 July 2006 at 8:52, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Actually, what about some kind of SPI? Or now that JSR-199 in in public draft form, anything useful in there? (There's two more questions 40-love) geir Geir Magnusson Jr wrote: Tim Ellison wrote: Geir Magnusson Jr wrote: Can you get your IDE to invoke ant? Of course, but do you really want our implementation code to be closely coupled to Ant? RIght now it's coupled to a specific version number from eclipse-land that requires the code itself to change when they update. (please answer with a question, I'm getting into the Wimbledon spirit) Maybe we could use a property? :) geir Regards, Tim Tim Ellison wrote: Geir Magnusson Jr wrote: Indeed not. Should we just use an ant filter and a property to set th is ? Does your IDE cope with this? It will require testing exclusively via Ant I think. Regards, Tim geir [EMAIL PROTECTED] wrote: Author: tellison Date: Fri Jun 30 00:49:45 2006 New Revision: 418195 URL: http://svn.apache.org/viewvc?rev=418195view=rev Log: Update compiler impl reference (should not be hardcoded like this) Modified: incubator/harmony/enhanced/classlib/trunk/modules/tools/src/main /j ava/org/apache/harmony/tools/javac/Compiler.java Modified: incubator/harmony/enhanced/classlib/trunk/modules/tools/sr c/ main/java/org/apache/harmony/tools/javac/Compiler.java URL: http://svn.apache.org/viewvc/incubator/harmony/enhanced/classli b/ trunk/modules/tools/src/main/java/org/apache/harmony/tools/javac/Compiler. jav a?rev=418195r1=418194r2=418195view=diff == --- incubator/harmony/enhanced/classlib/trunk/modules/tools/src/main /j ava/org/apache/harmony/tools/javac/Compiler.java (original) +++ incubator/harmony/enhanced/classlib/trunk/modules/tools/src/main /j ava/org/apache/harmony/tools/javac/Compiler.java Fri Jun 30 00:49:45 2006 @@ -36,7 +36,7 @@ ISO8859_1); /* FIXME: Hard-coded for now, the name of the ECJ JAR file */ -static final String ECJ_JAR_FILE = ecj_3.2RC5.jar; +static final String ECJ_JAR_FILE = ecj_3.2MAINT.jar; /* The name of the ECJ compiler class */ static final String MAIN_CLASS_NAME = org.eclipse.jdt.internal .c ompiler.batch.Main; - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] g - 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] - 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,
Re: Re: [classlib] Testing conventions - a proposal
On 06/07/06, Richard Liang [EMAIL PROTECTED] wrote: George Harley wrote: A couple of weeks ago I mentioned that the TestNG framework [2] seemed like a reasonably good way of allowing us to both group together different kinds of tests and permit the exclusion of individual tests/groups of tests [3]. I would like to strongly propose that we consider using TestNG as a means of providing the different test configurations required by Harmony. Will try to study TestNG before I can give comment ;-) I'd strongly recommend TestNG for this purpose, too. It's possible to have a limiteless set of annotations for TestNG as well as allowing different (sub)sets of those tests to be run. You can also set up dependencies between stages (e.g. to test sockets, you've got to test the IO ones first) as well as allowing re-running of just failed tests from the command line (a test run can output markers as to which tests passed/failed, and then on subsequent runs just re-run the failing tests). It would also solve a lot of the problems that we've been seeing for OS-specific issues; you can mark a test only to be run on Windows, or on Linux etc. the best thing is that all of these annotations can be combined in whatever ways that you want -- as opposed to a directory-based approach, which is hierarchical and thus not easy to split based on OS or enviornment alone without an exponetial explosion in the possible combinations. 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] Testing conventions - a proposal
Alex Blewitt wrote: On 06/07/06, Richard Liang [EMAIL PROTECTED] wrote: George Harley wrote: A couple of weeks ago I mentioned that the TestNG framework [2] seemed like a reasonably good way of allowing us to both group together different kinds of tests and permit the exclusion of individual tests/groups of tests [3]. I would like to strongly propose that we consider using TestNG as a means of providing the different test configurations required by Harmony. Will try to study TestNG before I can give comment ;-) I'd strongly recommend TestNG for this purpose, too. It's possible to have a limiteless set of annotations for TestNG as well as allowing different (sub)sets of those tests to be run. You can also set up dependencies between stages (e.g. to test sockets, you've got to test the IO ones first) as well as allowing re-running of just failed tests from the command line (a test run can output markers as to which tests passed/failed, and then on subsequent runs just re-run the failing tests). It would also solve a lot of the problems that we've been seeing for OS-specific issues; you can mark a test only to be run on Windows, or on Linux etc. the best thing is that all of these annotations can be combined in whatever ways that you want -- as opposed to a directory-based approach, which is hierarchical and thus not easy to split based on OS or enviornment alone without an exponetial explosion in the possible combinations. Hello Alex, It seems that you're very familiar with TestNG. ;-) So would you please identify what we shall do to transfer from junit to TestNG? Thanks a lot. Alex. - 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 - 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] Testing conventions - a proposal
On 06/07/06, Richard Liang [EMAIL PROTECTED] wrote: It seems that you're very familiar with TestNG. ;-) So would you please identify what we shall do to transfer from junit to TestNG? Thanks a lot. Me? I'm just highly opinionated :-) There's guidelines for migrating from JUnit to TestNG at the home page: http://testng.org/doc/migrating.html Here is a sample use that will convert all the JUnit tests in the src/ directory to TestNG: java org.testng.JUnitConverter -overwrite -annotation -srcdir src :-) There's also instructions about how to set it up with an Ant-based build: http://testng.org/doc/ant.html I'll see if I can migrate the tests I've got in the Pack200 dir to use TestNG, so that you can see what it looks like. Unfortunately, I doubt that I'm going to be able to get to that much before 2 weeks time due to other outstanding commitments ... 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
IMNSHO I don't think we should by default copy the toString() behaviour from the RI, unless mandated by the spec in JavaDoc. Frankly, the toString() has always been undefined, and I'm sick off Java developers saying Well, yes, but I always expect it to be [name='value',name='other value'] and then writing toString() methods that do exactly the same. toString() was never meant to be a dump of the object's fields and values. It was meant to be a string representation of the object. And it's an insanely ineffecient measure to dump out all of an object's fields using toString() anyway, because of all the wasted concatenation that goes on when you have nested objects. It would be much better if Java developers on the whole got over the fascination with toString() and its format, and used better mechanisms for writing out debug state (e.g. dump(Writer) *) if they needed -- or better yet, just used a debugger. Alex. * Why everyone wants to stream toString() values is beyond me. If you just write the output to a stream in the first place, you get the concatenation for free without having to do all that expensive memory manipuation. On 06/07/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Yep. No answer yet. I pinged them for an update, and also asked the toString() question. geir Mikhail Loenko wrote: IIRC Geir was going to ask Sun if we are allowed to copy their exception messages Thanks, Mikhail 2006/7/5, Richard Liang [EMAIL PROTECTED]: Geir Magnusson Jr wrote: Richard Liang wrote: Geir Magnusson Jr wrote: Tim Ellison wrote: Yep, if the spec tells you what the format of the string should be then follow it (since apps may be dependent upon it), otherwise I'd be inclined to invent your own useful string representation. This idea scares me. I think people do depend on toString() when writing apps, and tend to shove that kind of thing to log files and such on server apps. To have our outptut different from Sun's, BEA's, IBM's, Apple's seens like we're asking for trouble. Hello Geir, IMHO, as long as the method does not give confusing message to developers, we are not required to have the same behavior. You may want to refer to the spec of java.lang.Object.toString: ... In general, the toString method returns a string that textually represents this object. The result should be a concise but informative representation that is easy for **a person to read**. ... Sure, but that doesn't mean that it would be reasonable to randomly change the output of a given Class's toString() as long as it would be easy for a person to read :) I know that's not what you are advocating, and I certainly agree that no one should depend on toString() output like that, but I also know that in production systems *I* have done it, and I'm sure others have as well. And there are some cases that we even cannot follow RI. e.g., URLConnection conn = new URL(http://www.apache.org;).openConnection(); System.out.println(conn.toString()); The code above will print sun.net.www.protocol.http.HttpURLConnection:http://www.apache.org; Any comments? Thanks a lot. Well, we could actually print that if that was our impl of URLConnection for HTTP, but still, I think org.apache.harmony.whatever.HttpURLConnection:http://www.apache.org; would be more reasonable than Implementing Class : org.apache.harmony.whatever.HttpURLConnection, Target URI : http://www.apache.org; or something like that, even thought the second is perfectly good. All I'm saying is that unless the output from the RI's toString() is particularly brain-dead, it doesn't seem to be too much of a bother to be similar. Agree. And in fact, it's easier to have the same output as RI's if we are allowed. :-) Could we think this rule also apply to the message when an exception is thrown? Any comments? Thanks a lot. Best regards, Richard Just my $0.02 geir Best regards, Richard 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] -- 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] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe,
Re: [vote] acceptance of HARMONY-609 : AWT, Java2D, Swing TESTS
Ok. I just have to ask. Why did you delete the body of the original message? Mark Hindess wrote: +1 -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: [classlib][testing] excluding the failed tests
More details: it is org/apache/harmony/security/tests/java/security/SecureRandom2Test.java test. At present time it has 2 failing tests with messages about SHA1PRNG algorithm (no support for SHA1PRNG provider). Looks like it is valid tests for non implemented functionality, but, I'm not sure what to do with such TestCase(s): comment these 2 tests or move them into separate TestCase. Ideas? By the way, probably, it worth reviewing *all* excluded TestCases and: 1. Unexclude if all tests pass. 2. Report bug and provide patch for test to make it passing if it failed due to bug in test. 3. Report bug (and provide patch) for implementation to make tests passing, if it was/is bug in implementation and no such issue in JIRA. 4. Specify reasons for excluding TestCases in exclude list to make further clean-up process easier. 5. Review results of this exclude list clean-up activity and then decide what to do with the rest failing tests. I can do it starting next week. Do you think it worth doing? Thanks, Vladimir On 7/6/06, Nathan Beyer [EMAIL PROTECTED] wrote: Did the TestCase run without a failure? If it didn't, then I would ask for you to attempt to fix it and post the patch and the patch to enable it. If it did pass, then just post a patch to enable it or just submit the issue as ask it to be removed from the exclude list. If the test is failing because of a bug, then log an issue about the bug and try to fix the issue. -Nathan -Original Message- From: Vladimir Ivanov [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 05, 2006 12:41 AM To: harmony-dev@incubator.apache.org Subject: Re: [classlib][testing] excluding the failed tests Yesterday I tried to add a regression test to existing in security module TestCase, but, found that the TestCase is in exclude list. I had to un-exclude it, run, check my test passes and exclude the TestCase again - it was a little bit inconvenient, besides, my new valid (I believe) regression test will go directly to exclude list after integration... I see that we are near to decision what to do with failing tests. Am I right that we are at the point of agreement on the following?: There could be two groups of failing tests: *Tests that never passed. *Tests that recently started failing. Test that never passed should be stored in TestCases with suffix Fail ( StringFailTest.java for example). They are subject for review and either deletion or fixing or fixing implementation if they find a bug in API implementation. There should be 0 tests that recently started failing. If such test appears it should be fixed within 24h, otherwise, commit which introduced the failure will be rolled back. Right? Thanks, Vladimir On 7/4/06, Tim Ellison [EMAIL PROTECTED] wrote: Nathan Beyer wrote: Based on what I've seen of the excluded tests, category 1 is the predominate case. This could be validated by looking at old revisions in SVN. I'm sure that is true, I'm just saying that the build system 'normal' state is that all enabled tests pass. My concern was over your statement you have had failing tests for months. What is failing for you now? Regards, Tim -Original Message- From: Geir Magnusson Jr [mailto: [EMAIL PROTECTED] Is this the case where we have two 'categories'? 1) tests that never worked 2) tests that recently broke I think that a #2 should never persist for more than one build iteration, as either things get fixed or backed out. I suppose then we are really talking about category #1, and that we don't have the broken window problem as we never had the window there in the first place? I think it's important to understand this (if it's actually true). geir Tim Ellison wrote: Nathan Beyer wrote: How are other projects handling this? My opinion is that tests, which are expected and know to pass should always be running and if they fail and the failure can be independently recreated, then it's something to be posted on the list, if trivial (typo in build file?), or logged as a JIRA issue. Agreed, the tests we have enabled are run on each build (hourly if things are being committed), and failures are sent to commit list. If it's broken for a significant amount of time (weeks, months), then rather than excluding the test, I would propose moving it to a broken or possibly invalid source folder that's out of the test path. If it doesn't already have JIRA issue, then one should be created. Yes, though I'd be inclined to move it sooner -- tests should not stay broken for more than a couple of days. Recently our breakages have been invalid tests rather than broken implementation, but they still need to be investigated/resolved. I've been living with consistently failing tests for a long time now. Recently it was the unstable
Re: [vote] acceptance of HARMONY-609 : AWT, Java2D, Swing TESTS
On 6 July 2006 at 5:38, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Ok. I just have to ask. Why did you delete the body of the original message? I didn't really give it much thought, but ... Why not? Wasn't the meaning of the +1 comment was perfectly clear from the subject. I had nothing to say about the body of the message which mostly related to the process of voting. -Mark. Mark Hindess wrote: +1 -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: [vote] acceptance of HARMONY-609 : AWT, Java2D, Swing TESTS
Odd. :) Leaving the body does make it clear, given that with long threads, there can be a gap between Subject and body... geir Mark Hindess wrote: On 6 July 2006 at 5:38, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Ok. I just have to ask. Why did you delete the body of the original message? I didn't really give it much thought, but ... Why not? Wasn't the meaning of the +1 comment was perfectly clear from the subject. I had nothing to say about the body of the message which mostly related to the process of voting. -Mark. Mark Hindess wrote: +1 -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: [classlib] compatibility of toString
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. Frankly, the toString() has always been undefined, and I'm sick off Java developers saying Well, yes, but I always expect it to be [name='value',name='other value'] and then writing toString() methods that do exactly the same. toString() was never meant to be a dump of the object's fields and values. It was meant to be a string representation of the object. And it's an insanely ineffecient measure to dump out all of an object's fields using toString() anyway, because of all the wasted concatenation that goes on when you have nested objects. It would be much better if Java developers on the whole got over the fascination with toString() and its format, and used better mechanisms for writing out debug state (e.g. dump(Writer) *) if they needed -- or better yet, just used a debugger. 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? geir Alex. * Why everyone wants to stream toString() values is beyond me. If you just write the output to a stream in the first place, you get the concatenation for free without having to do all that expensive memory manipuation. On 06/07/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Yep. No answer yet. I pinged them for an update, and also asked the toString() question. geir Mikhail Loenko wrote: IIRC Geir was going to ask Sun if we are allowed to copy their exception messages Thanks, Mikhail 2006/7/5, Richard Liang [EMAIL PROTECTED]: Geir Magnusson Jr wrote: Richard Liang wrote: Geir Magnusson Jr wrote: Tim Ellison wrote: Yep, if the spec tells you what the format of the string should be then follow it (since apps may be dependent upon it), otherwise I'd be inclined to invent your own useful string representation. This idea scares me. I think people do depend on toString() when writing apps, and tend to shove that kind of thing to log files and such on server apps. To have our outptut different from Sun's, BEA's, IBM's, Apple's seens like we're asking for trouble. Hello Geir, IMHO, as long as the method does not give confusing message to developers, we are not required to have the same behavior. You may want to refer to the spec of java.lang.Object.toString: ... In general, the toString method returns a string that textually represents this object. The result should be a concise but informative representation that is easy for **a person to read**. ... Sure, but that doesn't mean that it would be reasonable to randomly change the output of a given Class's toString() as long as it would be easy for a person to read :) I know that's not what you are advocating, and I certainly agree that no one should depend on toString() output like that, but I also know that in production systems *I* have done it, and I'm sure others have as well. And there are some cases that we even cannot follow RI. e.g., URLConnection conn = new URL(http://www.apache.org;).openConnection(); System.out.println(conn.toString()); The code above will print sun.net.www.protocol.http.HttpURLConnection:http://www.apache.org; Any comments? Thanks a lot. Well, we could actually print that if that was our impl of URLConnection for HTTP, but still, I think org.apache.harmony.whatever.HttpURLConnection:http://www.apache.org; would be more reasonable than Implementing Class : org.apache.harmony.whatever.HttpURLConnection, Target URI : http://www.apache.org; or something like that, even thought the second is perfectly good. All I'm saying is that unless the output from the RI's toString() is particularly brain-dead, it doesn't seem to be too much of a bother to be similar. Agree. And in fact, it's easier to have the same output as RI's if we are allowed. :-) Could we think this rule also apply to the message when an exception is thrown? Any comments? Thanks a lot. Best regards, Richard Just my $0.02 geir Best regards, Richard 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] -- Richard Liang China Software Development Lab, IBM
Re: Strategy for Harmony to work with Visual Studio 2005?
Xiao-Feng Li wrote: Visual Studio 2005 (Whidbey VC8) C runtime library (CRT) has changed some compilation rules and APIs for better security or ISO/ANSI conformance. Many changes are breaking, i.e., incompatible. For example, it adds safer counterparts for many functions like `strcpy_s' for `strcpy', `sprintf_s' for `sprintf', etc. In this example, the safer version has an additional parameter asking for the buffer size of the destination string to prevent buffer overflow [1] . I personally like the changes, since they make code safer. But Harmony classlib and DRLVM have tons of warnings or failures when compiled with VC8. Some are from the code themselves, some are from supporting codes. The suggested solutions by Microsoft for the security changes are either to temporarily define _CRT_SECURE_NO_DEPRECATE for compilation or to use the changed APIs since Microsoft said they submit the work to standard committee. (Btw, the security changes are the major part, but there are still warnings/failures caused by other changes.) I don't know how other people solve(d) the problem in their Harmony compilation, but to use `#ifdef' for every call site of the changed function looks ugly. Probably we could group all those APIs into a port layer. Since Microsoft has submitted their work to standard committee, looks like those safe APIs will soon become standardized [2]. We may finally have to support them (why not?). Microsoft has tried to produce some tool that can automatically translate the code to work with the safe CRT, but this approach doesn't work in many situations. Another workaround proposed by Microsoft is to overload the original function with a wrapper function that invokes the safer version, but it doesn't work for C code. Since this issue is not specific to Harmony, it's a little bit surprising that I failed to google much useful information in open source commuinty. Or I missed something obvious? I think the key reason is that this is non-standard stuff from microsoft's for-fee toolchain, and people in OSS try to avoid having a dependency on that. I wouldn't mind supporting this at some point a) once it becomes a standard and b) has broad acceptance, but I'm guessing that's going to take years. People who have used the free version of MSFT tools seem to just set the flag as you note. geir Thanks, xiaofeng [1] http://msdn.microsoft.com/msdnmag/issues/05/05/SafeCandC/ [2] http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1146.pdf On 7/6/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Xiao-Feng Li wrote: It has lots of secure enhancement API changes. What's the strategy for those APIs support in Harmony? Huh? What APIs in Visual Studio? 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] - 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
Alex Blewitt wrote: On 06/07/06, Richard Liang [EMAIL PROTECTED] wrote: It seems that you're very familiar with TestNG. ;-) So would you please identify what we shall do to transfer from junit to TestNG? Thanks a lot. Me? I'm just highly opinionated :-) There's guidelines for migrating from JUnit to TestNG at the home page: http://testng.org/doc/migrating.html Here is a sample use that will convert all the JUnit tests in the src/ directory to TestNG: java org.testng.JUnitConverter -overwrite -annotation -srcdir src :-) There's also instructions about how to set it up with an Ant-based build: http://testng.org/doc/ant.html Will read the materials :-) Thanks a lot. I'll see if I can migrate the tests I've got in the Pack200 dir to use TestNG, so that you can see what it looks like. Unfortunately, I doubt that I'm going to be able to get to that much before 2 weeks time due to other outstanding commitments ... If no objection, we can start from Pack200 (when you're free). ;-) Alex. - 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 - 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?
Ok, then I will get back to VC7 at the moment. :-) Let's wait till its acceptance by the community. Actually I don't see them as new APIs; instead, I view them as enforced good coding conventions that help to achieve better security, e.g., always check the buffer size in debug mode. (Personally I like the changes immediately when I met them. My only question was why we didn't do that earlier. :-) Thanks, xiaofeng On 7/6/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: I think the key reason is that this is non-standard stuff from microsoft's for-fee toolchain, and people in OSS try to avoid having a dependency on that. I wouldn't mind supporting this at some point a) once it becomes a standard and b) has broad acceptance, but I'm guessing that's going to take years. People who have used the free version of MSFT tools seem to just set the flag as you note. geir Thanks, xiaofeng [1] http://msdn.microsoft.com/msdnmag/issues/05/05/SafeCandC/ [2] http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1146.pdf On 7/6/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Xiao-Feng Li wrote: It has lots of secure enhancement API changes. What's the strategy for those APIs support in Harmony? Huh? What APIs in Visual Studio? 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] - 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] Testing conventions - a proposal
Alex Blewitt wrote: On 06/07/06, Richard Liang [EMAIL PROTECTED] wrote: It seems that you're very familiar with TestNG. ;-) So would you please identify what we shall do to transfer from junit to TestNG? Thanks a lot. Me? I'm just highly opinionated :-) Hi Alex, I think we are all pretty much in the TestNG novice category :-) There's guidelines for migrating from JUnit to TestNG at the home page: http://testng.org/doc/migrating.html Here is a sample use that will convert all the JUnit tests in the src/ directory to TestNG: java org.testng.JUnitConverter -overwrite -annotation -srcdir src :-) I have done some private experimentation with this command line utility and it seems to work well. In the first instance it would be good to preserve the JUnit nature of the tests - i.e. still have the test classes extend from JUnit TestCase etc - so that there is always a backwards migration path. That's me being paranoid. Note that the equivalent migration functionality in the latest TestNG plug-in for Eclipse did not allow that but, in addition to adding in the annotations, insisted on removing the inheritance from TestCase. There's also instructions about how to set it up with an Ant-based build: http://testng.org/doc/ant.html I'll see if I can migrate the tests I've got in the Pack200 dir to use TestNG, so that you can see what it looks like. Unfortunately, I doubt that I'm going to be able to get to that much before 2 weeks time due to other outstanding commitments ... Alex. Although we haven't gotten round to discussing specifics yet, it is probably timely to mention here that using the TestNG annotations approach (as opposed to the pre-1.5 Javadoc comments approach) will not work so long as we are compiling Harmony code with the jsr14 target. It looked like the annotation metadata did not make it into the generated class files (at least this is what I saw in my own experiments). If we want to use the annotations approach we will have to wait until we move up to compiling for a 1.5 target. Hopefully that will not be too long now.. In the meantime you could try out using the Javadoc comments approach, just to get a feel for how things run. The downside to that is that your test source needs to be available at runtime so that the comments are available for the framework to examine. Best regards, George - 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: svn commit: r419522 - in /incubator/harmony/enhanced/classlib/trunk/modules/nio: .classpath build.xml make/hyproperties.xml src/test/java/common/ src/test/java/common/org/ src/test/java/linux/ src
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). 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.
Thanks,
George
[1]
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200607.mbox/[EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
Author: hindessm
Date: Thu Jul 6 04:20:27 2006
New Revision: 419522
URL: http://svn.apache.org/viewvc?rev=419522view=rev
Log:
Applied changes for [#HARMONY-782] [classlib][nio]Relayout NIO test cases to
platform dependent.
Added:
incubator/harmony/enhanced/classlib/trunk/modules/nio/src/test/java/common/
incubator/harmony/enhanced/classlib/trunk/modules/nio/src/test/java/common/org/
- copied from r419518,
incubator/harmony/enhanced/classlib/trunk/modules/nio/src/test/java/org/
incubator/harmony/enhanced/classlib/trunk/modules/nio/src/test/java/linux/
incubator/harmony/enhanced/classlib/trunk/modules/nio/src/test/java/windows/
Removed:
incubator/harmony/enhanced/classlib/trunk/modules/nio/src/test/java/org/
Modified:
incubator/harmony/enhanced/classlib/trunk/modules/nio/.classpath
incubator/harmony/enhanced/classlib/trunk/modules/nio/build.xml
incubator/harmony/enhanced/classlib/trunk/modules/nio/make/hyproperties.xml
Modified: incubator/harmony/enhanced/classlib/trunk/modules/nio/.classpath
URL:
http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/modules/nio/.classpath?rev=419522r1=419521r2=419522view=diff
==
--- incubator/harmony/enhanced/classlib/trunk/modules/nio/.classpath (original)
+++ incubator/harmony/enhanced/classlib/trunk/modules/nio/.classpath Thu Jul 6
04:20:27 2006
@@ -1,7 +1,9 @@
?xml version=1.0 encoding=UTF-8?
classpath
classpathentry output=bin/main kind=src path=src/main/java/
- classpathentry output=bin/test kind=src path=src/test/java/
+ classpathentry output=bin/test kind=src
path=src/test/java/common/
+ classpathentry output=bin/test kind=src
path=src/test/java/windows/
+ classpathentry output=bin/test kind=src
path=src/test/java/linux/
classpathentry output=bin/test kind=src path=src/test/resources/
classpathentry kind=con path=org.eclipse.pde.core.requiredPlugins/
classpathentry sourcepath=JUNIT_SRC_HOME/junitsrc.zip kind=var
path=JUNIT_HOME/junit.jar/
Modified: incubator/harmony/enhanced/classlib/trunk/modules/nio/build.xml
URL:
http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/modules/nio/build.xml?rev=419522r1=419521r2=419522view=diff
==
--- incubator/harmony/enhanced/classlib/trunk/modules/nio/build.xml (original)
+++ incubator/harmony/enhanced/classlib/trunk/modules/nio/build.xml Thu Jul 6
04:20:27 2006
@@ -35,6 +35,9 @@
use the Eclipse Java compiler. --
property name=build.compiler value=modern /
+property name=hy.nio.src.test.java.platform
+ value=${hy.nio.src.test.java}/../${hy.os} /
+
target name=build depends=compile.java, build.jar /
target name=test depends=build, compile.tests, run.tests /
@@ -108,19 +111,23 @@
mkdir dir=${hy.nio.bin.test} /
- javac srcdir=${hy.nio.src.test.java}
- destdir=${hy.nio.bin.test}
- sourcepath=
- source=${hy.javac.source}
- target=${hy.javac.target}
- debug=${hy.javac.debug}
-
- bootclasspath
- fileset dir=${hy.jdk}/jre/lib/boot
- include name=**/*.jar /
- /fileset
- /bootclasspath
- classpath location=${hy.hdk}/build/test/support.jar
/
+ javac destdir=${hy.nio.bin.test}
+ sourcepath=
+ source=${hy.javac.source}
+ target=${hy.javac.target}
+ debug=${hy.javac.debug}
+
+src
+pathelement location=${hy.nio.src.test.java}/
+pathelement
+ location=${hy.nio.src.test.java.platform}/
+/src
+ bootclasspath
+ fileset dir=${hy.jdk}/jre/lib/boot
+ include name=**/*.jar /
+ /fileset
+ /bootclasspath
+ classpath location=${hy.hdk}/build/test/support.jar /
/javac
/target
@@ -153,6 +160,9 @@
batchtest todir=${hy.tests.reports} haltonfailure=no unless=test.case
fileset
Re: [general] milestones and roadmap (round 1 summary)
Geir - looks accurate to me. A couple of comments in line: Geir Magnusson Jr wrote: I think this captures the input so far w/ a minimum of editorializing on my part for now :) let me know if anything was left off, or if there are new things to be added General === - switch to java 5 - get some of the principal JDK tools in place - use system libraries, dynamically where appropriate - libz, libpng, libjpeg, liblcms, libicu*, etc. - modularity -- DRLVM - refine and document the internal interfaces and API such that one can substitute parts of VM (ex, can the MMTk activities be a first step?) -- classlib - is there opportunity for refactoring classlib natives to be more modular WRT portlib? Build/Test Framework - regular schedule for snapshots. Maybe every two weeks for now? -- classlib -- classlib + DRLVM -- classlib + classlib adapter + jchevm - Build/CI/test framework - Mark/IBM get us booted? -- make it easy for anyone to setup the CI infrastructure and report back to a website here - Performance -- measure baseline -- start looking for hotspots - Stability and reliability -- stress testing - application-driven advancement -- which apps work -- tool for users to generate missing classes reports for us No I'm sure we have this. I wrote one (stand-alone and simple minded) which is still in JIRA (Hamony 165), then I believe that Mark wrote something more sophisticated later on. All we really need to do for identifying missing classes is for people to run their apps a few standard operations with java -verbose:class and capture the output. I volunteer to look at this if anyone wants to do it Or - you could look at Harmony 165 and tell me what needs to be improved - I'm afraid it's Perl though so you may have to learn a new language :-) - JCK -- acquire -- integrate - federated build -- agreement between parts on things like debug/release flag, structure of artifacts (model after classlib for now), common dependency pool where possible, etc Classlib - concurrency : integration of Doug Lea's java.util.concurrency package. -- Nathan is looking at it -- need support from DRLVM + JCHEVM - CORBA - yoko? - JMX -- Mark has MX4J in place -- need to see if we can host MX4J as separate distributable of the Harmony project - package completion roadmap Ports = - em64t platform support - ipf platform support - amd64 - linux/ppc64 - osx/intel - osx/ppc Community = - make things accessible to users - increase commmitter pool - get out of incubator -- I think it's too early now, and we aren't suffering being in here, so I'd prefer to drop this one... Well - yes. Too early now - but it's what we are all working towards isn't it? So what's the harm in stating it as a goal? (p.s. I just got a osx/intel box, so I'm really hoping that port is easy...) - 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: [drlvm] Signed jars cannot be used in classpath
On 7/6/06, Gregory Shimansky [EMAIL PROTECTED] wrote: On Wednesday 05 July 2006 14:33 Alexey Varlamov wrote: Please find the solution in HARMONY-764 and HARMONY-765 JIRAs. Thanks a lot Alexey, I've checked the build with your fixes on linux and now signed jars work. The only addition to these patches that is needed is to copy security/ directory from classlib to drlvm but this is, I think, what Andrey is working on at the moment. I've added a trivial patch in HARMONY-785 that does the necessary copying. Thanks, Andrey. -- 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] -- 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: [jira] Updated: (HARMONY-788) [drlvm] Verifier: parameters and dimensions limit checks fix
During the first pass through bytecode verifier builds an instruction array of the method. While building the instruction array verifier checks constraints for each processed instruction. For instance, for instruction working with local variables verifier checks a range of local variable index, for constant pool index – range of constant pool index and type of constant pool entry, and so on. Java VM Specification has a limitation for arrays dimensions (it's limited to 255). There are 2 instructions which create multi-dimensional arrays – anewarray and multianewarray. The limitation should be checked for these instructions. Checking it verifier constructs a type of created array and counts a number of dimensions and check the limit. Besides array dimensions Java VM Specification has a limit for number of a method arguments (the limitation is 255 arguments). Parsing a descriptor of an invoked method verifier counts the number of arguments and checks if it exceeds the limit. The test which checks the limitations seems to be quite synthetic but verifier should be able to correctly process all classes loaded by VM. On 06/07/06, Pavel Rebriy (JIRA) [EMAIL PROTECTED] wrote: [ http://issues.apache.org/jira/browse/HARMONY-788?page=all ] Pavel Rebriy updated HARMONY-788: - Attachment: 0001-Verifier-parameters-and-dimensions-limit-checks-fix.patch Patch to fix the problem. [drlvm] Verifier: parameters and dimensions limit checks fix Key: HARMONY-788 URL: http://issues.apache.org/jira/browse/HARMONY-788 Project: Harmony Type: Bug Components: VM Reporter: Pavel Rebriy Attachments: 0001-Test.zip, 0001-Verifier-parameters-and-dimensions-limit-checks-fix.patch I've found a bug that DRLVM verifier doesn't check array dimensions and method parameters limits as requested in Java VM Specification. Test checks multianewarray instruction array dimensions and number of arguments for invokevirtual, invokespecial, invokeinterface and invokestatic instructions. To run test use the following command: path to drl vm/bin/ij Test -- 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, Pavel Rebriy
[classlib] Exception throwing compatibility: java.util.Scanner
Hello All,
When I'm trying to implement Scanner.nextInt(int radix), I met a problem.
As we all know, Character.MIN_RADIX equals 2 and Character.MAX_RADIX
equals 36, so the parameter radix can not less than 2 or greater than
36, Otherwise that parameter is illegal.
But on RI, when the parameter radix is illegal, there are different
kinds of Exception thrown.
* If the parameter is less than 0 or greater than 36, RI throws a
StringIndexOutOfBoundsException. Obviously this exception depends
an RI's implementation.
* If the parameter equals 1, RI throws an InputMismatchException
with an additional information The radix 1 is less than the
Character.MIN_RADIX.
* If the parameter equals 0, RI throws a
java.util.regex.PatternSyntaxException whose constructor has three
parameters. And the parameters depends on RI's implementation,
that makes me can not follow RI.
And nothing is documented in the spec. Shall I follow RI's behavior?
Thanks a lot.
Here is the test case to demo this issue.
public void test_nextIntI(){
Scanner s = new Scanner(123 456);
try {
s.nextInt(-1);
fail(Should throw StringIndexOutOfBoundsException);
} catch (StringIndexOutOfBoundsException e) {
// Expected
}
try {
s.nextInt(0);
fail(Should throw PatternSyntaxException);
} catch (PatternSyntaxException e) {
// Expected
}
try {
s.nextInt(1);
fail(Should throw InputMismatchException);
} catch (InputMismatchException e) {
// Expected
}
try {
s.nextInt(40);
fail(Should throw StringIndexOutOfBoundsException);
} catch (StringIndexOutOfBoundsException e) {
// Expected
}
}
--
Richard Liang
China Software Development Lab, IBM
Re: svn commit: r419522 - in /incubator/harmony/enhanced/classlib/trunk/modules/nio: .classpath build.xml make/hyproperties.xml src/test/java/common/ src/test/java/common/org/ src/test/java/linux/ src
Hi, George
I've read that thread, and I agree with you that the test layout is an
issue worthing consideration, but before heading into the discussion on
test convention(again), I want to have a look at TestNG at first so that
I can have more value-add to that thread.
But on the other side, I've committed (to Andrew and Jimmy) that I'll
help to address the platform dependent nio tests, and I guess they may
have got quite a few such kind of tests in hand(I've been urged several
times on the list after my commitment :( ), and IMO it is not necessary
to stop all related work during the discussion, I for sure have no
objection to refactor them later (I promise I will volunteer to do that,
at least for NIO module) if TestNG is identified at last as a better
choice.
George Harley 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). 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.
Thanks,
George
[1]
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200607.mbox/[EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
Author: hindessm
Date: Thu Jul 6 04:20:27 2006
New Revision: 419522
URL: http://svn.apache.org/viewvc?rev=419522view=rev
Log:
Applied changes for [#HARMONY-782] [classlib][nio]Relayout NIO test
cases to platform dependent.
Added:
incubator/harmony/enhanced/classlib/trunk/modules/nio/src/test/java/common/
incubator/harmony/enhanced/classlib/trunk/modules/nio/src/test/java/common/org/
- copied from r419518,
incubator/harmony/enhanced/classlib/trunk/modules/nio/src/test/java/org/
incubator/harmony/enhanced/classlib/trunk/modules/nio/src/test/java/linux/
incubator/harmony/enhanced/classlib/trunk/modules/nio/src/test/java/windows/
Removed:
incubator/harmony/enhanced/classlib/trunk/modules/nio/src/test/java/org/
Modified:
incubator/harmony/enhanced/classlib/trunk/modules/nio/.classpath
incubator/harmony/enhanced/classlib/trunk/modules/nio/build.xml
incubator/harmony/enhanced/classlib/trunk/modules/nio/make/hyproperties.xml
Modified:
incubator/harmony/enhanced/classlib/trunk/modules/nio/.classpath
URL:
http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/modules/nio/.classpath?rev=419522r1=419521r2=419522view=diff
==
--- incubator/harmony/enhanced/classlib/trunk/modules/nio/.classpath
(original)
+++ incubator/harmony/enhanced/classlib/trunk/modules/nio/.classpath
Thu Jul 6 04:20:27 2006
@@ -1,7 +1,9 @@
?xml version=1.0 encoding=UTF-8?
classpath
classpathentry output=bin/main kind=src path=src/main/java/
-classpathentry output=bin/test kind=src path=src/test/java/
+classpathentry output=bin/test kind=src
path=src/test/java/common/
+classpathentry output=bin/test kind=src
path=src/test/java/windows/
+classpathentry output=bin/test kind=src
path=src/test/java/linux/
classpathentry output=bin/test kind=src
path=src/test/resources/
classpathentry kind=con
path=org.eclipse.pde.core.requiredPlugins/
classpathentry sourcepath=JUNIT_SRC_HOME/junitsrc.zip
kind=var path=JUNIT_HOME/junit.jar/
Modified:
incubator/harmony/enhanced/classlib/trunk/modules/nio/build.xml
URL:
http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/modules/nio/build.xml?rev=419522r1=419521r2=419522view=diff
==
--- incubator/harmony/enhanced/classlib/trunk/modules/nio/build.xml
(original)
+++ incubator/harmony/enhanced/classlib/trunk/modules/nio/build.xml
Thu Jul 6 04:20:27 2006
@@ -35,6 +35,9 @@
use the Eclipse Java compiler. --
property name=build.compiler value=modern /
+property name=hy.nio.src.test.java.platform
+ value=${hy.nio.src.test.java}/../${hy.os} /
+
target name=build depends=compile.java, build.jar /
target name=test depends=build, compile.tests, run.tests /
@@ -108,19 +111,23 @@
mkdir dir=${hy.nio.bin.test} /
-javac srcdir=${hy.nio.src.test.java}
-destdir=${hy.nio.bin.test}
-sourcepath=
-source=${hy.javac.source}
-target=${hy.javac.target}
-debug=${hy.javac.debug}
-
-bootclasspath
-fileset dir=${hy.jdk}/jre/lib/boot
-include name=**/*.jar /
-/fileset
-/bootclasspath
-classpath location=${hy.hdk}/build/test/support.jar /
+javac destdir=${hy.nio.bin.test}
+ sourcepath=
+ source=${hy.javac.source}
+ target=${hy.javac.target}
+ debug=${hy.javac.debug}
+
+src
+
Re: [classlib][nio] Platform dependent tests in SocketChannelTest
Andrew,
I've raised HARMONY-782, and thanks Mark, the patch has been applied,
but I must say sorry that it breaks your patch for HARMONY-767(many
thanks to Mark again, he provided a updated patch for this). Please
check it can meet your requirement so far.
And FYI, you may interest another thread discussing the TestNG adoption
proposal, which is related to the test layout convention.
Andrew Zhang wrote:
Paulex,
I also noticed there are several platform-dependent behaviours of
FileChannel.
So I can't wait to see the revised test layout. :)
Will you plan to re-layout NIO test structure recently?
Thank you very much!
On 6/29/06, Paulex Yang [EMAIL PROTECTED] wrote:
If no one objects, I'm volunteer to re-layout the nio module's test
according to our test convention proposal to accommodate the platform
dependent tests.
Jimmy, Jing Lv wrote:
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,
--
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]
--
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: svn commit: r419522 - in /incubator/harmony/enhanced/classlib/trunk/modules/nio: .classpath build.xml make/hyproperties.xml src/test/java/common/ src/test/java/common/org/ src/test/java/linux/ src
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! ;-)
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.
I think Paulex was correct to separate the process of allowing for
platform-specific tests (HARMONY-782) from any JIRA containing new
tests.
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 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.
Regards,
Mark.
Thanks,
George
[1]
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200607.mbox/[EMAIL
PROTECTED]
[EMAIL PROTECTED] wrote:
Author: hindessm
Date: Thu Jul 6 04:20:27 2006
New Revision: 419522
URL: http://svn.apache.org/viewvc?rev=419522view=rev
Log:
Applied changes for [#HARMONY-782] [classlib][nio]Relayout NIO test cases
to platform dependent.
Added:
incubator/harmony/enhanced/classlib/trunk/modules/nio/src/test/java/com
mon/
incubator/harmony/enhanced/classlib/trunk/modules/nio/src/test/java/com
mon/org/
- copied from r419518, incubator/harmony/enhanced/classlib/trunk/modu
les/nio/src/test/java/org/
incubator/harmony/enhanced/classlib/trunk/modules/nio/src/test/java/lin
ux/
incubator/harmony/enhanced/classlib/trunk/modules/nio/src/test/java/win
dows/
Removed:
incubator/harmony/enhanced/classlib/trunk/modules/nio/src/test/java/org
/
Modified:
incubator/harmony/enhanced/classlib/trunk/modules/nio/.classpath
incubator/harmony/enhanced/classlib/trunk/modules/nio/build.xml
incubator/harmony/enhanced/classlib/trunk/modules/nio/make/hyproperties
.xml
Modified: incubator/harmony/enhanced/classlib/trunk/modules/nio/.classpath
URL: http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk
/modules/nio/.classpath?rev=419522r1=419521r2=419522view=diff
===
===
--- incubator/harmony/enhanced/classlib/trunk/modules/nio/.classpath (origi
nal)
+++ incubator/harmony/enhanced/classlib/trunk/modules/nio/.classpath Thu Ju
l 6 04:20:27 2006
@@ -1,7 +1,9 @@
?xml version=1.0 encoding=UTF-8?
classpath
classpathentry output=bin/main kind=src path=src/main/java/
- classpathentry output=bin/test kind=src path=src/test/java/
+ classpathentry output=bin/test kind=src path=src/test/java/common
/
+ classpathentry output=bin/test kind=src path=src/test/java/window
s/
+ classpathentry output=bin/test kind=src path=src/test/java/linux
/
classpathentry output=bin/test kind=src path=src/test/resources/
classpathentry kind=con path=org.eclipse.pde.core.requiredPlugins/
classpathentry sourcepath=JUNIT_SRC_HOME/junitsrc.zip kind=var pat
h=JUNIT_HOME/junit.jar/
Modified: incubator/harmony/enhanced/classlib/trunk/modules/nio/build.xml
URL: http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk
/modules/nio/build.xml?rev=419522r1=419521r2=419522view=diff
===
===
--- incubator/harmony/enhanced/classlib/trunk/modules/nio/build.xml (origin
al)
+++ incubator/harmony/enhanced/classlib/trunk/modules/nio/build.xml Thu Jul
6 04:20:27 2006
@@ -35,6 +35,9 @@
use the Eclipse Java compiler. --
property name=build.compiler value=modern /
+property name=hy.nio.src.test.java.platform
+ value=${hy.nio.src.test.java}/../${hy.os} /
+
target name=build depends=compile.java, build.jar /
target name=test depends=build, compile.tests, run.tests /
@@ -108,19 +111,23 @@
mkdir dir=${hy.nio.bin.test} /
- javac srcdir=${hy.nio.src.test.java}
- destdir=${hy.nio.bin.test}
- sourcepath=
- source=${hy.javac.source}
- target=${hy.javac.target}
- debug=${hy.javac.debug}
-
- bootclasspath
- fileset
Re: [classlib] Exception throwing compatibility: java.util.Scanner
Hi Richard,
Very good example.
You are right, spec says nothing about invalid radix processing for
nextInt(). RI behavior just proves they have no guard check. However
useRadix() produces IAE for the invalid radix and the sound of logic
says that IAE is a proper reaction for wrong radix in any method with
radix. Looks like a bug in RI for me...
Don't beat me please :-), but I would suggest two approaches:
- either no checks for radix, so that underlying algorithm does or
doesn't produce some exceptions
- implement guard check and produce IAE.
I believe that right solution is the second one - produce IAE -
however it potentailly results in less compatibility with RI.
--
Anton Avtamonov,
Intel Middleware Products Division
On 7/6/06, Richard Liang [EMAIL PROTECTED] wrote:
Hello All,
When I'm trying to implement Scanner.nextInt(int radix), I met a problem.
As we all know, Character.MIN_RADIX equals 2 and Character.MAX_RADIX
equals 36, so the parameter radix can not less than 2 or greater than
36, Otherwise that parameter is illegal.
But on RI, when the parameter radix is illegal, there are different
kinds of Exception thrown.
* If the parameter is less than 0 or greater than 36, RI throws a
StringIndexOutOfBoundsException. Obviously this exception depends
an RI's implementation.
* If the parameter equals 1, RI throws an InputMismatchException
with an additional information The radix 1 is less than the
Character.MIN_RADIX.
* If the parameter equals 0, RI throws a
java.util.regex.PatternSyntaxException whose constructor has three
parameters. And the parameters depends on RI's implementation,
that makes me can not follow RI.
And nothing is documented in the spec. Shall I follow RI's behavior?
Thanks a lot.
Here is the test case to demo this issue.
public void test_nextIntI(){
Scanner s = new Scanner(123 456);
try {
s.nextInt(-1);
fail(Should throw StringIndexOutOfBoundsException);
} catch (StringIndexOutOfBoundsException e) {
// Expected
}
try {
s.nextInt(0);
fail(Should throw PatternSyntaxException);
} catch (PatternSyntaxException e) {
// Expected
}
try {
s.nextInt(1);
fail(Should throw InputMismatchException);
} catch (InputMismatchException e) {
// Expected
}
try {
s.nextInt(40);
fail(Should throw StringIndexOutOfBoundsException);
} catch (StringIndexOutOfBoundsException e) {
// Expected
}
}
--
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]
Re: svn commit: r419522 - in /incubator/harmony/enhanced/classlib/trunk/modules/nio: .classpath build.xml make/hyproperties.xml src/test/java/common/ src/test/java/common/org/ src/test/java/linux/ src
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! ;-)
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.
I think Paulex was correct to separate the process of allowing for
platform-specific tests (HARMONY-782) from any JIRA containing new
tests.
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.
Oooops, It's my fault, I was not noticed this reopened one:(... thanks
Mark again to update that patch.
I really need more coffee these days, fortunately the WorldCup is going
to over and I don't need to wake up every 3:00 AM any more! ;-)
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.
Regards,
Mark.
Thanks,
George
[1]
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200607.mbox/[EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
Author: hindessm
Date: Thu Jul 6 04:20:27 2006
New Revision: 419522
URL: http://svn.apache.org/viewvc?rev=419522view=rev
Log:
Applied changes for [#HARMONY-782] [classlib][nio]Relayout NIO test cases
to platform dependent.
Added:
incubator/harmony/enhanced/classlib/trunk/modules/nio/src/test/java/com
mon/
incubator/harmony/enhanced/classlib/trunk/modules/nio/src/test/java/com
mon/org/
- copied from r419518, incubator/harmony/enhanced/classlib/trunk/modu
les/nio/src/test/java/org/
incubator/harmony/enhanced/classlib/trunk/modules/nio/src/test/java/lin
ux/
incubator/harmony/enhanced/classlib/trunk/modules/nio/src/test/java/win
dows/
Removed:
incubator/harmony/enhanced/classlib/trunk/modules/nio/src/test/java/org
/
Modified:
incubator/harmony/enhanced/classlib/trunk/modules/nio/.classpath
incubator/harmony/enhanced/classlib/trunk/modules/nio/build.xml
incubator/harmony/enhanced/classlib/trunk/modules/nio/make/hyproperties
.xml
Modified: incubator/harmony/enhanced/classlib/trunk/modules/nio/.classpath
URL: http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk
/modules/nio/.classpath?rev=419522r1=419521r2=419522view=diff
===
===
--- incubator/harmony/enhanced/classlib/trunk/modules/nio/.classpath (origi
nal)
+++ incubator/harmony/enhanced/classlib/trunk/modules/nio/.classpath Thu Ju
l 6 04:20:27 2006
@@ -1,7 +1,9 @@
?xml version=1.0 encoding=UTF-8?
classpath
classpathentry output=bin/main kind=src path=src/main/java/
- classpathentry output=bin/test kind=src path=src/test/java/
+ classpathentry output=bin/test kind=src path=src/test/java/common
/
+ classpathentry output=bin/test kind=src path=src/test/java/window
s/
+ classpathentry output=bin/test kind=src path=src/test/java/linux
/
classpathentry output=bin/test kind=src path=src/test/resources/
classpathentry kind=con path=org.eclipse.pde.core.requiredPlugins/
classpathentry sourcepath=JUNIT_SRC_HOME/junitsrc.zip kind=var pat
h=JUNIT_HOME/junit.jar/
Modified: incubator/harmony/enhanced/classlib/trunk/modules/nio/build.xml
URL: http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk
/modules/nio/build.xml?rev=419522r1=419521r2=419522view=diff
===
===
--- incubator/harmony/enhanced/classlib/trunk/modules/nio/build.xml (origin
al)
+++ incubator/harmony/enhanced/classlib/trunk/modules/nio/build.xml Thu Jul
6 04:20:27 2006
@@ -35,6 +35,9 @@
use the Eclipse Java compiler. --
property name=build.compiler value=modern /
+property name=hy.nio.src.test.java.platform
+ value=${hy.nio.src.test.java}/../${hy.os} /
+
target name=build depends=compile.java, build.jar /
target
Re: [drlvm] Removing classlib-related tasks from VM build (was Doing the minimum to support Java 5 classfiles)
Hello, For those who're going to rewrite the build: please add copying logging.properties: http://issues.apache.org/jira/browse/HARMONY-789 On 7/5/06, Vladimir Gorr [EMAIL PROTECTED] wrote: On 7/5/06, Salikh Zakirov [EMAIL PROTECTED] wrote: Mark Hindess wrote: Salikh Zakirov wrote: Using the fixed classlib snapshot will remove one factor of uncertainty, and will make the DRLVM behaviour more reproducible. -1 Doing this will hide issues that appear when changes to classlib breaks drlvm. At this stage in the project, I'd rather have such issues be as visible as possible. Such breakages should be relatively easy to fix and any drlvm developer should be capable of rolling back classlib svn until things are fixed if they get impatient. I don't see how it significantly affects reproducibility since it is trivial to check/record the versions of classlib and drlvm svn when an error occurs? I agree that recording revision numbers of both classlib and drlvm will be sufficient to reproduce the problem. The hard part is finding the good ones when the latest revisions do not work, in a case when someone wants to work on something different than fixing the latest breakages. I think that the reasonable compromise is to have both capabilities in the build system (build with classlib snapshot or with latest checkout), and leave it up to contributors to decide which way to use. If DRLVM will be built with the class library snapshot we should be sure it doesn't already contain the breakages. It means the responsible person for the class library snapshot should run the VM tests at least. IMO this will complicate the build process due to the possible test failures because it's not clear on this stage where a cause of error is. Therefore I'd prefer to build from scratch using the recent sources. In the case if any problems happen we can take any other revision either class library or DRLVM sources and re-build them if there are any doubts. In any case you need to take the latest version and to check it when you are finally going to commit your changes. Thanks, Vladimir. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- 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
Paulex Yang wrote:
Richard Liang wrote:
Hello All,
When I'm trying to implement Scanner.nextInt(int radix), I met a
problem.
As we all know, Character.MIN_RADIX equals 2 and Character.MAX_RADIX
equals 36, so the parameter radix can not less than 2 or greater than
36, Otherwise that parameter is illegal.
But on RI, when the parameter radix is illegal, there are different
kinds of Exception thrown.
* If the parameter is less than 0 or greater than 36, RI throws a
StringIndexOutOfBoundsException. Obviously this exception depends
an RI's implementation.
* If the parameter equals 1, RI throws an InputMismatchException
with an additional information The radix 1 is less than the
Character.MIN_RADIX.
* If the parameter equals 0, RI throws a
java.util.regex.PatternSyntaxException whose constructor has three
parameters. And the parameters depends on RI's implementation,
that makes me can not follow RI.
Is this exception thrown by RegEx class? Should we identify at first
if our regular expression has different behavior with RI on some
certain input parameter?
Hello Paulex,
Yes, this exception is thrown by regex, but it depends on RI's
implementation. I don't know how to get the input parameter, any comments?
Richard
And nothing is documented in the spec. Shall I follow RI's behavior?
Thanks a lot.
Here is the test case to demo this issue.
public void test_nextIntI(){
Scanner s = new Scanner(123 456);
try {
s.nextInt(-1);
fail(Should throw StringIndexOutOfBoundsException);
} catch (StringIndexOutOfBoundsException e) {
// Expected
}
try {
s.nextInt(0);
fail(Should throw PatternSyntaxException);
} catch (PatternSyntaxException e) {
// Expected
}
try {
s.nextInt(1);
fail(Should throw InputMismatchException);
} catch (InputMismatchException e) {
// Expected
}
try {
s.nextInt(40);
fail(Should throw StringIndexOutOfBoundsException);
} catch (StringIndexOutOfBoundsException e) {
// Expected
}
}
--
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]
Re: [classlib] Exception throwing compatibility: java.util.Scanner
Anton Avtamonov wrote: Hi Richard, Very good example. You are right, spec says nothing about invalid radix processing for nextInt(). RI behavior just proves they have no guard check. However useRadix() produces IAE for the invalid radix and the sound of logic says that IAE is a proper reaction for wrong radix in any method with radix. Looks like a bug in RI for me... Don't beat me please :-), but I would suggest two approaches: - either no checks for radix, so that underlying algorithm does or doesn't produce some exceptions - implement guard check and produce IAE. I believe that right solution is the second one - produce IAE - however it potentailly results in less compatibility with RI. Thanks a lot, Anton. Actually, I'd like to follow RI's behavior except throwing a meaningless PatternSyntaxException when radix is 0. It's said that RI will update spec instead of implementation when bug is reported[1] [2] ;-) 1. http://www.mail-archive.com/harmony-dev@incubator.apache.org/msg09588.html 2. http://www.mail-archive.com/harmony-dev@incubator.apache.org/msg09589.html -- 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]
Re: [drlvm] Removing classlib-related tasks from VM build (was Doing the minimum to support Java 5 classfiles)
Andrey Chernyshev wrote: On 7/5/06, Salikh Zakirov [EMAIL PROTECTED] wrote: Mark Hindess wrote: Salikh Zakirov wrote: Using the fixed classlib snapshot will remove one factor of uncertainty, and will make the DRLVM behaviour more reproducible. -1 Doing this will hide issues that appear when changes to classlib breaks drlvm. At this stage in the project, I'd rather have such issues be as visible as possible. Such breakages should be relatively easy to fix and any drlvm developer should be capable of rolling back classlib svn until things are fixed if they get impatient. I don't see how it significantly affects reproducibility since it is trivial to check/record the versions of classlib and drlvm svn when an error occurs? I agree that recording revision numbers of both classlib and drlvm will be sufficient to reproduce the problem. The hard part is finding the good ones when the latest revisions do not work, in a case when someone wants to work on something different than fixing the latest breakages. I think that the reasonable compromise is to have both capabilities in the build system (build with classlib snapshot or with latest checkout), and leave it up to contributors to decide which way to use. One more idea - we have a web page with the classlib snapshots over here: http://people.apache.org/dist/incubator/harmony/snapshots/ with an option of downloading the latest classlib snapshot, or a snapshot at a fixed date. By default, drlvm build could use just the latest one. This will allow to catch the possible classlib/drlvm integration issues at the frequency of creating build snapshots. On the other hand, in case the latest classlib appears to be incompatible with vm, people can easily change the link and use any of previous snapshots. How does that sound? I'm -1 for adding any more auto-fetches to DRLVM. 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?
Don't take my word here - we need opines from others, especially the people that work a lot on windows... geir Xiao-Feng Li wrote: Ok, then I will get back to VC7 at the moment. :-) Let's wait till its acceptance by the community. Actually I don't see them as new APIs; instead, I view them as enforced good coding conventions that help to achieve better security, e.g., always check the buffer size in debug mode. (Personally I like the changes immediately when I met them. My only question was why we didn't do that earlier. :-) Thanks, xiaofeng On 7/6/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: I think the key reason is that this is non-standard stuff from microsoft's for-fee toolchain, and people in OSS try to avoid having a dependency on that. I wouldn't mind supporting this at some point a) once it becomes a standard and b) has broad acceptance, but I'm guessing that's going to take years. People who have used the free version of MSFT tools seem to just set the flag as you note. geir Thanks, xiaofeng [1] http://msdn.microsoft.com/msdnmag/issues/05/05/SafeCandC/ [2] http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1146.pdf On 7/6/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Xiao-Feng Li wrote: It has lots of secure enhancement API changes. What's the strategy for those APIs support in Harmony? Huh? What APIs in Visual Studio? 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] - 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]
Re: [classlib] Exception throwing compatibility: java.util.Scanner
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?
try {
Scanner.nextInt(foo);
}
catch {StringInxOutOfBndsEx bar) {
... real problem...
}
catch (InputMismatchEx woogie) {
... erm, a 1?
}
catch (PatternSyntaxException blough) {
.. a 0
}
This is something where I'd suggest we consider doing it per the spec,
and noting the difference... I can't even imagine someone depending on
the IME or PSE to find 1 and 0 respectively...
geir
Richard Liang wrote:
Hello All,
When I'm trying to implement Scanner.nextInt(int radix), I met a problem.
As we all know, Character.MIN_RADIX equals 2 and Character.MAX_RADIX
equals 36, so the parameter radix can not less than 2 or greater than
36, Otherwise that parameter is illegal.
But on RI, when the parameter radix is illegal, there are different
kinds of Exception thrown.
* If the parameter is less than 0 or greater than 36, RI throws a
StringIndexOutOfBoundsException. Obviously this exception depends
an RI's implementation.
* If the parameter equals 1, RI throws an InputMismatchException
with an additional information The radix 1 is less than the
Character.MIN_RADIX.
* If the parameter equals 0, RI throws a
java.util.regex.PatternSyntaxException whose constructor has three
parameters. And the parameters depends on RI's implementation,
that makes me can not follow RI.
And nothing is documented in the spec. Shall I follow RI's behavior?
Thanks a lot.
Here is the test case to demo this issue.
public void test_nextIntI(){
Scanner s = new Scanner(123 456);
try {
s.nextInt(-1);
fail(Should throw StringIndexOutOfBoundsException);
} catch (StringIndexOutOfBoundsException e) {
// Expected
}
try {
s.nextInt(0);
fail(Should throw PatternSyntaxException);
} catch (PatternSyntaxException e) {
// Expected
}
try {
s.nextInt(1);
fail(Should throw InputMismatchException);
} catch (InputMismatchException e) {
// Expected
}
try {
s.nextInt(40);
fail(Should throw StringIndexOutOfBoundsException);
} catch (StringIndexOutOfBoundsException e) {
// Expected
}
}
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[admin] JIRA components
Geir, I quite often want to search JIRA for outstanding DRLVM issues. At the moment, these are mixed in with jchevm, classlibadapter and bootjvm issues. Perhaps we could split the VM component now? 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: svn commit: r419557 - in /incubator/harmony/enhanced/drlvm/trunk/vm: interpreter/src/interpreter.cpp vmcore/src/init/vm.cpp vmcore/src/jit/jit_runtime_support.cpp vmcore/src/verifier/Verifier.cpp
On 6 July 2006 at 10:36, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Ivan Volosyuk wrote: It is good to see that we finally have java1.5 support in DRLVM. One small question, why my authorship was discarded from interpreter.cpp? :) Nothing personal - just a habit... I'm just nipping off author tags as I go along ... Didn't this used to be ASF policy? I thought I recall hearing (at ApacheCon) that this had changed and that authorship tags were now allowed. ... as this code belongs to all of us. Agreed. Maybe it's time to revisit this - does anyone really want them? Personally, no. I don't like them. If you put one name in then everyone who edits it should be entitled to add their name and that just gets out of hand. As you say the code belongs to all of us. 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: svn commit: r419557 - in /incubator/harmony/enhanced/drlvm/trunk/vm: interpreter/src/interpreter.cpp vmcore/src/init/vm.cpp vmcore/src/jit/jit_runtime_support.cpp vmcore/src/verifier/Verifier.cpp
On 7/6/06, Mark Hindess [EMAIL PROTECTED] wrote: On 6 July 2006 at 10:36, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Ivan Volosyuk wrote: It is good to see that we finally have java1.5 support in DRLVM. One small question, why my authorship was discarded from interpreter.cpp? :) Nothing personal - just a habit... I'm just nipping off author tags as I go along ... Didn't this used to be ASF policy? I thought I recall hearing (at ApacheCon) that this had changed and that authorship tags were now allowed. ... as this code belongs to all of us. Agreed. Maybe it's time to revisit this - does anyone really want them? Personally, no. I don't like them. If you put one name in then everyone who edits it should be entitled to add their name and that just gets out of hand. There authors tags was quite useful in DRLVM development to find person responsible for certain component or source file. If it was difficult to fix a bug or implement some feature related to some subcomponent I usually contacted the author of a file to do the job or to help me get through. May be it doesn't makes sense in the open community like harmony. A little bit upset, that I'm no longer mentioned as author of the interpreter.cpp, it was quite a bit of work; not perfect I know. Btw, I have a few bug fixes. Shell I post it to harmony-dev for discussion or just submit its to JIRA? -- 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: [classlib] Testing conventions - a proposal
Mikhail Loenko wrote: 2006/7/5, George Harley [EMAIL PROTECTED]: 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. After looking at the recent changes to the LUNI module tests (where the layout guidelines were applied) I have a real concern that there are serious problems with this approach. We have started down a track of just continually growing the number of test source folders as new categories of test are identified and IMHO that is going to bring complexity and maintenance issues with these tests. Consider the dimensions of tests that we have ... API Harmony-specific Platform-specific Run on classpath Run on bootclasspath Behaves different between Harmony and RI BTW, these are Harmony-specific... I see your point. And I think we need this directory-level split to make it possible to run variuous kinds of tests with different frameworks. We were already discussing that JUnit extensions are not very good for performance testing. In the future we might find out that some new test contribution is inconsistent with the framework we have chosen. So I'm for directory-level separation of the tests. (Probably some categories should have their own build) 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 and have meant that entire test case classes have been excluded from our test runs. I have also been noticing some API test methods that pass fine on Harmony but fail when run against the RI. Are the different behaviours down to errors in the Harmony implementation ? An error in the RI implementation ? A bug in the RI Javadoc ? Only after some investigation has been carried out do we know for sure. That takes time. What do we do with the test methods in the meantime ? Do we push them round the file system into yet another new source folder ? IMHO we need a testing strategy that enables such problem methods to be tracked easily without disruption to the rest of the other tests. A couple of weeks ago I mentioned that the TestNG framework [2] seemed like a reasonably good way of allowing us to both group together different kinds of tests and permit the exclusion of individual tests/groups of tests [3]. I would like to strongly propose that we consider using TestNG as a means of providing the different test configurations required by Harmony. Using a combination of annotations and XML to capture the kinds of sophisticated test configurations that people need, and that allows us to specify down to the individual method, has got to be more scalable and flexible than where we are headed now. Thanks for reading this far. Best regards, George [1] http://incubator.apache.org/harmony/subcomponents/classlibrary/testing.html [2] http://testng.org [3] http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200606.mbox/[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 :
Re: [classlib] debug compilation as default
Gregory Shimansky wrote: On Thursday 06 July 2006 03:46 Geir Magnusson Jr wrote: In HARMONY-681, I applied the patch to build DRLVM as debug by default, but 'rejected' the classlib patch, as it's not overridable as the DRLVM one is. I think that we'd like to be able to set a flag for release build, rather than have to rummage about in each makefile and include. Yea? Nea? +1 for release flag when it is needed I support this as I also think that current classlib build system is rather primitive Don't mistake being simple with being primitive g. It will need to grow as we expand the amount of platform-dependent code, but I suggest we try to keep things as simple as possible. which is easy to alter by developers locally but isn't really meant to be a product build system. What do you mean? But the default I am sure should be debug everywhere, VM, classlib, tools until Harmony leaves the incubation state. I don't think it is tied to project incubation, but I agree that we need a switch that allows debug/release compilation. And if it is debug by default that is fine too. This is what my patch did (if I didn't miss some places in classlib makefiles). Add release switch later when it is needed. Now... is it important to have it? Is it necessary to build classlib even with -mpentium3? I don't think so. That's a different topic -- we should decide which architectures are 'officially' supported. 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: [admin] JIRA components
Sure! have at it! Mark Hindess wrote: Geir, I quite often want to search JIRA for outstanding DRLVM issues. At the moment, these are mixed in with jchevm, classlibadapter and bootjvm issues. Perhaps we could split the VM component now? 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: [classlib] compatibility of toString
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. Frankly, the toString() has always been undefined, and I'm sick off Java developers saying Well, yes, but I always expect it to be [name='value',name='other value'] and then writing toString() methods that do exactly the same. toString() was never meant to be a dump of the object's fields and values. It was meant to be a string representation of the object. And it's an insanely ineffecient measure to dump out all of an object's fields using toString() anyway, because of all the wasted concatenation that goes on when you have nested objects. It would be much better if Java developers on the whole got over the fascination with toString() and its format, and used better mechanisms for writing out debug state (e.g. dump(Writer) *) if they needed -- or better yet, just used a debugger. Alex. * Why everyone wants to stream toString() values is beyond me. If you just write the output to a stream in the first place, you get the concatenation for free without having to do all that expensive memory manipuation. Here here; if only the API was printOn(OutputStream) then we'd all be happy(er). Regards, Tim On 06/07/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Yep. No answer yet. I pinged them for an update, and also asked the toString() question. geir Mikhail Loenko wrote: IIRC Geir was going to ask Sun if we are allowed to copy their exception messages Thanks, Mikhail 2006/7/5, Richard Liang [EMAIL PROTECTED]: Geir Magnusson Jr wrote: Richard Liang wrote: Geir Magnusson Jr wrote: Tim Ellison wrote: Yep, if the spec tells you what the format of the string should be then follow it (since apps may be dependent upon it), otherwise I'd be inclined to invent your own useful string representation. This idea scares me. I think people do depend on toString() when writing apps, and tend to shove that kind of thing to log files and such on server apps. To have our outptut different from Sun's, BEA's, IBM's, Apple's seens like we're asking for trouble. Hello Geir, IMHO, as long as the method does not give confusing message to developers, we are not required to have the same behavior. You may want to refer to the spec of java.lang.Object.toString: ... In general, the toString method returns a string that textually represents this object. The result should be a concise but informative representation that is easy for **a person to read**. ... Sure, but that doesn't mean that it would be reasonable to randomly change the output of a given Class's toString() as long as it would be easy for a person to read :) I know that's not what you are advocating, and I certainly agree that no one should depend on toString() output like that, but I also know that in production systems *I* have done it, and I'm sure others have as well. And there are some cases that we even cannot follow RI. e.g., URLConnection conn = new URL(http://www.apache.org;).openConnection(); System.out.println(conn.toString()); The code above will print sun.net.www.protocol.http.HttpURLConnection:http://www.apache.org; Any comments? Thanks a lot. Well, we could actually print that if that was our impl of URLConnection for HTTP, but still, I think org.apache.harmony.whatever.HttpURLConnection:http://www.apache.org; would be more reasonable than Implementing Class : org.apache.harmony.whatever.HttpURLConnection, Target URI : http://www.apache.org; or something like that, even thought the second is perfectly good. All I'm saying is that unless the output from the RI's toString() is particularly brain-dead, it doesn't seem to be too much of a bother to be similar. Agree. And in fact, it's easier to have the same output as RI's if we are allowed. :-) Could we think this rule also apply to the message when an exception is thrown? Any comments? Thanks a lot. Best regards, Richard Just my $0.02 geir Best regards, Richard 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] -- Richard Liang China Software Development Lab, IBM - Terms of use :
Re: portlib functionality
(Apologies for the very late response, I'm way behind on my 'must respond' list)... 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? 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. Paulex: is this this something you are considering? 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] mem
(sorry for the very late response) Geir Magnusson Jr wrote: I don't mind the macros, I just think the actual function should be named something different than the macro and have some docs to stem confusion from other readers in the future. Yea/nea? Yea to doc (thanks!) and nea to renaming. It is simple to find the function once you know that they have the same name, and not hard to mentally skip the first arg. My 2c. 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][regex] Acknowledgement of Unicode Character Database
Nathan Beyer wrote: Shouldn't we be using Unicode 4.0.1, since Java 5 RI is 4.0-based and 4.1 is large upgrade? I've used 4.0.1 to implement some of the Character and UnicodeBlock code since it's a 4.0 patch version. Should be attempt to support a single Unicode version for all modules, regardless of which version we pick? A bunch of our TEXT implementation is based on ICU 3.4 which itself conforms to Unicode 4.1. Do you think that there are good reasons to stay with the 4.0 based spec? Regards, Tim -Original Message- From: Geir Magnusson Jr [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 04, 2006 7:13 AM To: harmony-dev@incubator.apache.org Subject: Re: [classlib][regex] Acknowledgement of Unicode Character Database +1 That's fine. Go for it. geir George Harley wrote: Hi, Just noticed that the source file java.util.regex.AbstractCharClass in modules/regex contains the following Javadoc comment for the PredefinedCharacterClasses inner class: /** * character classes generated from * http://www.unicode.org/reports/tr18/ * http://www.unicode.org/Public/4.1.0/ucd/Blocks.txt */ According to the terms of use for Blocks.txt file we need to be including the Unicode Inc. copyright notice somewhere in our documentation. As we do not appear to be doing this currently I would like to propose that we add the following into the file enhanced/classlib/THIRD_PARTY_NOTICES.txt: ---START-- Notice for Unicode Character Database = Copyright C 1991-2005 Unicode, Inc. All rights reserved. Distributed under the Terms of Use in http://www.unicode.org/copyright.html. Permission is hereby granted, free of charge, to any person obtaining a copy of the Unicode data files and any associated documentation (the Data Files) or Unicode software and any associated documentation (the Software) to deal in the Data Files or Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, and/or sell copies of the Data Files or Software, and to permit persons to whom the Data Files or Software are furnished to do so, provided that (a) the above copyright notice(s) and this permission notice appear with all copies of the Data Files or Software, (b) both the above copyright notice(s) and this permission notice appear in associated documentation, and (c) there is clear notice in each modified Data File or in the Software as well as in the documentation associated with the Data File(s) or Software that the data or software has been modified. THE DATA FILES AND SOFTWARE ARE PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OF THIRD PARTY RIGHTS. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR HOLDERS INCLUDED IN THIS NOTICE BE LIABLE FOR ANY CLAIM, OR ANY SPECIAL INDIRECT OR CONSEQUENTIAL DAMAGES, OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THE DATA FILES OR SOFTWARE. Except as contained in this notice, the name of a copyright holder shall not be used in advertising or otherwise to promote the sale, use or other dealings in these Data Files or Software without prior written authorization of the copyright holder. ---FINISH-- Please holler if you think that there is a problem with this addition. Best regards, George - 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] -- 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] mem
-Original Message- From: Tim Ellison [mailto:[EMAIL PROTECTED] Sent: Thursday, July 06, 2006 12:34 PM To: harmony-dev@incubator.apache.org Subject: Re: [classlib] mem (sorry for the very late response) Geir Magnusson Jr wrote: I don't mind the macros, I just think the actual function should be named something different than the macro and have some docs to stem confusion from other readers in the future. Yea/nea? Yea to doc (thanks!) and nea to renaming. It is simple to find the function once you know that they have the same name, and not hard to mentally skip the first arg. What's the downside of renaming? There is no required relationship between the two... 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: [drlvm] Removing classlib-related tasks from VM build (was Doing the minimum to support Java 5 classfiles)
Vladimir Gorr wrote: On 7/5/06, Salikh Zakirov [EMAIL PROTECTED] wrote: Mark Hindess wrote: Salikh Zakirov wrote: Using the fixed classlib snapshot will remove one factor of uncertainty, and will make the DRLVM behaviour more reproducible. -1 Doing this will hide issues that appear when changes to classlib breaks drlvm. At this stage in the project, I'd rather have such issues be as visible as possible. Such breakages should be relatively easy to fix and any drlvm developer should be capable of rolling back classlib svn until things are fixed if they get impatient. I don't see how it significantly affects reproducibility since it is trivial to check/record the versions of classlib and drlvm svn when an error occurs? I agree that recording revision numbers of both classlib and drlvm will be sufficient to reproduce the problem. The hard part is finding the good ones when the latest revisions do not work, in a case when someone wants to work on something different than fixing the latest breakages. I think that the reasonable compromise is to have both capabilities in the build system (build with classlib snapshot or with latest checkout), and leave it up to contributors to decide which way to use. If DRLVM will be built with the class library snapshot we should be sure it doesn't already contain the breakages. It means the responsible person for the class library snapshot should run the VM tests at least. IMO this will complicate the build process due to the possible test failures because it's not clear on this stage where a cause of error is. Therefore I'd prefer to build from scratch using the recent sources. In the case if any problems happen we can take any other revision either class library or DRLVM sources and re-build them if there are any doubts. In any case you need to take the latest version and to check it when you are finally going to commit your changes. I agree, we have to keep these things working together, and carefully manage the interface between VM and class library to allow for such forward compatibility. Downloading a particular snapshot/revision of classlib to work against is not a good idea IMHO. 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: [drlvm] Removing classlib-related tasks from VM build (was Doing the minimum to support Java 5 classfiles)
Geir Magnusson Jr wrote: I'm -1 for adding any more auto-fetches to DRLVM. me too, for the record. 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]Using APR for Harmony's native link to the OS
Marina Goldburt wrote: The patch is only an experiment to change the internal portlib implementation, that, as I think, reveals some design/implementation problems of the luni module. Please elaborate. I'm pleased that you are looking at this code, but may I suggest that you make a point of talking to people here early rather than crafting a large patch in silence. Firstly, it means that we all learn from your learning experience; and secondly if there is some doubt over the approach you will hear about it quicker. Sorry if that sounds negative, but I'd hate to see your hard work and enthusiasm wasted. Regards, Tim I think, it makes sense to move all platform-specific code of the luni into the portlib. And in parallel to cooperate with the APR developers on making it possible to use APR without pools - that, of course, the main problem that makes the APR not suitable for JVM needs. By the end of the process We'll have platform independent interface to operating system functionality, that covers all the luni needs, isolating in the portlib and can switch the portlib implementation to APR (if it have the appropriate memory model by the moment). Marina. On 7/4/06, Mark Hindess [EMAIL PROTECTED] wrote: On 4 July 2006 at 13:13, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Marina Goldburt wrote: Hi, To support the idea mentioned in the letter http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200602.mbox/ [EMAIL PROTECTED], I've tried to implement the file I/O part of the Harmony portlib using APR. The JIRA issue with the patch is http://issues.apache.org/jira/browse/HARMONY-751. I wouldn't want to tie us to APR like this - I can see us offering an APR port that is a peer to the native Windows and Linux.ia32 ports [it would be fun to test performance differences], but not make it the core, shared implementation. +1 I'd always imagined it would progress this way until it was in a position to supplant the current ports. -Mark. - 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]
Re: svn commit: r419522 - in /incubator/harmony/enhanced/classlib/trunk/modules/nio: .classpath build.xml make/hyproperties.xml src/test/java/common/ src/test/java/common/org/ src/test/java/linux/ src
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. 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 :-) 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. Regards, Mark. 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 ?? Best regards, George Thanks, George [1] http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200607.mbox/[EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: hindessm Date: Thu Jul 6 04:20:27 2006 New Revision: 419522 URL: http://svn.apache.org/viewvc?rev=419522view=rev Log: Applied changes for [#HARMONY-782] [classlib][nio]Relayout NIO test cases to platform dependent. Added: incubator/harmony/enhanced/classlib/trunk/modules/nio/src/test/java/com mon/ incubator/harmony/enhanced/classlib/trunk/modules/nio/src/test/java/com mon/org/ - copied from r419518, incubator/harmony/enhanced/classlib/trunk/modu les/nio/src/test/java/org/ incubator/harmony/enhanced/classlib/trunk/modules/nio/src/test/java/lin ux/ incubator/harmony/enhanced/classlib/trunk/modules/nio/src/test/java/win dows/ Removed: incubator/harmony/enhanced/classlib/trunk/modules/nio/src/test/java/org / Modified: incubator/harmony/enhanced/classlib/trunk/modules/nio/.classpath incubator/harmony/enhanced/classlib/trunk/modules/nio/build.xml incubator/harmony/enhanced/classlib/trunk/modules/nio/make/hyproperties .xml Modified: incubator/harmony/enhanced/classlib/trunk/modules/nio/.classpath URL: http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk /modules/nio/.classpath?rev=419522r1=419521r2=419522view=diff === === --- incubator/harmony/enhanced/classlib/trunk/modules/nio/.classpath (origi nal) +++ incubator/harmony/enhanced/classlib/trunk/modules/nio/.classpath Thu Ju l 6 04:20:27 2006 @@ -1,7 +1,9 @@ ?xml version=1.0 encoding=UTF-8? classpath classpathentry output=bin/main kind=src path=src/main/java/ - classpathentry output=bin/test kind=src path=src/test/java/ + classpathentry output=bin/test kind=src path=src/test/java/common / + classpathentry output=bin/test kind=src path=src/test/java/window s/ + classpathentry output=bin/test kind=src path=src/test/java/linux / classpathentry output=bin/test kind=src path=src/test/resources/ classpathentry kind=con path=org.eclipse.pde.core.requiredPlugins/ classpathentry sourcepath=JUNIT_SRC_HOME/junitsrc.zip kind=var pat h=JUNIT_HOME/junit.jar/ Modified: incubator/harmony/enhanced/classlib/trunk/modules/nio/build.xml URL: http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk /modules/nio/build.xml?rev=419522r1=419521r2=419522view=diff === === ---
Re: [general] milestones and roadmap (round 1 summary)
Geir Magnusson Jr wrote: I think this captures the input so far w/ a minimum of editorializing on my part for now :) let me know if anything was left off, or if there are new things to be added It would be good to expand on some of these topics with specific tasks, then put them on the website so people can see what needs doing (and volunteer!) snip Ports = - em64t platform support - ipf platform support - amd64 - linux/ppc64 - osx/intel - osx/ppc ...and more and more. Again, a plan of how we start to widen the platform coverage a factor at a time (add 64-bitness, little-endian-ness, weak memory model, non-ascii, ...) Community = - make things accessible to users - increase commmitter pool - get out of incubator -- I think it's too early now, and we aren't suffering being in here, so I'd prefer to drop this one... I don't see it as a case of 'suffering' or not, if we meet the criteria for graduation then we should go for it. Graduation means that our infrastructure, communications, and decision making process have stabilized in a manner consistent with other successful ASF projects and that the project is fully endorsed by the ASF -- they sound like things we should aim for. 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: Strategy for Harmony to work with Visual Studio 2005?
This particular mail (by Gregory) contains (a) a link to another mail (of his) describing how to get the MSFT tools to work, and (b) a link to a JIRA issue containing the necessary patches to use NASM for assembly: http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200606.mbox/[EMAIL PROTECTED] 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. -Matt --- Geir Magnusson Jr [EMAIL PROTECTED] wrote: Don't take my word here - we need opines from others, especially the people that work a lot on windows... geir Xiao-Feng Li wrote: Ok, then I will get back to VC7 at the moment. :-) Let's wait till its acceptance by the community. Actually I don't see them as new APIs; instead, I view them as enforced good coding conventions that help to achieve better security, e.g., always check the buffer size in debug mode. (Personally I like the changes immediately when I met them. My only question was why we didn't do that earlier. :-) Thanks, xiaofeng On 7/6/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: I think the key reason is that this is non-standard stuff from microsoft's for-fee toolchain, and people in OSS try to avoid having a dependency on that. I wouldn't mind supporting this at some point a) once it becomes a standard and b) has broad acceptance, but I'm guessing that's going to take years. People who have used the free version of MSFT tools seem to just set the flag as you note. geir Thanks, xiaofeng [1] http://msdn.microsoft.com/msdnmag/issues/05/05/SafeCandC/ [2] http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1146.pdf On 7/6/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Xiao-Feng Li wrote: It has lots of secure enhancement API changes. What's the strategy for those APIs support in Harmony? Huh? What APIs in Visual Studio? 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] - 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] __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - 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()
Geir Magnusson Jr wrote: Tim Ellison wrote: Andrey Chernyshev wrote: I'm not sure it is just a name clash problem - drlvm won't give the hythread library if the class lib hadn't requested it. The classlib builds it's own copy of the hythread library, so there is no need for a compatible VM to rebuild it or provide it. VMs are free to use the thread library for their own implementation, or use another thread library (but they shouldn't replace classlib's). Why not? Just curious what the downside is. Maybe I'm missing the point here... ...either you are building the same thread library and replacing it, which is only a waste of time; or you are building a different thread library and replacing it, which is likely to upset the classlib code. 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: svn commit: r419522 - in /incubator/harmony/enhanced/classlib/trunk/modules/nio: .classpath build.xml make/hyproperties.xml src/test/java/common/ src/test/java/common/org/ src/test/java/linux/ src
Paulex Yang wrote:
Hi, George
I've read that thread, and I agree with you that the test layout is an
issue worthing consideration, but before heading into the discussion
on test convention(again), I want to have a look at TestNG at first so
that I can have more value-add to that thread.
Hi Paulex,
Your inclusion of the parenthesized again speaks volumes. Believe me,
I enjoy those sorts of discussions every bit as much as you do. However,
I truly feel that there is something pretty major at stake here which
merits up-front debate.
But on the other side, I've committed (to Andrew and Jimmy) that I'll
help to address the platform dependent nio tests, and I guess they may
have got quite a few such kind of tests in hand(I've been urged
several times on the list after my commitment :( ), and IMO it is not
necessary to stop all related work during the discussion, I for sure
have no objection to refactor them later (I promise I will volunteer
to do that, at least for NIO module) if TestNG is identified at last
as a better choice.
What schedule are you working to here ? Is it so important that it must
be done right now ? Even if it means the possibility of creating a
bundle of no-value tests refactoring work later on to un-do it all ?
One of the reasons that we need the tests layout discussion is so that
we can minimise the endless re-shuffling, slicing and dicing of the test
code. It's a lot of effort for no obvious gain and we need to deal with
it so that we can get on with more valuable activities.
Best regards,
George
George Harley 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). 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.
Thanks,
George
[1]
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200607.mbox/[EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
Author: hindessm
Date: Thu Jul 6 04:20:27 2006
New Revision: 419522
URL: http://svn.apache.org/viewvc?rev=419522view=rev
Log:
Applied changes for [#HARMONY-782] [classlib][nio]Relayout NIO test
cases to platform dependent.
Added:
incubator/harmony/enhanced/classlib/trunk/modules/nio/src/test/java/common/
incubator/harmony/enhanced/classlib/trunk/modules/nio/src/test/java/common/org/
- copied from r419518,
incubator/harmony/enhanced/classlib/trunk/modules/nio/src/test/java/org/
incubator/harmony/enhanced/classlib/trunk/modules/nio/src/test/java/linux/
incubator/harmony/enhanced/classlib/trunk/modules/nio/src/test/java/windows/
Removed:
incubator/harmony/enhanced/classlib/trunk/modules/nio/src/test/java/org/
Modified:
incubator/harmony/enhanced/classlib/trunk/modules/nio/.classpath
incubator/harmony/enhanced/classlib/trunk/modules/nio/build.xml
incubator/harmony/enhanced/classlib/trunk/modules/nio/make/hyproperties.xml
Modified:
incubator/harmony/enhanced/classlib/trunk/modules/nio/.classpath
URL:
http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/modules/nio/.classpath?rev=419522r1=419521r2=419522view=diff
==
--- incubator/harmony/enhanced/classlib/trunk/modules/nio/.classpath
(original)
+++ incubator/harmony/enhanced/classlib/trunk/modules/nio/.classpath
Thu Jul 6 04:20:27 2006
@@ -1,7 +1,9 @@
?xml version=1.0 encoding=UTF-8?
classpath
classpathentry output=bin/main kind=src
path=src/main/java/
-classpathentry output=bin/test kind=src
path=src/test/java/
+classpathentry output=bin/test kind=src
path=src/test/java/common/
+classpathentry output=bin/test kind=src
path=src/test/java/windows/
+classpathentry output=bin/test kind=src
path=src/test/java/linux/
classpathentry output=bin/test kind=src
path=src/test/resources/
classpathentry kind=con
path=org.eclipse.pde.core.requiredPlugins/
classpathentry sourcepath=JUNIT_SRC_HOME/junitsrc.zip
kind=var path=JUNIT_HOME/junit.jar/
Modified:
incubator/harmony/enhanced/classlib/trunk/modules/nio/build.xml
URL:
http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/modules/nio/build.xml?rev=419522r1=419521r2=419522view=diff
==
--- incubator/harmony/enhanced/classlib/trunk/modules/nio/build.xml
(original)
+++ incubator/harmony/enhanced/classlib/trunk/modules/nio/build.xml
Thu Jul 6 04:20:27 2006
@@ -35,6 +35,9 @@
use the Eclipse Java compiler. --
property name=build.compiler value=modern /
+property name=hy.nio.src.test.java.platform
+ value=${hy.nio.src.test.java}/../${hy.os} /
+
target name=build depends=compile.java, build.jar /
target name=test depends=build, compile.tests,
Re: [classlib] debug compilation as default
On Thursday 06 July 2006 20:20 Tim Ellison wrote: Gregory Shimansky wrote: On Thursday 06 July 2006 03:46 Geir Magnusson Jr wrote: In HARMONY-681, I applied the patch to build DRLVM as debug by default, but 'rejected' the classlib patch, as it's not overridable as the DRLVM one is. I think that we'd like to be able to set a flag for release build, rather than have to rummage about in each makefile and include. Yea? Nea? +1 for release flag when it is needed I support this as I also think that current classlib build system is rather primitive Btw no offense intended I meant only native part of the build system. Java part is fine to me. I think I didn't understand the original question well enough. Sure I think it would be good to have more than one mode to build native sources. Don't mistake being simple with being primitive g. It will need to grow as we expand the amount of platform-dependent code, but I suggest we try to keep things as simple as possible. which is easy to alter by developers locally but isn't really meant to be a product build system. What do you mean? (I'll try to answer both your and Geir's question here) The build system for native code is really simple and has most things like even debug on/off mode hardcoded in the flags. It has just one fixed set of flags which don't include debug by default. If any change is required, makefiles have to be changed and I am sure I am not alone who altered them locally to produce debug version. I think we'll come to some sort of configure script but maybe not, it should be discussed separately. I agree that we need to improve it and add more flexible control over what it can produce, debug/release, different architectures, optimizations, maybe compilers. But discussing on the direction which this process should take (e.g. we may agree to add a configure script) may take a long time while a simple change to enable debugging by default doesn't since it seems most of the people agree that it is right thing to do. -- 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: Strategy for Harmony to work with Visual Studio 2005?
On Thursday 06 July 2006 14:35 Xiao-Feng Li wrote: Ok, then I will get back to VC7 at the moment. :-) Let's wait till its acceptance by the community. Actually I don't see them as new APIs; instead, I view them as enforced good coding conventions that help to achieve better security, e.g., always check the buffer size in debug mode. (Personally I like the changes immediately when I met them. My only question was why we didn't do that earlier. :-) If they were just drop in replacements of the old functions this could be done quickly. But they are not compatible for the most part and so may complicate the code significantly to support both old (e.g. VC7 and older, cyginw/mingw targets) and new version. You can use includes from Platform SDK which has headers compatible with old API [1] unless MS has changed new versions of Platform SDK to have this secure stuff and no alternative since I wrote that email. On 7/6/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: I think the key reason is that this is non-standard stuff from microsoft's for-fee toolchain, and people in OSS try to avoid having a dependency on that. I wouldn't mind supporting this at some point a) once it becomes a standard and b) has broad acceptance, but I'm guessing that's going to take years. People who have used the free version of MSFT tools seem to just set the flag as you note. There are two flags. I've found the second in [2]. But I didn't try to use the because I used Platform SDK includes workaround. Maybe defining them is still not enough. [1] http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200606.mbox/208da7a50606011434i405b7d5ao4be8a9fefc52e183%40mail.gmail.com [2] http://www.wxwidgets.org/wiki/index.php/MSVC_.NET_Setup_Guide#Version_Specific_Comments_.26_Instructions -- 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: [drlvm] DRLVM segfaults in hythread_tls_get()
Tim Ellison wrote: Geir Magnusson Jr wrote: Tim Ellison wrote: Andrey Chernyshev wrote: I'm not sure it is just a name clash problem - drlvm won't give the hythread library if the class lib hadn't requested it. The classlib builds it's own copy of the hythread library, so there is no need for a compatible VM to rebuild it or provide it. VMs are free to use the thread library for their own implementation, or use another thread library (but they shouldn't replace classlib's). Why not? Just curious what the downside is. Maybe I'm missing the point here... ...either you are building the same thread library and replacing it, which is only a waste of time; or you are building a different thread library and replacing it, which is likely to upset the classlib code. What if you support the same contracts? I'm trying to figure out where the solution is... 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: author tags
please categorize subject lines... Tim Ellison wrote: Ivan Volosyuk wrote: A little bit upset, that I'm no longer mentioned as author of the interpreter.cpp, it was quite a bit of work; not perfect I know. Sorry that you feel that way. Your feelings illustrates to me why it is easier and arguably fairer to never have author tags. The intent is not to upset people by omitting some names and not others, or getting into debates about whether a JavaDoc spelling correction warrants authorship, etc. I understand that others have opposing opinions, and I don't feel strongly about it. 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]
Re: [classlib] debug compilation as default
Gregory Shimansky wrote: (I'll try to answer both your and Geir's question here) The build system for native code is really simple and has most things like even debug on/off mode hardcoded in the flags. It has just one fixed set of flags which don't include debug by default. If any change is required, makefiles have to be changed and I am sure I am not alone who altered them locally to produce debug version. I think we'll come to some sort of configure script but maybe not, it should be discussed separately. I agree that we need to improve it and add more flexible control over what it can produce, debug/release, different architectures, optimizations, maybe compilers. But discussing on the direction which this process should take (e.g. we may agree to add a configure script) may take a long time while a simple change to enable debugging by default doesn't since it seems most of the people agree that it is right thing to do. Ah, I understand -- yes I agree. Thanks for the clarification. 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] debug compilation as default
Gregory Shimansky wrote: On Thursday 06 July 2006 20:20 Tim Ellison wrote: Gregory Shimansky wrote: On Thursday 06 July 2006 03:46 Geir Magnusson Jr wrote: In HARMONY-681, I applied the patch to build DRLVM as debug by default, but 'rejected' the classlib patch, as it's not overridable as the DRLVM one is. I think that we'd like to be able to set a flag for release build, rather than have to rummage about in each makefile and include. Yea? Nea? +1 for release flag when it is needed I support this as I also think that current classlib build system is rather primitive Btw no offense intended I meant only native part of the build system. Java part is fine to me. I think I didn't understand the original question well enough. Sure I think it would be good to have more than one mode to build native sources. Don't mistake being simple with being primitive g. It will need to grow as we expand the amount of platform-dependent code, but I suggest we try to keep things as simple as possible. which is easy to alter by developers locally but isn't really meant to be a product build system. What do you mean? (I'll try to answer both your and Geir's question here) The build system for native code is really simple and has most things like even debug on/off mode hardcoded in the flags. It has just one fixed set of flags which don't include debug by default. If any change is required, makefiles have to be changed and I am sure I am not alone who altered them locally to produce debug version. I think we'll come to some sort of configure script but maybe not, it should be discussed separately. Right - the argument we're making is that we don't want to have the same problem in reverse via the debug settings. We want to just do this right and have a settable property somewhere, and yes, debug as default is fine. I agree that we need to improve it and add more flexible control over what it can produce, debug/release, different architectures, optimizations, maybe compilers. But discussing on the direction which this process should take (e.g. we may agree to add a configure script) may take a long time while a simple change to enable debugging by default doesn't since it seems most of the people agree that it is right thing to do. But we don't. we agree it's a good default, but a little extra work will just do it via a user-specified property. Patch welcome :) 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 7/6/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: I think the key reason is that this is non-standard stuff from microsoft's for-fee toolchain, and people in OSS try to avoid having a dependency on that. I wouldn't mind supporting this at some point a) once it becomes a standard and b) has broad acceptance, but I'm guessing that's going to take years. People who have used the free version of MSFT tools seem to just set the flag as you note. Honestly that seems like the best approach to me. Otherwise, you'll get tons of warnings from code that's intended to be portable across C compilers, which can't possibly be expected to switch to the microsoft-only APIs. Switching to the microsoft-only APIs inside of specialized parts of the tree that are only used on windows is one thing, but even then I'd advise against it since it ties you too closely to their toolchain. -garrett - 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()
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? Geir Magnusson Jr wrote: Tim Ellison wrote: Geir Magnusson Jr wrote: Tim Ellison wrote: Andrey Chernyshev wrote: I'm not sure it is just a name clash problem - drlvm won't give the hythread library if the class lib hadn't requested it. The classlib builds it's own copy of the hythread library, so there is no need for a compatible VM to rebuild it or provide it. VMs are free to use the thread library for their own implementation, or use another thread library (but they shouldn't replace classlib's). Why not? Just curious what the downside is. Maybe I'm missing the point here... ...either you are building the same thread library and replacing it, which is only a waste of time; or you are building a different thread library and replacing it, which is likely to upset the classlib code. What if you support the same contracts? I'm trying to figure out where the solution is... 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][testing] excluding the failed tests
Vladimir Ivanov wrote: More details: it is org/apache/harmony/security/tests/java/security/SecureRandom2Test.java test. At present time it has 2 failing tests with messages about SHA1PRNG algorithm (no support for SHA1PRNG provider). Looks like it is valid tests for non implemented functionality, but, I'm not sure what to do with such TestCase(s): comment these 2 tests or move them into separate TestCase. Ideas? I'd prefer that we only use one mechanism for excluding tests, and today that is the excludes clause in the ant script. So I suggest that you do option (4) below. If there are really useful tests that are being unnecessarily excluded by being in the same *Test class, then you may want to consider moving the failing tests into SecureRandom3Test and excluding that -- but by the sound of it all SecureRandom tests will be failing. By the way, probably, it worth reviewing *all* excluded TestCases and: 1. Unexclude if all tests pass. 2. Report bug and provide patch for test to make it passing if it failed due to bug in test. 3. Report bug (and provide patch) for implementation to make tests passing, if it was/is bug in implementation and no such issue in JIRA. 4. Specify reasons for excluding TestCases in exclude list to make further clean-up process easier. 5. Review results of this exclude list clean-up activity and then decide what to do with the rest failing tests. I can do it starting next week. Do you think it worth doing? Thanks, Vladimir Sounds great, thanks Vladimir. 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: svn commit: r419522 - in /incubator/harmony/enhanced/classlib/trunk/modules/nio: .classpath build.xml make/hyproperties.xml src/test/java/common/ src/test/java/common/org/ src/test/java/linux/ src
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. 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? While I see the importance of the restructuring I'm also keen not to prevent the problematic nio tests to be fixed. 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. - 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
Magnusson, Geir wrote: -Original Message- From: Tim Ellison [mailto:[EMAIL PROTECTED] Sent: Thursday, July 06, 2006 12:34 PM To: harmony-dev@incubator.apache.org Subject: Re: [classlib] mem (sorry for the very late response) Geir Magnusson Jr wrote: I don't mind the macros, I just think the actual function should be named something different than the macro and have some docs to stem confusion from other readers in the future. Yea/nea? Yea to doc (thanks!) and nea to renaming. It is simple to find the function once you know that they have the same name, and not hard to mentally skip the first arg. What's the downside of renaming? There is no required relationship between the two... It is simple to find the function once you know that they have the same name. -- 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
On Thursday 06 July 2006 16:49, 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? I think we have to distinguish between exceptions like these, which normally nobody ever sees, unless they are actually writing tests for the core APIs (or unless they make a major programming blunder - and then they'll fix that and forget precisely what exception was thrown) on the one hand, and exceptions which one can reasonably expect to happen sometimes when developing code which may run in a variety of Java environments. An example of the latter would be ClassNotFoundException indicating that the runtime environment does not contain some wished-for class or package; if the application programmer builds in a throw..catch clause which implements a fallback, then you'd better theow ClassNotFoundException and not some random thing like NoClassDefFoundError or NPE. Similarly, I just heard from a customer that some application was failing because we were throwing LinkageError when a shared library could not be found, whereas the application only had a handler for UnsatisfiedLinkError. In this case both the RI and the spec were in agreement, but I would happily have made the change even if the spec had specified LinkageError and the RI was throwing the subclass UnsatisfiedLinkError. Fcourse it's not always easy to draw the line between exceptions which probably represent a programmer error and those which robust programs may need to handle, hance there will always be a need to discuss some of these cases. Chris µ -- Chris Gray/k/ Embedded Java Solutions BE0503765045 Embedded Mobile Java, OSGihttp://www.k-embedded-java.com/ [EMAIL PROTECTED] +32 3 216 0369 - 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] verification of classfile format
Gregory Shimansky wrote: On Thursday 06 July 2006 20:26 Geir Magnusson Jr wrote: As part of the work surrounding the HARMONY-677 (r419557), getting DRLVM to deal with Java5 classfile format, I noticed that DRLVM doesn't appear to give a hoot what version of the classfile it's chewing on. It just goes until something blows up. It does check the class file version in bootstrap class loader (vm/vmcore/src/class_support/Class_File_Loader.cpp) and can throw UnsupportedClassVersionError. The constant CLASSFILE_MAJOR_MAX is defined in vm/vmcore/include/Class.h. Ah ha. I think I just skipped over class_parse() when reading through :) I was comparing to j9, which gives a UnsupportedClassVersionError. DRLVM should do the same of course, and it makes me worry what else it outght to be doing - if we don't understand the version of the class file, how can we read it dependably? For some reason I don't really know the constant was changed to 49 as if VM did support class files of version 1.5. Maybe it was the first step to support 1.5 classes :) Well, that explains that. Sorry about that. My bad. I've verified that it works as expected (namely throws the UCVE on a v49 class w/ DRLVM set to v48) I was reading down through j.l.ClassLoader and natives, and given the dearth of comments, didn't quite grok where a good place to start doing some verification would be... Maybe I missed it. Can anyone give me a hint? I think it should happen in bootstrap class loader since it is the place where class file parsing is done anyway. So the place is in VM native code, not kernel classes. It seems to be. Just need some docs, and maybe some tests... 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] debug compilation as default
On 6 July 2006 at 21:37, Gregory Shimansky [EMAIL PROTECTED] wrote: On Thursday 06 July 2006 20:20 Tim Ellison wrote: Gregory Shimansky wrote: On Thursday 06 July 2006 03:46 Geir Magnusson Jr wrote: In HARMONY-681, I applied the patch to build DRLVM as debug by default, but 'rejected' the classlib patch, as it's not overridable as the DRLVM one is. I think that we'd like to be able to set a flag for release build, rather than have to rummage about in each makefile and include. Yea? Nea? +1 for release flag when it is needed I support this as I also think that current classlib build system is rather primitive Btw no offense intended I meant only native part of the build system. Java part is fine to me. None taken. Personally, I think primitive in the sense of not yet evolved is precisely what it is. At the moment, it does the job. However, I've hacked the CFLAGS more than once so it's definitely time it evolved a little. I think I didn't understand the original question well enough. Sure I think it would be good to have more than one mode to build native sources. Don't mistake being simple with being primitive g. It will need to grow as we expand the amount of platform-dependent code, but I suggest we try to keep things as simple as possible. which is easy to alter by developers locally but isn't really meant to be a product build system. What do you mean? (I'll try to answer both your and Geir's question here) The build system for native code is really simple and has most things like even debug on/off mode hardcoded in the flags. It has just one fixed set of flags which don't include debug by default. If any change is required, makefiles have to be changed and I am sure I am not alone who altered them locally to produce debug version. Can you describe how you've been altering them? It would be good to understand what requirements you might have. I've only ever added flags never removed them. Would hy.native.cflags and hy.native.ldflags defined in ant (defaulting to -g but being settable with -D) being added to the make environment and ultimately added to the existing flags be sufficient. Or do you have more requirements? Incidentally, I think it should already be possible to set environment variables to override any of the flags since ant is passing the entire environment to the make call and environment variables take priority. This is ugly though and we should find a more elegant solution. I think we'll come to some sort of configure script but maybe not, it should be discussed separately. I think we may end up there too. We might even evolve from ant to maven. (/me waits to see if Geir will take the bait. ;-) But I don't think we should rush to make changes before there is a compelling demand for them. I agree that we need to improve it and add more flexible control over what it can produce, debug/release, different architectures, optimizations, maybe compilers. But discussing on the direction which this process should take (e.g. we may agree to add a configure script) may take a long time while a simple change to enable debugging by default doesn't since it seems most of the people agree that it is right thing to do. Agreed. Patches welcome. ;-) Or you could just elaborate on your requirements and I might take a shot at it. 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: author tags
+1 in favor of dumping author tags. On 7/6/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: please categorize subject lines... Tim Ellison wrote: Ivan Volosyuk wrote: A little bit upset, that I'm no longer mentioned as author of the interpreter.cpp, it was quite a bit of work; not perfect I know. Sorry that you feel that way. Your feelings illustrates to me why it is easier and arguably fairer to never have author tags. The intent is not to upset people by omitting some names and not others, or getting into debates about whether a JavaDoc spelling correction warrants authorship, etc. I understand that others have opposing opinions, and I don't feel strongly about it. 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] -- Weldon Washburn 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] debug compilation as default
On Thursday 06 July 2006 23:06 Mark Hindess wrote: The build system for native code is really simple and has most things like even debug on/off mode hardcoded in the flags. It has just one fixed set of flags which don't include debug by default. If any change is required, makefiles have to be changed and I am sure I am not alone who altered them locally to produce debug version. Can you describe how you've been altering them? It would be good to understand what requirements you might have. I've only ever added flags never removed them. Would hy.native.cflags and hy.native.ldflags defined in ant (defaulting to -g but being settable with -D) being added to the make environment and ultimately added to the existing flags be sufficient. Or do you have more requirements? For my personal needs so far I've just added debug everywhere. And while we're talking about debugging, optimizing compilers can add debugging information while doing optimizations, when debugging this code many statements may be shifted. So for good debugging there should be no optimization -O0 for gcc and -Od for mscv. If debugging is the default mode it would be good to have it unoptimized as well. To make Tim happy and make it simple I think there should be just two modes, development debug which is the default and high performance release without debug information and optimized. For fine optimization tuning the optimization flags could be moved into separate set which could be altered from ant property or environment, but I am not sure this is needed yet. There is one more thing which has to be mentioned, on win32 linker creates .pdb files for .dll and .exe which actually contain the debug information. They have to be copied to the same directory as the .dll/.exe file to make it available. So on windows they'll have to be copied to the deploy dir. Incidentally, I think it should already be possible to set environment variables to override any of the flags since ant is passing the entire environment to the make call and environment variables take priority. This is ugly though and we should find a more elegant solution. Yes, but this will replace -I and -L flags as well so matching them in environment may be less convenient than just to edit the file to change just a few of them. I think we'll come to some sort of configure script but maybe not, it should be discussed separately. I think we may end up there too. We might even evolve from ant to maven. (/me waits to see if Geir will take the bait. ;-) But I don't think we should rush to make changes before there is a compelling demand for them. Sure, that is what I meant when writing when needed. I agree that we need to improve it and add more flexible control over what it can produce, debug/release, different architectures, optimizations, maybe compilers. But discussing on the direction which this process should take (e.g. we may agree to add a configure script) may take a long time while a simple change to enable debugging by default doesn't since it seems most of the people agree that it is right thing to do. Agreed. Patches welcome. ;-) Or you could just elaborate on your requirements and I might take a shot at it. While I'd really like to help I'll be away from Harmony participation because I go on 2 weeks vacations. If by the time I return I won't be satisfied I'll surely make a patch :) -- 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: svn commit: r419557 - in /incubator/harmony/enhanced/drlvm/trunk/vm: interpreter/src/interpreter.cpp vmcore/src/init/vm.cpp vmcore/src/jit/jit_runtime_support.cpp vmcore/src/verifier/Verifier.cpp
Anyway, I want to make a few changes in interpreter code. There is a fix for a few floating-point to integer conversions' bytecodes which make incorrect clumping. An improvement for diagnostic messages in AbstractMethodError and IllegalAccessError. Is it the right time to do this kind of changes? On 7/6/06, Ivan Volosyuk [EMAIL PROTECTED] wrote: On 7/6/06, Mark Hindess [EMAIL PROTECTED] wrote: .. Btw, I have a few bug fixes. Shell I post it to harmony-dev for discussion or just submit its to JIRA? -- 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: [classlib] debug compilation as default
On 7/7/06, Gregory Shimansky [EMAIL PROTECTED] wrote: On Thursday 06 July 2006 23:06 Mark Hindess wrote: The build system for native code is really simple and has most things like even debug on/off mode hardcoded in the flags. It has just one fixed set of flags which don't include debug by default. If any change is required, makefiles have to be changed and I am sure I am not alone who altered them locally to produce debug version. Can you describe how you've been altering them? It would be good to understand what requirements you might have. I've only ever added flags never removed them. Would hy.native.cflags and hy.native.ldflags defined in ant (defaulting to -g but being settable with -D) being added to the make environment and ultimately added to the existing flags be sufficient. Or do you have more requirements? For my personal needs so far I've just added debug everywhere. And while we're talking about debugging, optimizing compilers can add debugging information while doing optimizations, when debugging this code many statements may be shifted. So for good debugging there should be no optimization -O0 for gcc and -Od for mscv. If debugging is the default mode it would be good to have it unoptimized as well. To make Tim happy and make it simple I think there should be just two modes, development debug which is the default and high performance release without debug information and optimized. For fine optimization tuning the optimization flags could be moved into separate set which could be altered from ant property or environment, but I am not sure this is needed yet. There is one more thing which has to be mentioned, on win32 linker creates .pdb files for .dll and .exe which actually contain the debug information. They have to be copied to the same directory as the .dll/.exe file to make it available. So on windows they'll have to be copied to the deploy dir. Incidentally, I think it should already be possible to set environment variables to override any of the flags since ant is passing the entire environment to the make call and environment variables take priority. This is ugly though and we should find a more elegant solution. Yes, but this will replace -I and -L flags as well so matching them in environment may be less convenient than just to edit the file to change just a few of them. I think we'll come to some sort of configure script but maybe not, it should be discussed separately. I think we may end up there too. We might even evolve from ant to maven. (/me waits to see if Geir will take the bait. ;-) But I don't think we should rush to make changes before there is a compelling demand for them. Sure, that is what I meant when writing when needed. I agree that we need to improve it and add more flexible control over what it can produce, debug/release, different architectures, optimizations, maybe compilers. But discussing on the direction which this process should take (e.g. we may agree to add a configure script) may take a long time while a simple change to enable debugging by default doesn't since it seems most of the people agree that it is right thing to do. Agreed. Patches welcome. ;-) Or you could just elaborate on your requirements and I might take a shot at it. While I'd really like to help I'll be away from Harmony participation because I go on 2 weeks vacations. If by the time I return I won't be satisfied I'll surely make a patch :) I can make this patch. One question, is it ok to have same property as DRLVM for release mode? Like this: BUILD_CFG=release -- 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: Strategy for Harmony to work with Visual Studio 2005?
On 7/6/06, Xiao-Feng Li [EMAIL PROTECTED] wrote: Visual Studio 2005 (Whidbey VC8) C runtime library (CRT) has changed some compilation rules and APIs for better security or ISO/ANSI conformance. Many changes are breaking, i.e., incompatible. For example, it adds safer counterparts for many functions like `strcpy_s' for `strcpy', `sprintf_s' for `sprintf', etc. In this example, the safer version has an additional parameter asking for the buffer size of the destination string to prevent buffer overflow [1] . Just wondering. What is the function sprintf_s for? ISO C99 has another function: snprintf() which makes the job. Linux has the second function. It looks like that this functions should go to port library from now on. -- 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: [classlib] debug compilation as default
On 7 July 2006 at 0:43, Ivan Volosyuk [EMAIL PROTECTED] wrote: On 7/7/06, Gregory Shimansky [EMAIL PROTECTED] wrote: On Thursday 06 July 2006 23:06 Mark Hindess wrote: The build system for native code is really simple and has most things like even debug on/off mode hardcoded in the flags. It has just one fixed set of flags which don't include debug by default. If any change is required, makefiles have to be changed and I am sure I am not alone who altered them locally to produce debug version. Can you describe how you've been altering them? It would be good to understand what requirements you might have. I've only ever added flags never removed them. Would hy.native.cflags and hy.native.ldflags defined in ant (defaulting to -g but being settable with -D) being added to the make environment and ultimately added to the existing flags be sufficient. Or do you have more requirements? For my personal needs so far I've just added debug everywhere. And while we're talking about debugging, optimizing compilers can add debugging information while doing optimizations, when debugging this code many statements may be shifted. So for good debugging there should be no optimization -O0 for gcc and -Od for mscv. If debugging is the default mode it would be good to have it unoptimized as well. To make Tim happy and make it simple I think there should be just two modes, development debug which is the default and high performance release without debug information and optimized. For fine optimization tuning the optimization flags could be moved into separate set which could be altered from ant property or environment, but I am not sure this is needed yet. There is one more thing which has to be mentioned, on win32 linker creates .pdb files for .dll and .exe which actually contain the debug information. They have to be copied to the same directory as the .dll/.exe file to make it available. So on windows they'll have to be copied to the deploy dir. Incidentally, I think it should already be possible to set environment variables to override any of the flags since ant is passing the entire environment to the make call and environment variables take priority. This is ugly though and we should find a more elegant solution. Yes, but this will replace -I and -L flags as well so matching them in environment may be less convenient than just to edit the file to change just a few of them. I think we'll come to some sort of configure script but maybe not, it should be discussed separately. I think we may end up there too. We might even evolve from ant to maven. (/me waits to see if Geir will take the bait. ;-) But I don't think we should rush to make changes before there is a compelling demand for them. Sure, that is what I meant when writing when needed. I agree that we need to improve it and add more flexible control over what it can produce, debug/release, different architectures, optimizations, maybe compilers. But discussing on the direction which this process should take (e.g. we may agree to add a configure script) may take a long time while a simple change to enable debugging by default doesn't since it seems most of the people agree that it is right thing to do. Agreed. Patches welcome. ;-) Or you could just elaborate on your requirements and I might take a shot at it. While I'd really like to help I'll be away from Harmony participation because I go on 2 weeks vacations. If by the time I return I won't be satisfied I'll surely make a patch :) ;-) Have a good vacation. 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 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. 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. ;-) 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: svn commit: r419522 - in /incubator/harmony/enhanced/classlib/trunk/modules/nio: .classpath build.xml make/hyproperties.xml src/test/java/common/ src/test/java/common/org/ src/test/java/linux/ src
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 : 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] debug compilation as default
On 7/7/06, Mark Hindess [EMAIL PROTECTED] wrote: On 7 July 2006 at 0:43, Ivan Volosyuk [EMAIL PROTECTED] wrote: On 7/7/06, Gregory Shimansky [EMAIL PROTECTED] wrote: On Thursday 06 July 2006 23:06 Mark Hindess wrote: The build system for native code is really simple and has most things like even debug on/off mode hardcoded in the flags. It has just one fixed set of flags which don't include debug by default. If any change is required, makefiles have to be changed and I am sure I am not alone who altered them locally to produce debug version. Can you describe how you've been altering them? It would be good to understand what requirements you might have. I've only ever added flags never removed them. Would hy.native.cflags and hy.native.ldflags defined in ant (defaulting to -g but being settable with -D) being added to the make environment and ultimately added to the existing flags be sufficient. Or do you have more requirements? For my personal needs so far I've just added debug everywhere. And while we're talking about debugging, optimizing compilers can add debugging information while doing optimizations, when debugging this code many statements may be shifted. So for good debugging there should be no optimization -O0 for gcc and -Od for mscv. If debugging is the default mode it would be good to have it unoptimized as well. To make Tim happy and make it simple I think there should be just two modes, development debug which is the default and high performance release without debug information and optimized. For fine optimization tuning the optimization flags could be moved into separate set which could be altered from ant property or environment, but I am not sure this is needed yet. There is one more thing which has to be mentioned, on win32 linker creates .pdb files for .dll and .exe which actually contain the debug information. They have to be copied to the same directory as the .dll/.exe file to make it available. So on windows they'll have to be copied to the deploy dir. Incidentally, I think it should already be possible to set environment variables to override any of the flags since ant is passing the entire environment to the make call and environment variables take priority. This is ugly though and we should find a more elegant solution. Yes, but this will replace -I and -L flags as well so matching them in environment may be less convenient than just to edit the file to change just a few of them. I think we'll come to some sort of configure script but maybe not, it should be discussed separately. I think we may end up there too. We might even evolve from ant to maven. (/me waits to see if Geir will take the bait. ;-) But I don't think we should rush to make changes before there is a compelling demand for them. Sure, that is what I meant when writing when needed. I agree that we need to improve it and add more flexible control over what it can produce, debug/release, different architectures, optimizations, maybe compilers. But discussing on the direction which this process should take (e.g. we may agree to add a configure script) may take a long time while a simple change to enable debugging by default doesn't since it seems most of the people agree that it is right thing to do. Agreed. Patches welcome. ;-) Or you could just elaborate on your requirements and I might take a shot at it. While I'd really like to help I'll be away from Harmony participation because I go on 2 weeks vacations. If by the time I return I won't be satisfied I'll surely make a patch :) ;-) Have a good vacation. 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 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. 2) converting this in to an environment variable so what like hy.hdk gets converted to HY_HDK. Sure. 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.
[testing] Peace (was: Re: svn commit: r419522 - in /incubator/harmony/enhanced/classlib/trunk/modules/nio: .classpath build.xml make/hyproperties.xml src/test/java/common/ src/test/java/common/org/ s
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 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 : 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 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). 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. 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) +1 for #1, #2, #3 and #4 in my interpretation. -- 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] debug compilation as default
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. 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. 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) I will do that as I understood :) +1 for #1, #2, #3 and #4 in my interpretation. -- 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][regex] Acknowledgement of Unicode Character Database
The pieces of Unicode 4.1 that would be of any concern would be the notable changes [1]. If we were to fully support Unicode 4.1 in some classes, like Character.UnicodeBlock, there may be some cases of supporting more than the Java 5 spec (RI). This is probably fine in most cases, but I'd be curious if this had any affect on the JCK or any other JRE tests. I haven't checked the Java 6 spec lately, but it's likely that it has moved to Unicode 4.1. More than anything, I'd just like to have some sort of consensus if a question or a bug about supporting a Unicode 4.1 value comes up. If ICU supports it then I'm even more inclined to support it. -Nathan [1] http://www.unicode.org/versions/Unicode4.1.0/#NotableChanges -Original Message- From: Tim Ellison [mailto:[EMAIL PROTECTED] Sent: Thursday, July 06, 2006 11:44 AM To: harmony-dev@incubator.apache.org Subject: Re: [classlib][regex] Acknowledgement of Unicode Character Database Nathan Beyer wrote: Shouldn't we be using Unicode 4.0.1, since Java 5 RI is 4.0-based and 4.1 is large upgrade? I've used 4.0.1 to implement some of the Character and UnicodeBlock code since it's a 4.0 patch version. Should be attempt to support a single Unicode version for all modules, regardless of which version we pick? A bunch of our TEXT implementation is based on ICU 3.4 which itself conforms to Unicode 4.1. Do you think that there are good reasons to stay with the 4.0 based spec? Regards, Tim -Original Message- From: Geir Magnusson Jr [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 04, 2006 7:13 AM To: harmony-dev@incubator.apache.org Subject: Re: [classlib][regex] Acknowledgement of Unicode Character Database +1 That's fine. Go for it. geir George Harley wrote: Hi, Just noticed that the source file java.util.regex.AbstractCharClass in modules/regex contains the following Javadoc comment for the PredefinedCharacterClasses inner class: /** * character classes generated from * http://www.unicode.org/reports/tr18/ * http://www.unicode.org/Public/4.1.0/ucd/Blocks.txt */ According to the terms of use for Blocks.txt file we need to be including the Unicode Inc. copyright notice somewhere in our documentation. As we do not appear to be doing this currently I would like to propose that we add the following into the file enhanced/classlib/THIRD_PARTY_NOTICES.txt: ---START-- Notice for Unicode Character Database = Copyright C 1991-2005 Unicode, Inc. All rights reserved. Distributed under the Terms of Use in http://www.unicode.org/copyright.html. Permission is hereby granted, free of charge, to any person obtaining a copy of the Unicode data files and any associated documentation (the Data Files) or Unicode software and any associated documentation (the Software) to deal in the Data Files or Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, and/or sell copies of the Data Files or Software, and to permit persons to whom the Data Files or Software are furnished to do so, provided that (a) the above copyright notice(s) and this permission notice appear with all copies of the Data Files or Software, (b) both the above copyright notice(s) and this permission notice appear in associated documentation, and (c) there is clear notice in each modified Data File or in the Software as well as in the documentation associated with the Data File(s) or Software that the data or software has been modified. THE DATA FILES AND SOFTWARE ARE PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OF THIRD PARTY RIGHTS. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR HOLDERS INCLUDED IN THIS NOTICE BE LIABLE FOR ANY CLAIM, OR ANY SPECIAL INDIRECT OR CONSEQUENTIAL DAMAGES, OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THE DATA FILES OR SOFTWARE. Except as contained in this notice, the name of a copyright holder shall not be used in advertising or otherwise to promote the sale, use or other dealings in these Data Files or Software without prior written authorization of the copyright holder. ---FINISH-- Please holler if you think that there is a problem with this addition. Best regards, George - 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
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 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. 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. In regards to tests that must be on the bootclasspath, I would say either just put everything on the bootclasspath (any real harm) or use pattern sets for bootclasspath tests (80% of the time the classes will be java*/*). In regards to stress tests, performance tests and integration tests, I believe these are patently different and should be developed in their own projects. My 2 cents... -Nathan -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 and have meant that entire test case classes have been excluded from our test runs. I have also been noticing some API test methods that pass fine on Harmony but fail when run against the RI. Are the different behaviours down to errors in the Harmony implementation ? An error in the RI implementation ? A bug in the RI Javadoc ? Only after some investigation has been carried out do we know for sure. That takes time. What do we do with the test methods in the meantime ? Do we push them round the file system into yet another new source folder ? IMHO we need a testing strategy that enables such problem methods to be tracked easily without disruption to the rest of the other tests. A couple of weeks ago I mentioned that the TestNG framework [2] seemed like a reasonably good way of allowing us to both group together different kinds of tests and permit the exclusion of individual tests/groups of tests [3]. I would like to strongly propose that we consider using TestNG as a means of providing the different test configurations required by Harmony. Using a combination of annotations and XML to capture the kinds of sophisticated test configurations that people need, and that allows us to specify down to the individual method, has got to be more scalable and flexible than where we are headed now.
Re: [classlib] Exception throwing compatibility: java.util.Scanner
Chris Gray wrote: On Thursday 06 July 2006 16:49, 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? I think we have to distinguish between exceptions like these, which normally nobody ever sees, unless they are actually writing tests for the core APIs (or unless they make a major programming blunder - and then they'll fix that and forget precisely what exception was thrown) on the one hand, and exceptions which one can reasonably expect to happen sometimes when developing code which may run in a variety of Java environments. An example of the latter would be ClassNotFoundException indicating that the runtime environment does not contain some wished-for class or package; if the application programmer builds in a throw..catch clause which implements a fallback, then you'd better theow ClassNotFoundException and not some random thing like NoClassDefFoundError or NPE. Similarly, I just heard from a customer that some application was failing because we were throwing LinkageError when a shared library could not be found, whereas the application only had a handler for UnsatisfiedLinkError. In this case both the RI and the spec were in agreement, but I would happily have made the change even if the spec had specified LinkageError and the RI was throwing the subclass UnsatisfiedLinkError. Fcourse it's not always easy to draw the line between exceptions which probably represent a programmer error and those which robust programs may need to handle, hance there will always be a need to discuss some of these cases. Thanks a lot, Chris. We may frequently encounter this confused situation, and I suggest we discuss the problems case by case if someone is not sure how to do. ;-) For this case, I decide to follow useRadix(int radix). Please correct me if I'm wrong. Thanks a lot. Best regards, Richard Chris µ -- Richard Liang China Software Development Lab, IBM
Re: [classlib] Exception throwing compatibility: java.util.Scanner
Richard Liang wrote:
Paulex Yang wrote:
Richard Liang wrote:
Hello All,
When I'm trying to implement Scanner.nextInt(int radix), I met a
problem.
As we all know, Character.MIN_RADIX equals 2 and Character.MAX_RADIX
equals 36, so the parameter radix can not less than 2 or greater
than 36, Otherwise that parameter is illegal.
But on RI, when the parameter radix is illegal, there are different
kinds of Exception thrown.
* If the parameter is less than 0 or greater than 36, RI throws a
StringIndexOutOfBoundsException. Obviously this exception depends
an RI's implementation.
* If the parameter equals 1, RI throws an InputMismatchException
with an additional information The radix 1 is less than the
Character.MIN_RADIX.
* If the parameter equals 0, RI throws a
java.util.regex.PatternSyntaxException whose constructor has three
parameters. And the parameters depends on RI's implementation,
that makes me can not follow RI.
Is this exception thrown by RegEx class? Should we identify at first
if our regular expression has different behavior with RI on some
certain input parameter?
Hello Paulex,
Yes, this exception is thrown by regex, but it depends on RI's
implementation. I don't know how to get the input parameter, any
comments?
Oops, so just forget what I said:). Sorry if I made confusion, I didn't
look closely, just wondering why the regex exception is thrown from
Scanner, and I thought it may be straightforward to separately test the
regex API invocation, probably I'm wrong.
Richard
And nothing is documented in the spec. Shall I follow RI's behavior?
Thanks a lot.
Here is the test case to demo this issue.
public void test_nextIntI(){
Scanner s = new Scanner(123 456);
try {
s.nextInt(-1);
fail(Should throw StringIndexOutOfBoundsException);
} catch (StringIndexOutOfBoundsException e) {
// Expected
}
try {
s.nextInt(0);
fail(Should throw PatternSyntaxException);
} catch (PatternSyntaxException e) {
// Expected
}
try {
s.nextInt(1);
fail(Should throw InputMismatchException);
} catch (InputMismatchException e) {
// Expected
}
try {
s.nextInt(40);
fail(Should throw StringIndexOutOfBoundsException);
} catch (StringIndexOutOfBoundsException e) {
// Expected
}
}
--
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: [classlib] Exception throwing compatibility: java.util.Scanner
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.
Best regards,
Richard.
try {
Scanner.nextInt(foo);
}
catch {StringInxOutOfBndsEx bar) {
... real problem...
}
catch (InputMismatchEx woogie) {
... erm, a 1?
}
catch (PatternSyntaxException blough) {
.. a 0
}
This is something where I'd suggest we consider doing it per the spec,
and noting the difference... I can't even imagine someone depending on
the IME or PSE to find 1 and 0 respectively...
geir
Richard Liang wrote:
Hello All,
When I'm trying to implement Scanner.nextInt(int radix), I met a problem.
As we all know, Character.MIN_RADIX equals 2 and Character.MAX_RADIX
equals 36, so the parameter radix can not less than 2 or greater than
36, Otherwise that parameter is illegal.
But on RI, when the parameter radix is illegal, there are different
kinds of Exception thrown.
* If the parameter is less than 0 or greater than 36, RI throws a
StringIndexOutOfBoundsException. Obviously this exception depends
an RI's implementation.
* If the parameter equals 1, RI throws an InputMismatchException
with an additional information The radix 1 is less than the
Character.MIN_RADIX.
* If the parameter equals 0, RI throws a
java.util.regex.PatternSyntaxException whose constructor has three
parameters. And the parameters depends on RI's implementation,
that makes me can not follow RI.
And nothing is documented in the spec. Shall I follow RI's behavior?
Thanks a lot.
Here is the test case to demo this issue.
public void test_nextIntI(){
Scanner s = new Scanner(123 456);
try {
s.nextInt(-1);
fail(Should throw StringIndexOutOfBoundsException);
} catch (StringIndexOutOfBoundsException e) {
// Expected
}
try {
s.nextInt(0);
fail(Should throw PatternSyntaxException);
} catch (PatternSyntaxException e) {
// Expected
}
try {
s.nextInt(1);
fail(Should throw InputMismatchException);
} catch (InputMismatchException e) {
// Expected
}
try {
s.nextInt(40);
fail(Should throw StringIndexOutOfBoundsException);
} catch (StringIndexOutOfBoundsException e) {
// Expected
}
}
-
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: Strategy for Harmony to work with Visual Studio 2005?
I would suggest another approach.
Since the safe CRT APIs are mostly similar to the original counterpart
but enforcing safety checks and validations, we can take them as
coding conventions, so as to achieve both the safety and portability.
For example, with strcpy, we do this way:
step 1. write a safe version strcpy_s on platforms that have no safe
CRT support, see below.
step 2. replace all strcpy(dst, src) invocations with strcpy_s(dst, count, src);
This version of strcpy_s is only for illustration purpose and follow
the standard safety checkings.
#define MAX_STR_LEN (130)
#ifndef SAFE_CRT
int strcpy_s(dst, count, src)
{
if( dst != null count 0 count = MAX_STR_LEN )
dst[0] = '\0';
if( dst == NULL || src == NULL ) return -1;
if( count == 0 || count MAX_STR_LEN ) return -1;
if( count = strlen(src) ) return -1; //strlen should use safer version
if( mem_overlap (dst, src) ) return -1;
strcpy(dst, src);
return 0;
}
#endif
Thanks,
xiaofeng
On 7/7/06, Gregory Shimansky [EMAIL PROTECTED] wrote:
On Thursday 06 July 2006 14:35 Xiao-Feng Li wrote:
Ok, then I will get back to VC7 at the moment. :-) Let's wait till
its acceptance by the community.
Actually I don't see them as new APIs; instead, I view them as
enforced good coding conventions that help to achieve better security,
e.g., always check the buffer size in debug mode. (Personally I like
the changes immediately when I met them. My only question was why we
didn't do that earlier. :-)
If they were just drop in replacements of the old functions this could be done
quickly. But they are not compatible for the most part and so may complicate
the code significantly to support both old (e.g. VC7 and older, cyginw/mingw
targets) and new version.
You can use includes from Platform SDK which has headers compatible with old
API [1] unless MS has changed new versions of Platform SDK to have this
secure stuff and no alternative since I wrote that email.
On 7/6/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote:
I think the key reason is that this is non-standard stuff from
microsoft's for-fee toolchain, and people in OSS try to avoid having a
dependency on that.
I wouldn't mind supporting this at some point a) once it becomes a
standard and b) has broad acceptance, but I'm guessing that's going to
take years.
People who have used the free version of MSFT tools seem to just set the
flag as you note.
There are two flags. I've found the second in [2]. But I didn't try to use the
because I used Platform SDK includes workaround. Maybe defining them is still
not enough.
[1]
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200606.mbox/208da7a50606011434i405b7d5ao4be8a9fefc52e183%40mail.gmail.com
[2]
http://www.wxwidgets.org/wiki/index.php/MSVC_.NET_Setup_Guide#Version_Specific_Comments_.26_Instructions
--
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]
-
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?
The checks in my code example below can be asserts or defined for
debug mode only, if people worry about the performance AND are almost
sure about the safety. But I don't think they are only for debugging
purpose. Optimizations can be done to reduce the overhead.
Thanks,
xiaofeng
On 7/7/06, Xiao-Feng Li [EMAIL PROTECTED] wrote:
I would suggest another approach.
Since the safe CRT APIs are mostly similar to the original counterpart
but enforcing safety checks and validations, we can take them as
coding conventions, so as to achieve both the safety and portability.
For example, with strcpy, we do this way:
step 1. write a safe version strcpy_s on platforms that have no safe
CRT support, see below.
step 2. replace all strcpy(dst, src) invocations with strcpy_s(dst, count, src);
This version of strcpy_s is only for illustration purpose and follow
the standard safety checkings.
#define MAX_STR_LEN (130)
#ifndef SAFE_CRT
int strcpy_s(dst, count, src)
{
if( dst != null count 0 count = MAX_STR_LEN )
dst[0] = '\0';
if( dst == NULL || src == NULL ) return -1;
if( count == 0 || count MAX_STR_LEN ) return -1;
if( count = strlen(src) ) return -1; //strlen should use safer version
if( mem_overlap (dst, src) ) return -1;
strcpy(dst, src);
return 0;
}
#endif
Thanks,
xiaofeng
On 7/7/06, Gregory Shimansky [EMAIL PROTECTED] wrote:
On Thursday 06 July 2006 14:35 Xiao-Feng Li wrote:
Ok, then I will get back to VC7 at the moment. :-) Let's wait till
its acceptance by the community.
Actually I don't see them as new APIs; instead, I view them as
enforced good coding conventions that help to achieve better security,
e.g., always check the buffer size in debug mode. (Personally I like
the changes immediately when I met them. My only question was why we
didn't do that earlier. :-)
If they were just drop in replacements of the old functions this could be done
quickly. But they are not compatible for the most part and so may complicate
the code significantly to support both old (e.g. VC7 and older, cyginw/mingw
targets) and new version.
You can use includes from Platform SDK which has headers compatible with old
API [1] unless MS has changed new versions of Platform SDK to have this
secure stuff and no alternative since I wrote that email.
On 7/6/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote:
I think the key reason is that this is non-standard stuff from
microsoft's for-fee toolchain, and people in OSS try to avoid having a
dependency on that.
I wouldn't mind supporting this at some point a) once it becomes a
standard and b) has broad acceptance, but I'm guessing that's going to
take years.
People who have used the free version of MSFT tools seem to just set the
flag as you note.
There are two flags. I've found the second in [2]. But I didn't try to use the
because I used Platform SDK includes workaround. Maybe defining them is still
not enough.
[1]
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200606.mbox/208da7a50606011434i405b7d5ao4be8a9fefc52e183%40mail.gmail.com
[2]
http://www.wxwidgets.org/wiki/index.php/MSVC_.NET_Setup_Guide#Version_Specific_Comments_.26_Instructions
--
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]
-
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][regex] Acknowledgement of Unicode Character Database
Nathan Beyer wrote: The pieces of Unicode 4.1 that would be of any concern would be the notable changes [1]. If we were to fully support Unicode 4.1 in some classes, like Character.UnicodeBlock, there may be some cases of supporting more than the Java 5 spec (RI). This is probably fine in most cases, but I'd be curious if this had any affect on the JCK or any other JRE tests. I haven't checked the Java 6 spec lately, but it's likely that it has moved to Unicode 4.1. More than anything, I'd just like to have some sort of consensus if a question or a bug about supporting a Unicode 4.1 value comes up. If ICU supports it then I'm even more inclined to support it. Nathan, just FYI, if you decide to support Unicode 4.1, you may be interest in UCharacter[1][2] provided by ICU4J. Hopefully it can be useful. [1] official release's new features: http://www-306.ibm.com/software/globalization/icu/downloads.jsp [2] UCharacter API reference: http://icu.sourceforge.net/apiref/icu4j/com/ibm/icu/lang/UCharacter.html -Nathan [1] http://www.unicode.org/versions/Unicode4.1.0/#NotableChanges -Original Message- From: Tim Ellison [mailto:[EMAIL PROTECTED] Sent: Thursday, July 06, 2006 11:44 AM To: harmony-dev@incubator.apache.org Subject: Re: [classlib][regex] Acknowledgement of Unicode Character Database Nathan Beyer wrote: Shouldn't we be using Unicode 4.0.1, since Java 5 RI is 4.0-based and 4.1 is large upgrade? I've used 4.0.1 to implement some of the Character and UnicodeBlock code since it's a 4.0 patch version. Should be attempt to support a single Unicode version for all modules, regardless of which version we pick? A bunch of our TEXT implementation is based on ICU 3.4 which itself conforms to Unicode 4.1. Do you think that there are good reasons to stay with the 4.0 based spec? Regards, Tim -Original Message- From: Geir Magnusson Jr [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 04, 2006 7:13 AM To: harmony-dev@incubator.apache.org Subject: Re: [classlib][regex] Acknowledgement of Unicode Character Database +1 That's fine. Go for it. geir George Harley wrote: Hi, Just noticed that the source file java.util.regex.AbstractCharClass in modules/regex contains the following Javadoc comment for the PredefinedCharacterClasses inner class: /** * character classes generated from * http://www.unicode.org/reports/tr18/ * http://www.unicode.org/Public/4.1.0/ucd/Blocks.txt */ According to the terms of use for Blocks.txt file we need to be including the Unicode Inc. copyright notice somewhere in our documentation. As we do not appear to be doing this currently I would like to propose that we add the following into the file enhanced/classlib/THIRD_PARTY_NOTICES.txt: ---START-- Notice for Unicode Character Database = Copyright C 1991-2005 Unicode, Inc. All rights reserved. Distributed under the Terms of Use in http://www.unicode.org/copyright.html. Permission is hereby granted, free of charge, to any person obtaining a copy of the Unicode data files and any associated documentation (the Data Files) or Unicode software and any associated documentation (the Software) to deal in the Data Files or Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, and/or sell copies of the Data Files or Software, and to permit persons to whom the Data Files or Software are furnished to do so, provided that (a) the above copyright notice(s) and this permission notice appear with all copies of the Data Files or Software, (b) both the above copyright notice(s) and this permission notice appear in associated documentation, and (c) there is clear notice in each modified Data File or in the Software as well as in the documentation associated with the Data File(s) or Software that the data or software has been modified. THE DATA FILES AND SOFTWARE ARE PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OF THIRD PARTY RIGHTS. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR HOLDERS INCLUDED IN THIS NOTICE BE LIABLE FOR ANY CLAIM, OR ANY SPECIAL INDIRECT OR CONSEQUENTIAL DAMAGES, OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THE DATA FILES OR SOFTWARE. Except as contained in this notice, the name of a copyright holder shall not be used in advertising or otherwise to promote the sale, use or other dealings in these Data Files or Software without prior written authorization of the copyright holder.
Re: portlib functionality
Tim Ellison wrote: (Apologies for the very late response, I'm way behind on my 'must respond' list)... 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? 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. Paulex: is this this something you are considering? Yes, I'm working on the FileChannel completion, and my thought is to write platform dependent codes for mmap at first(I thought it is easier to be accepted, so that things can be moved forward), then propose a mmap related extension to portlib, and if it is accepted, refactor the codes. The current portlib's mmap API cannot meet the requirement of nio in several ways: 1. cannot map file in modes other than Copy-On-Write 2. cannot map part of file 3. cannot pick up the opened file descriptor as parameter Will look at the file locking later...And I'm sure there are other things worthing evaluation to be portlib extension. Regards, Tim -- 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: [classlib] Testing conventions - a proposal
On 7/5/06, George Harley [EMAIL PROTECTED] 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. After looking at the recent changes to the LUNI module tests (where the layout guidelines were applied) I have a real concern that there are serious problems with this approach. We have started down a track of just continually growing the number of test source folders as new categories of test are identified and IMHO that is going to bring complexity and maintenance issues with these tests. Consider the dimensions of tests that we have ... API Harmony-specific Platform-specific Run on classpath Run on bootclasspath Behaves different between Harmony and RI Stress ...and so on... At least ... 3(common/win/linux) * 2 (classpath/bootclasspath) * 2(api/impl) * ... = 12 * ... Of course, for some module or package, there are only common folder * classpath * api test, that the best thing. The count of folders are really terrifc in worst situation. 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 ? Put my 0.02$ here. Configuration is a better than physical folder layout, not matter by which tool (Junit, TestNG, ) In fact, physical layout is also a configuration, which is controlled by folder directory rather than annotations, xml, ... I think storing test specific information (e.g. only win) in code is better than in folder path (e.g **/win/...). In most cases, annotation by professional test tool is more flexible, and powerful. 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 and have meant that entire test case classes have been excluded from our test runs. I have also been noticing some API test methods that pass fine on Harmony but fail when run against the RI. Are the different behaviours down to errors in the Harmony implementation ? An error in the RI implementation ? A bug in the RI Javadoc ? Only after some investigation has been carried out do we know for sure. That takes time. What do we do with the test methods in the meantime ? Do we push them round the file system into yet another new source folder ? IMHO we need a testing strategy that enables such problem methods to be tracked easily without disruption to the rest of the other tests. A couple of weeks ago I mentioned that the TestNG framework [2] seemed like a reasonably good way of allowing us to both group together different kinds of tests and permit the exclusion of individual tests/groups of tests [3]. I would like to strongly propose that we consider using TestNG as a means of providing the different test configurations required by Harmony. Using a combination of annotations and XML to capture the kinds of sophisticated test configurations that people need, and that allows us to specify down to the individual method, has got to be more scalable and flexible than where we are headed now. Maybe another two cents here after learning TestNG. :) Thanks for reading this far. Best regards, George [1] http://incubator.apache.org/harmony/subcomponents/classlibrary/testing.html [2] http://testng.org [3] http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200606.mbox/[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] -- Andrew Zhang China Software Development Lab, IBM
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
Re: [classlib] Testing conventions - a proposal
Hello All, After read through the document recommended by Alex, I think TestNG can really meet our requirement. It provides much flexibility for test configuration. ;-) If we decide to transfer to TestNG, we shall: 1. Identify Harmony testing strategy. (It's not easy) 2. Define TestNG suite/groups to reflect Harmony testing strategy 3. Decide to use Java 5 Annotations or Java 1.4 JavaDoc annotations 4. Convert all JUnit tests to TestNG tests (TestNG provides a tool org.testng.JUnitConverter for migrating from JUnit, but it seems that the tool has a bug :-P ) 5. Choose a module to run a pilot ... Please correct me if I'm wrong. Thanks a lot. Best regards, Richard. George Harley wrote: Alex Blewitt wrote: On 06/07/06, Richard Liang [EMAIL PROTECTED] wrote: It seems that you're very familiar with TestNG. ;-) So would you please identify what we shall do to transfer from junit to TestNG? Thanks a lot. Me? I'm just highly opinionated :-) Hi Alex, I think we are all pretty much in the TestNG novice category :-) There's guidelines for migrating from JUnit to TestNG at the home page: http://testng.org/doc/migrating.html Here is a sample use that will convert all the JUnit tests in the src/ directory to TestNG: java org.testng.JUnitConverter -overwrite -annotation -srcdir src :-) I have done some private experimentation with this command line utility and it seems to work well. In the first instance it would be good to preserve the JUnit nature of the tests - i.e. still have the test classes extend from JUnit TestCase etc - so that there is always a backwards migration path. That's me being paranoid. Note that the equivalent migration functionality in the latest TestNG plug-in for Eclipse did not allow that but, in addition to adding in the annotations, insisted on removing the inheritance from TestCase. There's also instructions about how to set it up with an Ant-based build: http://testng.org/doc/ant.html I'll see if I can migrate the tests I've got in the Pack200 dir to use TestNG, so that you can see what it looks like. Unfortunately, I doubt that I'm going to be able to get to that much before 2 weeks time due to other outstanding commitments ... Alex. Although we haven't gotten round to discussing specifics yet, it is probably timely to mention here that using the TestNG annotations approach (as opposed to the pre-1.5 Javadoc comments approach) will not work so long as we are compiling Harmony code with the jsr14 target. It looked like the annotation metadata did not make it into the generated class files (at least this is what I saw in my own experiments). If we want to use the annotations approach we will have to wait until we move up to compiling for a 1.5 target. Hopefully that will not be too long now.. In the meantime you could try out using the Javadoc comments approach, just to get a feel for how things run. The downside to that is that your test source needs to be available at runtime so that the comments are available for the framework to examine. Best regards, George - 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] -- 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]
RE: [vote] acceptance of HARMONY-536 : JSEE provider contribution
+1 Dan Lydick [Original Message] From: Geir Magnusson Jr [EMAIL PROTECTED] To: harmony-dev@incubator.apache.org Date: 7/5/06 6:29:17 PM Subject: [vote] acceptance of HARMONY-536 : JSEE provider contribution 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] - 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
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. 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. 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] debug compilation as default
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 - 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
Richard Liang wrote: Hello All, After read through the document recommended by Alex, I think TestNG can really meet our requirement. It provides much flexibility for test configuration. ;-) If we decide to transfer to TestNG, we shall: 1. Identify Harmony testing strategy. (It's not easy) 2. Define TestNG suite/groups to reflect Harmony testing strategy 3. Decide to use Java 5 Annotations or Java 1.4 JavaDoc annotations Any difference between using 1.4 doclet or 5.0 annotation? If we use Java 1.4 so far, can we migrate to annotation easily? 4. Convert all JUnit tests to TestNG tests (TestNG provides a tool org.testng.JUnitConverter for migrating from JUnit, but it seems that the tool has a bug :-P ) I'm sorry, but...what the bug looks like? I think it is important because we have so many JUnit tests already, it will be a big concern of the TestNG solution if we have not tool to migrate. 5. Choose a module to run a pilot ... Please correct me if I'm wrong. Thanks a lot. Best regards, Richard. George Harley wrote: Alex Blewitt wrote: On 06/07/06, Richard Liang [EMAIL PROTECTED] wrote: It seems that you're very familiar with TestNG. ;-) So would you please identify what we shall do to transfer from junit to TestNG? Thanks a lot. Me? I'm just highly opinionated :-) Hi Alex, I think we are all pretty much in the TestNG novice category :-) There's guidelines for migrating from JUnit to TestNG at the home page: http://testng.org/doc/migrating.html Here is a sample use that will convert all the JUnit tests in the src/ directory to TestNG: java org.testng.JUnitConverter -overwrite -annotation -srcdir src :-) I have done some private experimentation with this command line utility and it seems to work well. In the first instance it would be good to preserve the JUnit nature of the tests - i.e. still have the test classes extend from JUnit TestCase etc - so that there is always a backwards migration path. That's me being paranoid. Note that the equivalent migration functionality in the latest TestNG plug-in for Eclipse did not allow that but, in addition to adding in the annotations, insisted on removing the inheritance from TestCase. There's also instructions about how to set it up with an Ant-based build: http://testng.org/doc/ant.html I'll see if I can migrate the tests I've got in the Pack200 dir to use TestNG, so that you can see what it looks like. Unfortunately, I doubt that I'm going to be able to get to that much before 2 weeks time due to other outstanding commitments ... Alex. Although we haven't gotten round to discussing specifics yet, it is probably timely to mention here that using the TestNG annotations approach (as opposed to the pre-1.5 Javadoc comments approach) will not work so long as we are compiling Harmony code with the jsr14 target. It looked like the annotation metadata did not make it into the generated class files (at least this is what I saw in my own experiments). If we want to use the annotations approach we will have to wait until we move up to compiling for a 1.5 target. Hopefully that will not be too long now.. In the meantime you could try out using the Javadoc comments approach, just to get a feel for how things run. The downside to that is that your test source needs to be available at runtime so that the comments are available for the framework to examine. Best regards, George - 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] -- 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: [classlib][nio] Modify ServerSocketChannel.implConfigureBlocking() method
Hi Jimmy In fact, after I raising Harmony-778, 779, I felt a little guilty, and didn't have a good sleep. :) I agree that original implConfigureBlocking is necessary but not sufficient. Original implConfigureBlocking uses ioctl family function to set underlying file descriptor, it's correct. But for SocketChannelImpl, it's still insufficient. All things are caused by connect_with_timeout() from portlib. As you mentioned, it always set the file descriptor as blocking file descriptor when it ends normally. To fix this problem, there are two solutions: 1. modify connect_with_timeout method. Set the file descriptor blocking mode as the same before invocation. 2. Always invoke implConfigureBlocking before read/write operations. Currently, solution 2 is easier as a temp fix. If connect_with_timeout is fixed in portlib, I'll remove these extra implConfigureBlocking codes. I'll raise a serpate JIRA to solve this problem thoroughly. Any comments and ideas? On 7/7/06, Jimmy, Jing Lv [EMAIL PROTECTED] wrote: 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
Re: [drlvm] verification of classfile format
2006/7/7, Gregory Shimansky [EMAIL PROTECTED]: On Thursday 06 July 2006 20:26 Geir Magnusson Jr wrote: As part of the work surrounding the HARMONY-677 (r419557), getting DRLVM to deal with Java5 classfile format, I noticed that DRLVM doesn't appear to give a hoot what version of the classfile it's chewing on. It just goes until something blows up. It does check the class file version in bootstrap class loader (vm/vmcore/src/class_support/Class_File_Loader.cpp) and can throw UnsupportedClassVersionError. The constant CLASSFILE_MAJOR_MAX is defined in vm/vmcore/include/Class.h. I was comparing to j9, which gives a UnsupportedClassVersionError. DRLVM should do the same of course, and it makes me worry what else it outght to be doing - if we don't understand the version of the class file, how can we read it dependably? For some reason I don't really know the constant was changed to 49 as if VM did support class files of version 1.5. Maybe it was the first step to support 1.5 classes :) I was reading down through j.l.ClassLoader and natives, and given the dearth of comments, didn't quite grok where a good place to start doing some verification would be... Maybe I missed it. Can anyone give me a hint? I think it should happen in bootstrap class loader since it is the place where class file parsing is done anyway. So the place is in VM native code, not kernel classes. Just to be accurate, this functionality (class data parsing) is common to all classloaders, not only bootstrap one (and obviously it would be a bug, if VM does not check classfiles consistency for user-defined classloaders). As long as any classloader makes a call to defineClass(), it will not pass by this check. -- Alexey Varlamov -- 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] - 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
On 7/7/06, Richard Liang [EMAIL PROTECTED] wrote: SNIP We may frequently encounter this confused situation, and I suggest we discuss the problems case by case if someone is not sure how to do. ;-) For this case, I decide to follow useRadix(int radix). Please correct me if I'm wrong. Thanks a lot. +1. -- 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]
