Re: [vote] acceptance of HARMONY-856 : assorted bug fixed for DRLVM
+1 2006/7/25, Nathan Beyer [EMAIL PROTECTED]: +1 -Original Message- From: Geir Magnusson Jr [mailto:[EMAIL PROTECTED] Sent: Sunday, July 23, 2006 1:02 PM To: harmony-dev@incubator.apache.org Subject: [vote] acceptance of HARMONY-856 : assorted bug fixed for DRLVM All is in order and in SVN for Harmony-856 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] -- Alexey A. Petrenko 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]
[classLib]Given a long value, RI behaves differently on windows and linux (and TestNG?)
Hi: I find another platform-dependent operation FileChannel.transforFrom(ReadableByteChannel src, long position, long count) in java.nio.channels. RI behaves differently if the given count is larger than Integer.MAX_VALUE: on windows, it throws an IOException; on Linux, it return zero silently. It is clear that the difference is caused by system call. Unfortunately Harmony fails to behave like RI as its has the same native code using the port-lib. If it is necessary to make Harmony behaving exactly like RI, I suggest writing native code for transforFrom. This may be a waste-of-effect as it is nearly the same except for this little difference.However, currently people have few chances to use a size larger than Integer.MAX_VALUE(nearly 4G, is it?), and system call does not support long value to pass in. Another thing I'd like to mention is that it'll be great if we can use testNG, or decide some other way to go. At least 2 testcases should be written for different platform as I remember, including the one for this problem. :) -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Stack Overflow Error support issues
Guys, I'm just curious - anybody know how probable is the chance to hit stack overflow during compilation vs managed code execution and vs native code execution? Shouldn't we care (even more) about kernel/classlib natives? I guess there are enough places lacking guard checks like if (ExceptionOccured()) return 0; BTW, the SOE machinery seems to be incomplete for this case, see HARMONY-971 issue. -- Alexey Varlamov 2006/7/25, Rana Dasgupta [EMAIL PROTECTED]: As I understand it, the value added by a broad check like this before the compile starts may not be very high. At best, it can try to avoid SOE in native code with a clean failure when it is certain that the stack state will not permit completion of the compile. So something like 1/100 of the stack as Mikhail mentions sounds reasonable, and the VM could do this. This is something like a tuning activity and some experiments may also help. It is also true that to offer real guarantees that overflow will not occur, the JIT will need to consider this bound before making optimization decisions or to limit recursion depth in algo selection. But this is a lot to do proactively in the Jit, just to try to avoid SOE. My suggestion is that we can consider doing these defensive checks in the Jit only if we want to offer and honor some published reliability guarantees. This is a broader topic and would need to include not only SOE, but several other failures like ThreadAbort etc. that the user does not usually anticipate and are not user code failures. Basically these are guarantees that if the user follows some reasonable guidelines, certain portions of his code cannot fail. How those guarantees can be exposed etc. ( eg., a method attributed with an attribute Reliable that the Jit and VM support, or some command line flags etc. ) is a matter of design. We should defer this work unless SOE becomes an issue with our apps of choice or this type of reliable managed code is a design requirement in Harmony. For now, it may be better to periodically check for the exception state on the thread in line with Pavel's original design. Thanks, Rana On 7/24/06, Mikhail Fursov [EMAIL PROTECTED] wrote: No, I think that VM can do this check but use lower border: e.g. 1/100 of initial. JIT must do this check more accurate: use knowledge of algorithms it uses. The requirement to avoid SOE during a compilation can affect any algorithm in JIT that uses recursion. Jitrino.OPT has a lot of such algorithms: node, insts, opnd based . So I'm not sure that JIT can construct a heuristic or a profile to refuse to compile a method in the beginning of the compilation. The another option is to check available stack size before any recursion based algorithm and limit the algorithm up to N steps in recursion (N is recomputed in runtime) . If N steps is not enough algorithm will fail and JIT will not not perform the optimization or compilation at all. Quite a lot of changes in JIT though. Any other ideas? On 7/24/06, Pavel Afremov [EMAIL PROTECTED] wrote: Hi On 7/22/06, Mikhail Fursov [EMAIL PROTECTED] wrote: I think this must be a JIT heuristics because even a small method can lead to inlining of whole classlib API :) Are You think this check should be removed from VM and puted into JIT only? BR Pavel Afremov. -- Mikhail Fursov - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Stack Overflow Error support issues
[SNIP] Shouldn't we care (even more) about kernel/classlib natives? I guess there are enough places lacking guard checks like if (ExceptionOccured()) return 0; BTW, the SOE machinery seems to be incomplete for this case, see HARMONY-971 issue. I think some issues could disappear if lazy exception creation is used for SOE. Besides, it would be more reliable - in case we are really tight on stack... Pavel, is it possible without massive refactoring in exceptions submodule ? [SNIP] -- Alexey - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classLib]Given a long value, RI behaves differently on windows and linux (and TestNG?)
2006/7/25, Jimmy, Jing Lv [EMAIL PROTECTED]: Hi: I find another platform-dependent operation FileChannel.transforFrom(ReadableByteChannel src, long position, long count) in java.nio.channels. RI behaves differently if the given count is larger than Integer.MAX_VALUE: on windows, it throws an IOException; on Linux, it return zero silently. It is clear that the difference is caused by system call. Unfortunately Harmony fails to behave like RI as its has the same native code using the port-lib. If it is necessary to make Harmony behaving exactly like RI, I suggest writing native code for transforFrom. This may be a waste-of-effect as it is nearly the same except for this little difference.However, currently people have few chances to use a size larger than Integer.MAX_VALUE(nearly 4G, is it?), and system call does not support long value to pass in. Another thing I'd like to mention is that it'll be great if we can use testNG, or decide some other way to go. At least 2 testcases should be written for different platform as I remember, including the one for this problem. :) -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Dear Jimmy: As spec is not clear about how to deal with the argument greater than Integer.MAX_VALUE, maybe we shall look more closely at what RI does and how the system call behaves. I think it will be a good idea to let native code or even system call itself treat with such affairs, provided that Harmony will support some 64-bit platforms one day. Thus it may be not so wise to throw some exception in java code if encountering the data longer than 32-bits. Besides, whether we should behaves the same as RI, even if it is different on different platforms? :) -- Leo Li China Software Development Lab, IBM
Re: [vote] acceptance of HARMONY-856 : assorted bug fixed for DRLVM
+1 2006/7/24, Geir Magnusson Jr [EMAIL PROTECTED]: All is in order and in SVN for Harmony-856 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: Re: Re: [classlib] TwoKeyHashMap
2006/7/25, Alex Blewitt [EMAIL PROTECTED]: On 25/07/06, Mikhail Loenko [EMAIL PROTECTED] wrote: In general before we get rid of that class or decide to keep it, I think we should work out an approach to performance optimizations. It's a rare case when perofmance might be significantly improved for free, a regular price is: additional complexity, more code, lack of readability, additional memory footprint etc. So let's discuss how we approach performance in general and that return to this specific class. Performance in general: premature optimisation is the root of all evil [Knuth] http://mindprod.com/jgloss/knuth.html In this case, we've not only dupllicated logic from a HashMap, but at the expense of a potential problem that we've not even measured. For example, there is an assumption that the cost of creating (and recycling) objects in a wrapper for an equivalent use of a Map is something that's not even been measured, yet we have code that assumes that that is a bottleneck. Is this code even on the critical path? That is, have we profiled this code to know whether any access is actually directly responsible for performance problems? If not, then it sounds like assumptions have been made prior to writing this. So, we should strive to make code: 1) Correct 2) Easy to understand and maintain 3) Performant 4) Optimised (for memory, speed) in that order. In this case, I'm not sure whether we've violated 2 in preference for 4. Not sure I agree with your priorities Thanks, Mikhail Alex. - 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: Re: Re: [classlib] TwoKeyHashMap
Sorry, sent unfinished message my version of priorities is: 1) Correct 2) Attractive to users 3) Easy to maintain Thanks, Mikhail 2006/7/25, Mikhail Loenko [EMAIL PROTECTED]: 2006/7/25, Alex Blewitt [EMAIL PROTECTED]: On 25/07/06, Mikhail Loenko [EMAIL PROTECTED] wrote: In general before we get rid of that class or decide to keep it, I think we should work out an approach to performance optimizations. It's a rare case when perofmance might be significantly improved for free, a regular price is: additional complexity, more code, lack of readability, additional memory footprint etc. So let's discuss how we approach performance in general and that return to this specific class. Performance in general: premature optimisation is the root of all evil [Knuth] http://mindprod.com/jgloss/knuth.html In this case, we've not only dupllicated logic from a HashMap, but at the expense of a potential problem that we've not even measured. For example, there is an assumption that the cost of creating (and recycling) objects in a wrapper for an equivalent use of a Map is something that's not even been measured, yet we have code that assumes that that is a bottleneck. Is this code even on the critical path? That is, have we profiled this code to know whether any access is actually directly responsible for performance problems? If not, then it sounds like assumptions have been made prior to writing this. So, we should strive to make code: 1) Correct 2) Easy to understand and maintain 3) Performant 4) Optimised (for memory, speed) in that order. In this case, I'm not sure whether we've violated 2 in preference for 4. Not sure I agree with your priorities Thanks, Mikhail Alex. - 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: r425315 - in /incubator/harmony/enhanced/classlib/trunk: depends/files/ modules/security/ modules/security/make/ modules/security/src/main/java/common/java/security/ modules/security/s
Mikhail, after your commit, I can't build Harmony: [javac] C:\new_harmony\Harmony\enhanced\classlib\trunk\modules\security\src\ main\java\common\org\apache\harmony\security\provider\crypto\SHA1PRNG_SecureRand omImpl.java:28: cannot find symbol [javac] symbol : class RandomBitsSupplier [javac] location: package org.apache.harmony.security.provider.crypto [javac] import org.apache.harmony.security.provider.crypto.RandomBitsSupplie r; [javac]^ [javac] C:\new_harmony\Harmony\enhanced\classlib\trunk\modules\security\src\ main\java\common\org\apache\harmony\security\provider\crypto\SHA1PRNG_SecureRand omImpl.java:253: cannot find symbol [javac] symbol : variable RandomBitsSupplier [javac] location: class org.apache.harmony.security.provider.crypto.SHA1PRNG _SecureRandomImpl [javac] myRandom.engineSetSeed( RandomBitsSupplier.getRandomBits( DIGEST_LENGTH)); [javac]^ [javac] C:\new_harmony\Harmony\enhanced\classlib\trunk\modules\security\src\ main\java\common\org\apache\harmony\security\provider\crypto\SHA1PRNG_SecureRand omImpl.java:297: cannot find symbol [javac] symbol : variable RandomBitsSupplier [javac] location: class org.apache.harmony.security.provider.crypto.SHA1PRNG _SecureRandomImpl [javac] updateSeed(RandomBitsSupplier.getRandomBits (DIGEST_LENGT H)); [javac]^ [javac] Note: * uses or overrides a deprecated API. [javac] Note: Recompile with -Xlint:deprecation for details. [javac] Note: Some input files use unchecked or unsafe operations. [javac] Note: Recompile with -Xlint:unchecked for details. [javac] 3 errors BUILD FAILED
RE: [testing] locale dependent tests
-Original Message- From: Richard Liang [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 25, 2006 6:26 AM To: harmony-dev@incubator.apache.org Subject: Re: [testing] locale dependent tests Ivanov, Alexey A wrote: -Original Message- From: Paulex Yang [mailto:[EMAIL PROTECTED] Sent: Thursday, July 20, 2006 10:27 AM To: harmony-dev@incubator.apache.org Subject: Re: [testing] locale dependent tests Andrew Zhang wrote: On 7/19/06, Richard Liang [EMAIL PROTECTED] wrote: Tim Ellison wrote: Richard Liang wrote: Although the spec does not require the round-trip of applyPattern and toPattern, we still want to get one *certain* pattern through toPattern. Now the problem is the returned pattern is locale-dependent. I'm uncertain about the reason to remove the assertion: 1) Because the behavior is not required by spec, or 2) Because the behavior is locale-dependent It would seem that rather than forcing the locale to be en_US to make the test assertions valid, you could work with the default locale and guard any assertions that are locale-specific. It would seem a shame to loose the diversity of testing on multiple locale machines if the tests always force everyone to look like an American (horror! ;-) ) I would expect the fix therefore to be something like, if locale is en_US go ahead and assert more round-tripping code, otherwise can't test it as the spec allows variances. If a test case passes in all locales, could we think that the behavior tested by the test case is locale-independent? We still have to think about how to test locale-dependent behavior. For example, java.util.Locale.getDisplayName() and java.lang.String.toUpperCase(). To verify both the code logic and locale data, shall we have some tests like ABC_en_US_Test, ABC_en_UK_Test, and ABC_ru_RU_Test? I still confuse what we want to test, the logic or the data? I think most (if not all) i18n related methods actually have same single executable with multiple resource bundles, i.e., the single executable should be locale-independent, the different return value is due to the resource data difference. I think at least for now, we should pay our attention to logic of single executable, and leave the data verification to the i18n libraries' author, say, ICU, they have much more knowledge and authority (at least than me) on this area. If we can get agree on the above, so the i18n related test cases organization are easier to judge: the logic is locale-independent, so ideally the tests should be locale-independent, but we have some exceptional cases, say, the en_UK in MessageFormat case, so we cannot make our tests rely on the default locale, then we just specify one locale(en_US) to the tests, and supplement some exceptional case when we find some. i.e., I don't think we need ABC_en_US_Test, or so. Comments? I don't think we need several test cases like ABC_en_US_Test and ABC_ru_RU_Test because users can modify locale data. Perhaps not all data can be changed, but some can be surely, for example, date/time formats, decimal and group separators. Thus a test which passes on one machine can fail on another one because locale data are different from the default values. I agree that we do not need the test cases like ABC_en_US_Test and ABC_ru_RU_Test. But I'm just wondering whether users could modify the locale data. Would you please give some instructions? Thanks a lot. In Windows XP, open the Control Panel, choose Date, Time, Language, and Regional Options group and then click Regional and Language Options (if in Classic View, just click this option). On the Regional Options tab click Customize button. A dialog opens. Here one can change formatting options like decimal separator symbol, digit grouping symbol, date format, time format and others. I can't give you instructions for Linux but surely there should be a way to customize these data. I know for sure that in Russia many users customize decimal separator to be point like in English locale. This is because many programs had problems dealing with something other than point in numbers. As far as I know the situation is better now. So, I think the best way to deal with such tests is to provide a fake hard-coded locale which can't be changed at all. And tests will become locale-independent. Not sure what the fake hard-coded locale is. I used to set the default locale to some particular one, e.g., en_US, but it seems that someone (Tim) does not like the idea. :-) By fake locale I mean a locale that doesn't fetch any settings from operating system. It may be en_US or another. However we should ensure the data in this locale can't be changed. If you had set en_US in the tests, we wouldn't have found bugs in DecimalFormatter, for example HARMONY-965. All tests would have passed successfully in Russian locale as well. So we need to ensure that the logic is correct. How? It's a
Re: svn commit: r425315 - in /incubator/harmony/enhanced/classlib/trunk: depends/files/ modules/security/ modules/security/make/ modules/security/src/main/java/common/java/security/ modules/security/s
try ant rebuild 2006/7/25, Igor Stolyarov [EMAIL PROTECTED]: Mikhail, after your commit, I can't build Harmony: [javac] C:\new_harmony\Harmony\enhanced\classlib\trunk\modules\security\src\ main\java\common\org\apache\harmony\security\provider\crypto\SHA1PRNG_SecureRand omImpl.java:28: cannot find symbol [javac] symbol : class RandomBitsSupplier [javac] location: package org.apache.harmony.security.provider.crypto [javac] import org.apache.harmony.security.provider.crypto.RandomBitsSupplie r; [javac]^ [javac] C:\new_harmony\Harmony\enhanced\classlib\trunk\modules\security\src\ main\java\common\org\apache\harmony\security\provider\crypto\SHA1PRNG_SecureRand omImpl.java:253: cannot find symbol [javac] symbol : variable RandomBitsSupplier [javac] location: class org.apache.harmony.security.provider.crypto.SHA1PRNG _SecureRandomImpl [javac] myRandom.engineSetSeed( RandomBitsSupplier.getRandomBits( DIGEST_LENGTH)); [javac]^ [javac] C:\new_harmony\Harmony\enhanced\classlib\trunk\modules\security\src\ main\java\common\org\apache\harmony\security\provider\crypto\SHA1PRNG_SecureRand omImpl.java:297: cannot find symbol [javac] symbol : variable RandomBitsSupplier [javac] location: class org.apache.harmony.security.provider.crypto.SHA1PRNG _SecureRandomImpl [javac] updateSeed(RandomBitsSupplier.getRandomBits (DIGEST_LENGT H)); [javac]^ [javac] Note: * uses or overrides a deprecated API. [javac] Note: Recompile with -Xlint:deprecation for details. [javac] Note: Some input files use unchecked or unsafe operations. [javac] Note: Recompile with -Xlint:unchecked for details. [javac] 3 errors BUILD FAILED - 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][util] EnumMap and EnumSet
Paulex Yang 写道: Oops...sorry for that, I had interest on them, but from then on, I've been (desperately) busy on NIO stuffs :-(((. I've updated the Wiki page and reverted the status of the two classes to Welcome Volunteer. Thank you for the reminder! Anyone else want to help? Richard Liang wrote: Hello Paulex, I'm looking at the component status of java.util [1]. And I find you have raised two JIRAs for java.util.EnumMap[2] and EnumSet[3], however, there is no follow-on actions. ;-) Are you still working on these classes? Thanks a lot. 1. http://wiki.apache.org/harmony/LUNI 2. http://issues.apache.org/jira/browse/HARMONY-595 3. http://issues.apache.org/jira/browse/HARMONY-594 Hi Paulex: Since you are so busy, I think I could implement java.util.EnumMap and EnumSet for you. Best regards -- Spark Shen China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] Cleaning insides of Class.h header
Michail,
you can get root class set to A and iterate all incarnations from there.
Regards,
Pavel.
On 7/24/06, Mikhail Fursov [EMAIL PROTECTED] wrote:
On 7/24/06, Pavel Pervov [EMAIL PROTECTED] wrote:
Michail,
If some component external to VM core has direct access to class.h, this
should be eliminated shortly. AFAIU, there are none such components.
Yes there are no such components, JIT uses 'vm.h' file to access class or
methods information.
But 'vm.h' functions use class.h functionality in their implementation.
Answering your questions:
1) It is possible to traverse class hierarchy downward using available
specialized interfaces. It is also possible to traverse class hierarchy
upward by asking direct super class of any class you have. The only
impossible thing to do is to traverse one level of class hierarchy in
both
directions. Do you really want to do the thing?
2) AFAIU, it is also available in the interface.
Do you mean this method?
// Initializes the CHA_Method_Iterator, to iterate over all methods that
// match the method signature and descend from root_class (including
root_class itself).
// Returns TRUE if iteration is supported over root_class, FALSE if not.
VMEXPORT Boolean method_iterator_initialize(ChaMethodIterator*,
Method_Handle method, Class_Handle root_class);
I'm afraid this will not work, let's check the example:
class A {
void foo(){}
}
class B extends A {
void foo(){}
}
class C extends B {
void foo(){}
}
In runtime I can have a handle of B::foo() and want to get all method
incarnations: A::foo(), B::foo(), C::foo().
What is the best way to get them all?
--
Mikhail Fursov
Re: [drlvm] Cleaning insides of Class.h header
Geir, well, it is the argument at least for me to start thinking in this direction and initiate this discussion. And there are places in VM core code where only definition of members of a class is required, but whole Class.h is included anyway. This is also about localizing potential development in separate functional groups to reduce recompilation when working intensively with these files. Hope, I answered, what you were asking about. :) Regards, Pavel. On 7/24/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Pavel Pervov wrote: On 7/24/06, Alexey Petrenko [EMAIL PROTECTED] wrote: 2006/7/24, Pavel Pervov [EMAIL PROTECTED]: First thing I would like to do is to split the file into a group of files, each of which would contain only one entity (and some closely related entities, if any). This would produce the following headers: 1) Class.h – constant pool and class 2) vtable.h – vtable 3) class_member.h – field and method entities descriptors, exception handler descriptor 4) cci.h – code chunk entity (part of compiled method code) Will these header files be useful separately? Yes, sure, they will be. This is one of the arguments for doing so. To whom? geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[classlib] porting to other platforms
Hi, I'm interested in the task of porting classlib to the 64bit platform (em64t/amd64). At this moment, classlib's source structure and build system doesn't support the diversity of platforms. Let's discuss what changes have to be made to support other platforms. One way is to move platform-dependent to the appropriate directory. For example, port--linux --ia32 --em64t --ipf makefile and to add platform determination and proper files selection to the makefile. The other way is to select the platform-dependent code by the preprocessor difine directives and to include the platform determination and the difines setting to the top-level build files (unfortunatly it doesn't work with asm files). Any thoughts? Thanks, Marina.
Re: svn commit: r425315 - in /incubator/harmony/enhanced/classlib/trunk: depends/files/ modules/security/ modules/security/make/ modules/security/src/main/java/common/java/security/ modules/security/s
I see the same error messages in Eclipse - can be fixed by adding 'src/main/java/windows' as classpathentry. So in case of Linux 'src/main/java/linux' has to be added. I think that it is a little bit inconvenient because '.classpath' file can not contain both entries (both contains a class with the same name - RandomBitsSupplier). So everybody who works with 'security' module under Eclipse has to remember about it and add mannually corresponding entry (at least at once). Thanks, Stepan. On 7/25/06, Mikhail Loenko wrote: try ant rebuild 2006/7/25, Igor Stolyarov: Mikhail, after your commit, I can't build Harmony: [javac] C:\new_harmony\Harmony\enhanced\classlib\trunk\modules\security\src\ main\java\common\org\apache\harmony\security\provider\crypto\SHA1PRNG_SecureRand omImpl.java:28: cannot find symbol [javac] symbol : class RandomBitsSupplier [javac] location: package org.apache.harmony.security.provider.crypto [javac] import org.apache.harmony.security.provider.crypto.RandomBitsSupplie r; [javac]^ [javac] C:\new_harmony\Harmony\enhanced\classlib\trunk\modules\security\src\ main\java\common\org\apache\harmony\security\provider\crypto\SHA1PRNG_SecureRand omImpl.java:253: cannot find symbol [javac] symbol : variable RandomBitsSupplier [javac] location: class org.apache.harmony.security.provider.crypto.SHA1PRNG _SecureRandomImpl [javac] myRandom.engineSetSeed( RandomBitsSupplier.getRandomBits( DIGEST_LENGTH)); [javac]^ [javac] C:\new_harmony\Harmony\enhanced\classlib\trunk\modules\security\src\ main\java\common\org\apache\harmony\security\provider\crypto\SHA1PRNG_SecureRand omImpl.java:297: cannot find symbol [javac] symbol : variable RandomBitsSupplier [javac] location: class org.apache.harmony.security.provider.crypto.SHA1PRNG _SecureRandomImpl [javac] updateSeed(RandomBitsSupplier.getRandomBits (DIGEST_LENGT H)); [javac]^ [javac] Note: * uses or overrides a deprecated API. [javac] Note: Recompile with -Xlint:deprecation for details. [javac] Note: Some input files use unchecked or unsafe operations. [javac] Note: Recompile with -Xlint:unchecked for details. [javac] 3 errors BUILD FAILED -- Thanks, Stepan Mishura Intel Middleware Products Division -- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] Cleaning insides of Class.h header
Pavel, but the common root class in Java is java.lang.Object, so you propose me to use this class as root every time I want to browse a method hierarchy? On 7/25/06, Pavel Pervov [EMAIL PROTECTED] wrote: Michail, you can get root class set to A and iterate all incarnations from there. Regards, Pavel. -- Mikhail Fursov
Re: [classlib] porting to other platforms
At first, all assembler files should be propagated to the 64bit platforms. e.g.: classlib/modules/luni/src/main/native/thread/linux/thrspinlock.s classlib/modules/luni/src/main/native/thread/linux/thrhelp.s or classlib/modules/luni/src/main/native/thread/windows/thrspinlock.asm classlib/modules/luni/src/main/native/thread/windows/thrhelp.asm Thanks, Dmitry. 2006/7/25, Marina Goldburt [EMAIL PROTECTED]: Hi, I'm interested in the task of porting classlib to the 64bit platform (em64t/amd64). At this moment, classlib's source structure and build system doesn't support the diversity of platforms. Let's discuss what changes have to be made to support other platforms. One way is to move platform-dependent to the appropriate directory. For example, port--linux --ia32 --em64t --ipf makefile and to add platform determination and proper files selection to the makefile. The other way is to select the platform-dependent code by the preprocessor difine directives and to include the platform determination and the difines setting to the top-level build files (unfortunatly it doesn't work with asm files). Any thoughts? Thanks, Marina. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][util] EnumMap and EnumSet
Spark Shen wrote: Paulex Yang 写道: Oops...sorry for that, I had interest on them, but from then on, I've been (desperately) busy on NIO stuffs :-(((. I've updated the Wiki page and reverted the status of the two classes to Welcome Volunteer. Thank you for the reminder! Anyone else want to help? Richard Liang wrote: Hello Paulex, I'm looking at the component status of java.util [1]. And I find you have raised two JIRAs for java.util.EnumMap[2] and EnumSet[3], however, there is no follow-on actions. ;-) Are you still working on these classes? Thanks a lot. 1. http://wiki.apache.org/harmony/LUNI 2. http://issues.apache.org/jira/browse/HARMONY-595 3. http://issues.apache.org/jira/browse/HARMONY-594 Hi Paulex: Since you are so busy, I think I could implement java.util.EnumMap and EnumSet for you. Great! thanks a lot, Spark. Before you start, please confirm you have understood the contribution policy and filled the ACQ[1]. And if no one objects or have related work in progress, would you please update the status Wiki to in progress? BTW, don't implement them for me but for Harmony, otherwise I will think I owe you beer;-). [1] http://incubator.apache.org/harmony/contribution_policy.html [2] http://wiki.apache.org/harmony/LUNI 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]
[optimization] Algorithmic tricks
Hello, I'd like to suggest people that know some algorithmic tricks to look at the corresponding areas of classlib. Maybe some of the community members had (un)lucky experience of tuning performance of some application that led them to a deep knowledge of some very specific area has good approaches but not too widely known to an average developer. It might also be an interest for students and other people from institutes and universities. What I'm talking about is not related to 'premature optimization' that is now being discussed in another thread but something very narrow, limited to maybe one method and not influencing anything else. For example, consider current implementation of java.util.BitSet.cardinality() . It just checks all bits one by one and increments count. [1] Gives an overview of algorithms for checking set bit count. The fastest algorithms are with table lookup, which requires additional memory, but there are algorithms that are several times faster than iteration (in C) and don't require tables. I believe such local optimizations with good comments and links to corresponding resources won't do any harm and are a good point to start with. Does it make sence? [1] http://www-db.stanford.edu/~manku/bitcount/bitcount.html -- 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] debug compilation as default
Salikh Zakirov skrev den 17-07-2006 17:14: But then, I am unix type, and having correctly defined environment is essential to me. I just keep my .profile file up-to-date, and don't care about setting it in a new window. It gets configured automatically. And I hate property files, because they cannot be configured in one central place, and I have to keep copying them over and over, and quickly get lost in a multitude of unsynchronized copies. This applies for you, but you cannot check environment variables into a versioning control system, and therefore ensure that the basic environment is the same for all users. I have now tried for quite some time to get in the water with the builds and find environment variables extremely annoying since i have to keep copying them around from machine to machine and get lost in a multitude of unsynchronized copies. property files are configured in one central place :) -- Thorbjørn - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib]bug-to-bug compatibility j.u.Formatter
Hello All,
As we have further discussion about our Compatibility issues, I'd like
to summarize this particular problems and ask for comments. Thanks a lot.
If we pass a null to j.u.Formatter.Formatter(Appendable a), when we try
to get the destination of the formatter's output by calling
formatter.out(), RI will thrown a java.util.FormatterClosedException.
But according to the specification, the destination should be a
StringBuilder.
Shall we follow RI or specification?
(My opinion is: Following spec, and record a Non-bug differences from
RI in JIRA)
The following test passes on Harmony, but fails on RI.
public void test_ConstructorLjava_lang_Appendable() {
Formatter formatter = new Formatter((Appendable) null);
Appendable out = formatter.out();
assertTrue(out instanceof StringBuilder);
}
Richard Liang wrote:
Hello All,
Here we think it's a bug of RI. I have addressed this issue in the
comments of these test cases. You may want to refer to the spec of
java.util.Formatter. Do you think I shall raise a Non-bug
differences from RI in JIRA? Thanks a lot.
quote
public Formatter(Appendable a)
Constructs a new formatter with the specified destination.
The locale used is the default locale for this instance of the Java
virtual machine.
Parameters:
*a - Destination for the formatted output. If a is null then a
StringBuilder will be created.*
/quote
Tim Ellison wrote:
Richard is probably best placed to answer that question (so I've changed
the subject to attract his attention ;-) )
Regards,
Tim
Nathan Beyer wrote:
Here are the particular failures that I'm seeing. Some seem like minor
things like exception discrepancies, but others like this unexpected
exception java.util.IllegalFormatFlagsException: Flags = '+' seem
like
flaws.
BTW: if you search for test_, it will land on the failed test
methods.
TESTROOT
tests.api.java.util.FormatterTest
test_ConstructorLjava_lang_Appendable(tests.api.java.util.FormatterTest)
java.util.FormatterClosedException
at java.util.Formatter.ensureOpen(Formatter.java:2315)
at java.util.Formatter.out(Formatter.java:2226)
at
tests.api.java.util.FormatterTest.test_ConstructorLjava_lang_Appendable(Form
atterTest.java:183)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39
)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl
.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at junit.framework.TestCase.runTest(TestCase.java:154)
at junit.framework.TestCase.runBare(TestCase.java:127)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:118)
at junit.framework.TestSuite.runTest(TestSuite.java:208)
at junit.framework.TestSuite.run(TestSuite.java:203)
at
org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3T
estReference.java:128)
at
org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:3
8)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRu
nner.java:460)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRu
nner.java:673)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.
java:386)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner
.java:196)
test_ConstructorLjava_io_FileLjava_lang_String(tests.api.java.util.Formatter
Test)
junit.framework.AssertionFailedError
at junit.framework.Assert.fail(Assert.java:47)
at junit.framework.Assert.assertTrue(Assert.java:20)
at junit.framework.Assert.assertTrue(Assert.java:27)
at
tests.api.java.util.FormatterTest.test_ConstructorLjava_io_FileLjava_lang_St
ring(FormatterTest.java:465)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39
)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl
.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at junit.framework.TestCase.runTest(TestCase.java:154)
at junit.framework.TestCase.runBare(TestCase.java:127)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:118)
at junit.framework.TestSuite.runTest(TestSuite.java:208)
at junit.framework.TestSuite.run(TestSuite.java:203)
at
org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3T
estReference.java:128)
at
Re: [classlib] porting to other platforms
Marina Goldburt wrote: Hi, I'm interested in the task of porting classlib to the 64bit platform (em64t/amd64). Thanks you! Welcome! At this moment, classlib's source structure and build system doesn't support the diversity of platforms. hmm... Do you mean VM or classlib? I'm not familiar with current VM(DRL, JCHEVM, BootJVM...)'s structure, but for classlib, IIRC we have discussed these issue before, and seems the agreement is to layout them into directories, For example, the LUNI module has platform dependent natives, while Security has platform dependent java codes, they are layout as this: src -- main -- java(native) -- share -- linux -- windows Let's discuss what changes have to be made to support other platforms. One way is to move platform-dependent to the appropriate directory. For example, port--linux --ia32 --em64t --ipf makefile and to add platform determination and proper files selection to the makefile. The other way is to select the platform-dependent code by the preprocessor difine directives and to include the platform determination and the difines setting to the top-level build files (unfortunatly it doesn't work with asm files). Any thoughts? Thanks, Marina. -- Paulex Yang China Software Development Lab IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [optimization] Algorithmic tricks
On 7/25/06, Anton Luht [EMAIL PROTECTED] wrote: For example, consider current implementation of java.util.BitSet.cardinality() . It just checks all bits one by one and increments count. [1] Gives an overview of algorithms for checking set bit count. The fastest algorithms are with table lookup, which requires additional memory, but there are algorithms that are several times faster than iteration (in C) and don't require tables. I believe such local optimizations with good comments and links to corresponding resources won't do any harm and are a good point to start with. Does it make sence? [1] http://www-db.stanford.edu/~manku/bitcount/bitcount.html Yes, BitSet code looks not optimized but at least it's readable :) I always use wikipedia to read about classic algorithms implementation. E.g. here is bit counting algorithm too, but it with a reference to the book where it was published: http://en.wikipedia.org/wiki/Bit_array So when improving algorithm and making it not readable and 'tricky' I propose to add a reference to the original source. -- Mikhail Fursov
Re: [classlib] porting to other platforms
On 7/25/06, Paulex Yang [EMAIL PROTECTED] wrote:mm... Do you mean VM or classlib? I'm not familiar with current VM(DRL, JCHEVM, BootJVM...)'s structure, but for classlib, IIRC we have discussed these issue before, and seems the agreement is to layout them into directories, For example, the LUNI module has platform dependent natives, while Security has platform dependent java codes, they are layout as this: src -- main -- java(native) -- share -- linux -- windows The question is what to do if the code depends not only on an operating system but on a machine architecture too. (em64t,ipf ...) And it is only about the classlib. The DRLVM has possibilities to add architecture dependent code. (I don't know about other vms - I'm not familiar with them too) Marina
Re: [classlib] porting to other platforms
Hi Hi, I'm interested in the task of porting classlib to the 64bit platform (em64t/amd64). At this moment, classlib's source structure and build system doesn't support the diversity of platforms. Let's discuss what changes have to be made to support other platforms. One way is to move platform-dependent to the appropriate directory. For example, port--linux --ia32 --em64t --ipf makefile and to add platform determination and proper files selection to the makefile. I always do this way when it comes to write multi platform code because I like to keep everything clean and organized. The other way is to select the platform-dependent code by the preprocessor difine directives and to include the platform determination and the difines setting to the top-level build files (unfortunatly it doesn't work with asm files). That taints the code but it's the most used way, and of course, assembly code should reside in separate files. Multi-platform code forces you to deal with the triplet: CPU, OS, Compiler Enrico - 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]bug-to-bug compatibility j.u.Formatter
Richard Liang 写道:
Hello All,
As we have further discussion about our Compatibility issues, I'd like
to summarize this particular problems and ask for comments. Thanks a lot.
If we pass a null to j.u.Formatter.Formatter(Appendable a), when we
try to get the destination of the formatter's output by calling
formatter.out(), RI will thrown a java.util.FormatterClosedException.
But according to the specification, the destination should be a
StringBuilder.
Shall we follow RI or specification?
(My opinion is: Following spec, and record a Non-bug differences from
RI in JIRA)
The following test passes on Harmony, but fails on RI.
public void test_ConstructorLjava_lang_Appendable() {
Formatter formatter = new Formatter((Appendable) null);
Appendable out = formatter.out();
assertTrue(out instanceof StringBuilder);
}
Richard, I am fully agree with you. :-)
And there are places RI behaves irrational and not compatible with RI.
See the test cases below:
public void
test_formatLjava_lang_String$Ljava_lang_Object_BigDecimalConversionF() {
f = new Formatter(Locale.US);
f.format(%f, new BigDecimal(5.0E9));
// error on RI
// RI throw ArrayIndexOutOfBoundsException
assertEquals(50.00, f.toString());
}
And others [1]
**These assertion failures can neither be categoried to test case bug
nor harmony implementation imcompatible.
IMHO, fully compatible with RI on these occasions may not be
appropriate. Record them in JIRA may be a good idea.
[1]refer to thread '[classlib] Exception throwing compatibility:
java.util.Scanner'
BTW, this one below is not caused by java.util.Formatter itself:
tests.api.java.util.FormatterTest.test_ConstructorLjava_io_FileLjava_lang_St
ring(FormatterTest.java:465)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
The failed assertion is on tests.api.java.util.FormatterTest Line 474 :
**assertTrue(notExist.delete());*
*Best regards*
*
Richard Liang wrote:
Hello All,
Here we think it's a bug of RI. I have addressed this issue in the
comments of these test cases. You may want to refer to the spec of
java.util.Formatter. Do you think I shall raise a Non-bug
differences from RI in JIRA? Thanks a lot.
quote
public Formatter(Appendable a)
Constructs a new formatter with the specified destination.
The locale used is the default locale for this instance of the Java
virtual machine.
Parameters:
*a - Destination for the formatted output. If a is null then a
StringBuilder will be created.*
/quote
Tim Ellison wrote:
Richard is probably best placed to answer that question (so I've
changed
the subject to attract his attention ;-) )
Regards,
Tim
Nathan Beyer wrote:
Here are the particular failures that I'm seeing. Some seem like minor
things like exception discrepancies, but others like this unexpected
exception java.util.IllegalFormatFlagsException: Flags = '+' seem
like
flaws.
BTW: if you search for test_, it will land on the failed test
methods.
TESTROOT
tests.api.java.util.FormatterTest
test_ConstructorLjava_lang_Appendable(tests.api.java.util.FormatterTest)
java.util.FormatterClosedException
at java.util.Formatter.ensureOpen(Formatter.java:2315)
at java.util.Formatter.out(Formatter.java:2226)
at
tests.api.java.util.FormatterTest.test_ConstructorLjava_lang_Appendable(Form
atterTest.java:183)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39
)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl
.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at junit.framework.TestCase.runTest(TestCase.java:154)
at junit.framework.TestCase.runBare(TestCase.java:127)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:118)
at junit.framework.TestSuite.runTest(TestSuite.java:208)
at junit.framework.TestSuite.run(TestSuite.java:203)
at
org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3T
estReference.java:128)
at
org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:3
8)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRu
nner.java:460)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRu
nner.java:673)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.
java:386)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner
.java:196)
test_ConstructorLjava_io_FileLjava_lang_String(tests.api.java.util.Formatter
Test)
junit.framework.AssertionFailedError
at junit.framework.Assert.fail(Assert.java:47)
at junit.framework.Assert.assertTrue(Assert.java:20)
at junit.framework.Assert.assertTrue(Assert.java:27)
at
Re: [classlib] choose one [x-net] || [security] for HARMONY-536 (JSSE provider)
Hi Stepan, The overall idea is to isolate providers' code from 'regular code' and make Well, I completely support the idea of isolating extra stuff from the regular code. The only question is in what way should we do this. Please explain why. Now we have 'javac' and 'keytool' in 'tools' module and I hope will have more tools there. I just propose to do the same for providers, for example IMHO with tools we have at least one common thing for all tools - this is a command-line interface. But with providers the common stuff is just the fact that they are providers - i.e. applications that comply to some Service Provider Interface (specific to every provider). Probably we can think about something like having one module per SPI (jndiproviders, securityproviders, etc.)? Regards, 2006/7/25, Stepan Mishura [EMAIL PROTECTED]: Hi Alexei, The overall idea is to isolate providers' code from 'regular code' and make it possible to build different 'harmony providers' distributions. On 7/24/06, Alexei Zakharov wrote: Hi Stepan, FYI there are other modules that contain providers, jndi for example. The JNDI DNS provider is currently located there. If someone will decide to implement some other JNDI provider we will need to decide where should we put it. IMHO it is not a very good idea to keep different types of providers (jndi and security here) at one place. Please explain why. Now we have 'javac' and 'keytool' in 'tools' module and I hope will have more tools there. I just propose to do the same for providers, for example modules/ providers/ src/main/java/org/apache/harmony/ archive/provider/ pack200 jndi/provider/ dns security/provider/ cert/ crypto/ Thanks, Stepan. Regards, 2006/7/24, Stepan Mishura : IMO, it is not a big issue. We may create one module for all providers (like 'tools' module) and building 'providers' module will produce a set of required jars. Thanks, Stepan. On 7/24/06, Mikhail Loenko wrote: If we create separate module for each provider then number of modules is going to be too big... (e.g. RI has 6 or 7 providers) Thanks, Mikhail 2006/7/24, Stepan Mishura : On 7/19/06, Mikhail Loenko wrote: A long ago we agreed that providers go into a separate module. But now I think it's might be not very reasonable. Hi Mikhail, Why you think that is not reasonable? Here is the initial proposal: http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200601.mbox/[EMAIL PROTECTED] Thanks, Stepan. Sun keeps certificates in its own proprietary format (JKS), while we have BKS from Bouncy Castle, so files will have to be converted. I can do this next week Thanks, Mikhail 2006/7/19, Geir Magnusson Jr [EMAIL PROTECTED]: Tim Ellison wrote: Geir Magnusson Jr wrote: I'm integrating HARMONY-536, the JSSE provider. Two things: 1) it's contributed to go into x-net, but the package namespace is o.a.h.security.provider.jsse so I wonder if this would be better off in the security module. If not, we are stuck because we don't have a 'negative' patternset for jar packaging, so it's getting sucked into security jar right now anyway :) IMHO it should be in x-net. Can't you rename the package? Of course. Something was going to get moved, just wanted to see any other opinions.. 2) I have a little test proggie that shows that it's negotiating w/ the other side, but given we have no cacerts, it whines and gives up. (It's a reasonable whine...) Lazily and naively, I threw the cacerts from Sun's JRE into jre/lib/security and prayed, but the security deities are not smiling on me today. So, where does/what format/etc/etc should our root cert file go? Dunno. I know you were just playing, but AIUI the use of root certificates for popular CA's cost $'s don't they? I didn't think so. I thought that they gave the root certs away because the value of a cert provider is directly proportional to the amount of software out there that can understand it's certs... Hopefully Boris will enlighten us to the format used. Regards, Tim -- Thanks, Stepan Mishura Intel Middleware Products Division -- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Alexei Zakharov, Intel Middleware Product Division
Re: [classlib]bug-to-bug compatibility j.u.Formatter
Hello, And there are places RI behaves irrational and not compatible with RI. You mean RI behaves not compatible with spec? :) -- 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: svn commit: r425020 - in /incubator/harmony/enhanced/classlib/trunk: make/ modules/security/ modules/security/make/ modules/security/src/main/java/common/org/apache/harmony/security/provider/crypt
Good catch! I've managed to reproduce the problem I'll fix it shortly Thanks, Mikhail - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] porting to other platforms
Dmitry, As noticed in the letter http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200606.mbox/[EMAIL PROTECTED] hythreads module is not used by the DRLVM (the VM used in Harmony official JRE and HDK snapshots) and by j9 vm too. I don't know about JCHEVM and BootJVM (if somebody knows, please, tell are they use the hythreads library or not?). So, I think, the first step might be to port the parts of classlib required to get working em64t/ipf JRE snapshot. Marina. On 7/25/06, Dmitry Yershov [EMAIL PROTECTED] wrote: At first, all assembler files should be propagated to the 64bit platforms. e.g.: classlib/modules/luni/src/main/native/thread/linux/thrspinlock.s classlib/modules/luni/src/main/native/thread/linux/thrhelp.s or classlib/modules/luni/src/main/native/thread/windows/thrspinlock.asm classlib/modules/luni/src/main/native/thread/windows/thrhelp.asm Thanks, Dmitry. 2006/7/25, Marina Goldburt [EMAIL PROTECTED]: Hi, I'm interested in the task of porting classlib to the 64bit platform (em64t/amd64). At this moment, classlib's source structure and build system doesn't support the diversity of platforms. Let's discuss what changes have to be made to support other platforms. One way is to move platform-dependent to the appropriate directory. For example, port--linux --ia32 --em64t --ipf makefile and to add platform determination and proper files selection to the makefile. The other way is to select the platform-dependent code by the preprocessor difine directives and to include the platform determination and the difines setting to the top-level build files (unfortunatly it doesn't work with asm files). Any thoughts? Thanks, Marina. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] porting to other platforms
Marina Goldburt wrote: On 7/25/06, Paulex Yang [EMAIL PROTECTED] wrote:mm... Do you mean VM or classlib? I'm not familiar with current VM(DRL, JCHEVM, BootJVM...)'s structure, but for classlib, IIRC we have discussed these issue before, and seems the agreement is to layout them into directories, For example, the LUNI module has platform dependent natives, while Security has platform dependent java codes, they are layout as this: src -- main -- java(native) -- share -- linux -- windows The question is what to do if the code depends not only on an operating system but on a machine architecture too. (em64t,ipf ...) I see, personally Im fine to add architecture as operation systems' subdirectory if necessary. And it is only about the classlib. The DRLVM has possibilities to add architecture dependent code. (I don't know about other vms - I'm not familiar with them too) Marina -- Paulex Yang China Software Development Lab IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classLib]Given a long value, RI behaves differently on windows and linux (and TestNG?)
Hi, Is there any known real applications that use NIO for reading stuff with 4GB blocks? Regards, 2006/7/25, Leo Li [EMAIL PROTECTED]: 2006/7/25, Jimmy, Jing Lv [EMAIL PROTECTED]: Hi: I find another platform-dependent operation FileChannel.transforFrom(ReadableByteChannel src, long position, long count) in java.nio.channels. RI behaves differently if the given count is larger than Integer.MAX_VALUE: on windows, it throws an IOException; on Linux, it return zero silently. It is clear that the difference is caused by system call. Unfortunately Harmony fails to behave like RI as its has the same native code using the port-lib. If it is necessary to make Harmony behaving exactly like RI, I suggest writing native code for transforFrom. This may be a waste-of-effect as it is nearly the same except for this little difference.However, currently people have few chances to use a size larger than Integer.MAX_VALUE(nearly 4G, is it?), and system call does not support long value to pass in. Another thing I'd like to mention is that it'll be great if we can use testNG, or decide some other way to go. At least 2 testcases should be written for different platform as I remember, including the one for this problem. :) -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Dear Jimmy: As spec is not clear about how to deal with the argument greater than Integer.MAX_VALUE, maybe we shall look more closely at what RI does and how the system call behaves. I think it will be a good idea to let native code or even system call itself treat with such affairs, provided that Harmony will support some 64-bit platforms one day. Thus it may be not so wise to throw some exception in java code if encountering the data longer than 32-bits. Besides, whether we should behaves the same as RI, even if it is different on different platforms? :) -- Leo Li China Software Development Lab, IBM -- Alexei Zakharov, Intel Middleware Product 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: [build-test-infra] Build Test Infrastructure
-Original Message-
From: Anton Luht [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 25, 2006 5:32 AM
To: harmony-dev@incubator.apache.org
Subject: Re: [build-test-infra] Build Test Infrastructure
Geir,
I've managed to get CC running on Windows. I had no problems with
checkout of classlib - maybe you've stepped on the long paths problem
- I've made a testing build directory close to root.
The start.win target didn't work for me - I've changed it
according to Ant FAQ.
target name=start-win if=is.windows
exec executable=cmd dir=${target.dir}
- arg line=cruisecontrol.bat/
+ arg line=/c cruisecontrol.bat/
/exec
/target
Perfect. I hadn't tried it on Windows. Because my windows laptop (a
T43 w/ a 7200 RPM drive and 2G memory) is perceptably slower for same
activities (checkout, build, etc) than my linux laptop (a T42 w/ 5300
RPM drive and 1G memory) I tend to gravitate to do things on linux...
Cleanup of 'connectfour' directories in the build look
strange to me :)
You mean that we're doing it, or how it's done? I thought it needed to
be done as it's a standard CC distro that's automatically fetched and
setup, and it's nice to have the unrelated drek removed.
Geir
On 7/11/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote:
Thanks for all the comments - I know this will be an
exciting part of
our project ;)
(There were no comments...)
Anyway, I checked in into enhanced/buildtest. In trunk,
you should be
able to :
ant setup
and have the almost the thing install and
ant
just kicks it off and runs it.
I say almost because
1) you need to manually get the IBM J9 VM and install it into
cc/projects/classlib/trunk after you manually run 'ant'
once to setup
the deploy/ directory. In fact, I think we should put the
deploy/jdk/jre skeleton in place in SVN for this to make it easier.
2) there's a problem on windows - the full setup fails during the
checkout of classlib, even though the 'subtarget' to do the checkout
works just fine. I suspect there's some memory problem or
such, but I
got tired of staring at it.
This really is a 'proof of concept' sketch for comment.
Immediately,
I'd like to set CC sending mail to our lists, and then
figure out some
way of aggregating the information into a webpage or wiki
page. Maybe
wiki is going to be easier to start..
--
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]
-
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-856 : assorted bug fixed for DRLVM
+1 Pavel Afremov On 7/23/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: All is in order and in SVN for Harmony-856 wrt BCC and ACQ. Please vote to accept or reject this codebase into the Apache Harmony class library : [ ] + 1 Accept [ ] -1 Reject (provide reason below) Lets let this run a minimum of 3 days unless a) someone states they need more time or b) we get all committer votes before then. geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] Testing conventions - a proposal
On 7/20/06, George Harley wrote: SNIP! Anyway, the point I guess that I am trying to make here is that it is possible in TestNG to select the methods to test dynamically using a little bit of scripting that (a) gives us a lot more power than the include/exclude technique and (b) will work the same across every platform we test on. Because BeanShell allows us to instantiate and use Java objects of any type on the classpath then the possibility of using more than just group membership to decide on tests to run becomes available to us. Please refer to the TestNG documentation for more on the capabilities of BeanShell and the TestNG API. I had never heard of it before never mind used it but still managed to get stuff working in a relatively short space of time. I hope this helps. Maybe I need to write a page on the wiki or something ? Hi George, It would be great to have your proposal for using TestNG on web-site like we have for Testing conventions [1]. Thanks, Stepan. [1] http://incubator.apache.org/harmony/subcomponents/classlibrary/testing.html Best regards, George Best regards, George Thanks for reading this far. Best regards, George George Harley wrote: Hi, Just seen Tim's note on test support classes and it really caught my attention as I have been mulling over this issue for a little while now. I think that it is a good time for us to return to the topic of class library test layouts. The current proposal [1] sets out to segment our different types of test by placing them in different file locations. 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... 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] -- Thanks, Stepan Mishura Intel Middleware Products Division -- Terms of use :
Re: [DRLVM/MMTk] v0.1 porting layer has been committed
Weldon, I've updated the magics.cpp with fromLong/toLong fixed. But I suspect other issues as well, and I'm working on it, so please expect more commits of magics.cpp to come. -- Thanks, Alex Alex Astapchuk wrote: Weldon, I also recently discovered what could be problem with jitrino.JET compiling OPCODE_LCMP. Jitrino.JET is core dumping. This problem I'm looking into the issue. Could you please share the class/method that causes assertion ? - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [optimization] Algorithmic tricks
Anton, it looks like a joke but while investigating potential performance problems of our classlib with DeCapo benchmark I found that the same method (counting signed bits in bitset) is the hottest method in antlr benchmark. But this method is not from classlib, but from the benchmark and its implementation is very close to ours and not optimized. I wonder if our JIT will be able to automatically detect such algorithms and replace them with more optimized version someday... On 7/25/06, Mikhail Fursov [EMAIL PROTECTED] wrote: On 7/25/06, Anton Luht [EMAIL PROTECTED] wrote: For example, consider current implementation of java.util.BitSet.cardinality() . It just checks all bits one by one and increments count. [1] Gives an overview of algorithms for checking set bit count. The fastest algorithms are with table lookup, which requires additional memory, but there are algorithms that are several times faster than iteration (in C) and don't require tables. I believe such local optimizations with good comments and links to corresponding resources won't do any harm and are a good point to start with. Does it make sence? [1] http://www-db.stanford.edu/~manku/bitcount/bitcount.html http://www-db.stanford.edu/%7Emanku/bitcount/bitcount.html Yes, BitSet code looks not optimized but at least it's readable :) I always use wikipedia to read about classic algorithms implementation. E.g. here is bit counting algorithm too, but it with a reference to the book where it was published: http://en.wikipedia.org/wiki/Bit_array So when improving algorithm and making it not readable and 'tricky' I propose to add a reference to the original source. -- Mikhail Fursov -- Mikhail Fursov
Re: svn commit: r425020 - in /incubator/harmony/enhanced/classlib/trunk: make/ modules/security/ modules/security/make/ modules/security/src/main/java/common/org/apache/harmony/security/provider/crypt
Classlib is building successfully on my machine again now. Regards, Oliver Mikhail Loenko wrote: Good catch! I've managed to reproduce the problem I'll fix it shortly Thanks, Mikhail - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Oliver Deakin IBM United Kingdom Limited - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] Using Yoko as CORBA for Harmony
2006/7/22, Geir Magnusson Jr [EMAIL PROTECTED]: Alexey Petrenko wrote: There are not much news to share... First of all I realized that I did not completely build Yoko. My build was failed with the test failure. I thought that all the tests are at the end so all the sources are built. But Yoko runs the tests after building each module... I reviewed Yoko bug database and found the issue corresponding to my failure, applied fix to my repository and definitely finished the build after that :) Ok. I've tried to run Maven on Harmony classlib+drlvm but have failed with it. Ant lets to define Java executable to run on by environment variable but I could not find such option for Maven. I've renamed ij.exe into java.exe and set JAVA_HOME to drlvm location. Maven started with Harmony after that but failed with Java version check. Drlvm shows version like 11.smth.smth. Probably we should fix this in drlvm. Or at least discuss this. Both are fixed in current version, or should be if it's just using the first line reported by -versin Investigation shown that Maven checks for java.class.version property value. I also found a shell script inside Yoko which can run Yoko tests without Maven. But I had not time to try it yet... Ok - I don't understand quite what you are trying to do. The goal is to integrate yoko to satisfy the corba requirements for java 5. it sounds like you are trying to run Yoko using Harmony. This is something that will happen, but w/o any integration into classlib, right now no one can look at this with you. Can you come up with a first-pass, simple, just-get-it-in-there integration into the classlibrary? geir SY, Alexey 2006/7/21, Geir Magnusson Jr [EMAIL PROTECTED]: So how goes the YOKO battle? Alexey Petrenko wrote: Guys, There is a CORBA implementation in Apache incubator named Yoko. http://incubator.apache.org/yoko/ I've built and reviewed it... It seems that Yoko have almost all the packages from the 1.5 specification. So it looks like a good candidate for using as CORBA for Harmony. The only problem is that Yoko has even more packages in org.omg then specified by 1.5 specification. So we should decide what to do with them. I'm planing to do the following things in nearest future: 1. Get the list of the not implemented classes in Yoko according to 1.5 spec. 2. Check that we have all the classes needed by Yoko in Harmony. Thoughts? Comments? SY, Alexey - 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] -- Alexey A. Petrenko 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: [vote] acceptance of HARMONY-856 : assorted bug fixed for DRLVM
+1 On 23/07/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: All is in order and in SVN for Harmony-856 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] -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
Re: portlib functionality
(Thanks for bringing this onto the list Paulex) On 25/07/06, Marina Goldburt [EMAIL PROTECTED] wrote: Yes, this is the straightforward mechanism. The only objection is that adding all the missed functions to the HyPortLibrary structure leads to its significant growing. We should discuss what functions you see as candidates for extension to the portlibrary. The second was that this mechanism needs vm recompilation. If you honour the existing table layout then you don't need to break compatibility. In addition, VMs are not required to use the class library portlib if they choose not to. But it's ok since Harmony has its own vm and nobody uses j9 vm binaries. This is a joke right? There are three VMs in various states of development at Harmony, and people are also using the IBM VME. Regards, Tim On 7/25/06, Paulex Yang [EMAIL PROTECTED] wrote: Marina, Actually... I didn't catch up here about how the portlib can be extended, if you mean what API should look like about the mmap portable version, yes, I meant this; or if you mean the portlib's mechanism to extension, I thought it is straightforward, so please correct me if I make mistakes or miss sth., I thought it needs three steps: 1. Modify hyport.h to add the function prototyp, add the new function prototypes to function table(Struct HyPortLibrary), add a macro to access the new item(like #define hystr_printf privatePortLibrary-str_printf) 2. add the function declaration in portpriv.h, and add the reference to function table instance(MasterPortLibraryTable) 3. implement the function for every platform, and modify makefile if necessary BTW, would you mind if I forward this to the mailing list? I think probably more people will have interest on this topic:). Marina Goldburt wrote: Paulex, As I understand, the proposal'll be about how the portlib can be extended? While you're preparing the proposal, I'll look through the classlib code and try to prepare the list of the possible portlib extensions. Thanks, Marina. On 7/25/06, *Paulex Yang* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Marina, I've completed the implementation of mmap, and they are good candidates to be refactored as extension of portlib. I'm a little guilty that it appears in slow paces...I'll post a proposal about this soon. And I believe there are other candidates in NIO and other modules(FileLock, ICMP ECHO REQUEST, etc), your (and anyone others') ideas and suggestions are welcome:). Marina Goldburt wrote: Hi, Paulex, On 7/7/06, *Paulex Yang* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: 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. What is the current state of your development? As I see, you didn't extend portlib functionality yet. How are you going to do it? As everybody agrees that moving all platform-dependent code of the luni module to the portlib is the correct idea, let's discuss the way the portlib can be extended. Marina. -- Paulex Yang China Software Development Lab IBM -- Paulex Yang China Software Development Lab IBM -- 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: Stack Overflow Error support issues
On 7/25/06, Pavel Afremov [EMAIL PROTECTED] wrote: Hello I can't reproduce assertion described in HARMONY-971, but it possible indeed. Alexey is right, lazy exception support for VM code fixes this and other similar bugs. I think I understand the above. Lazy exceptions only actually create the exception object if an exception handler can be located that actually consumes this object. If an exception handler is located and it does not use this object, the optimization is to never create the exception object. The net result is that an exception can indeed be properly thown when there is zero memory to allocate any new object. This, in turn, improves DRLVM's overall stability and ability to deal with Stack Overflow Exceptions correctly. In other words, it reduces the symptoms which is good. But it does not completely solve SOE problems. The question I think is important to find out is if the above is good enough for 2006 goals. The other possible solution is check available stack size before running the VM functions which should works in suspended mode and which can be source of stack overflow. I don't know what suspended mode is. Please explain. The third solution is using pre created exception like for OutOfMemoryException. I think that the first solution is the best. Lazy object creation also has an added benefit of reducing the amount of time it takes to throw an exception (which is good). A question about the third solution. Will it be a better solution when an exception handler does indeed consume the exception object? In other words, does the third solution fix more SOE corner cases than the first solution? So I'd like start experiments with lazy exceptions support for VM code. The last time I looked, the lazy exception code was still in DRLVM code base. The experiments would be to find out if it causes more SOE cases to be handled correctly? Is this right? Thanks. Pavel Afremov. -- 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: [drlvm][classlib] unification of eclipse plugin
On 23/07/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: snip P.S. I'm an IDEA user. IDEA just lets me point at the JRE directory I want to use for execution and debugging, and it figures it out. Good IDEA, huh? Hopefully Eclipse will one day do this. I know you only wrote that to get a rise out of someone ... So how does IDEA know which Harmony JAR files to compile against? If you point Eclipse at a standard JRE it will pick out the rt.jar etc, but our modular packaging and multi-VM support means that we need a new VM-type for Eclipse. 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][classlib] unification of eclipse plugin
On 25/07/06, Vladimir Gorr [EMAIL PROTECTED] wrote: My suggestion is simple. I'd like Tim looked at our changes (* drlvm\trunk\build\patches\hyplugin.patch*) and apply them if there are no objections. It seems I need to create new JIRA issue (for convenience) I'll have a look soon (my hard disk died yesterday so I'm limited in what I can do while it is rebuilt). In the meantime Geir's suggestion of making a DRLVM-specific plug-in type sounds right, then we can move to the harmony launcher version when the VM does. Regards, Tim and attach the slightly-modified patch taking into account renaming ij to java. Does it make sense? After the Eclipse plug in will be modified we can remove the patching action. Thanks, Vladimir. So I was going to bring the code for the eclipse plugin from classlib into DRLVM (and patch it as necessary) - temporarily - until we get DRLVM using the launcher, and then it's moot - we can throw it out, and just use the one from classlib (and move it out of there into /tools or something) geir P.S. I'm an IDEA user. IDEA just lets me point at the JRE directory I want to use for execution and debugging, and it figures it out. Good IDEA, huh? Hopefully Eclipse will one day do this. - 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: [drlvm][classlib] unification of eclipse plugin
Tim Ellison wrote: On 23/07/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: snip P.S. I'm an IDEA user. IDEA just lets me point at the JRE directory I want to use for execution and debugging, and it figures it out. Good IDEA, huh? Hopefully Eclipse will one day do this. I know you only wrote that to get a rise out of someone ... Just you :) So how does IDEA know which Harmony JAR files to compile against? Honestly, I'll have to get back to you on that. If you point Eclipse at a standard JRE it will pick out the rt.jar etc, but our modular packaging and multi-VM support means that we need a new VM-type for Eclipse. 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: [testing] locale dependent tests
On 25/07/06, Richard Liang [EMAIL PROTECTED] wrote: snip Not sure what the fake hard-coded locale is. I used to set the default locale to some particular one, e.g., en_US, but it seems that someone (Tim) does not like the idea. :-) What I objected to was setting the locale to a specific value that made the tests pass even where the logic is locale-specific. So, for example, if an application using the ru_RU locale would experience the problem that Alexey is seeing with the DecimalFormat, then the tests should use the default locale, and we (Harmony) get the benefit of a wide community of hetrogeneous testers. i.e. don't make all tests run on a uniform machine set-up -- let them be realistic. 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][classlib] unification of eclipse plugin
Tim Ellison wrote: On 25/07/06, Vladimir Gorr [EMAIL PROTECTED] wrote: My suggestion is simple. I'd like Tim looked at our changes (* drlvm\trunk\build\patches\hyplugin.patch*) and apply them if there are no objections. It seems I need to create new JIRA issue (for convenience) I'll have a look soon (my hard disk died yesterday so I'm limited in what I can do while it is rebuilt). In the meantime Geir's suggestion of making a DRLVM-specific plug-in type sounds right, then we can move to the harmony launcher version when the VM does. Right - i assume that the patch will be moot then for the mainline plugin... geir Regards, Tim and attach the slightly-modified patch taking into account renaming ij to java. Does it make sense? After the Eclipse plug in will be modified we can remove the patching action. Thanks, Vladimir. So I was going to bring the code for the eclipse plugin from classlib into DRLVM (and patch it as necessary) - temporarily - until we get DRLVM using the launcher, and then it's moot - we can throw it out, and just use the one from classlib (and move it out of there into /tools or something) geir P.S. I'm an IDEA user. IDEA just lets me point at the JRE directory I want to use for execution and debugging, and it figures it out. Good IDEA, huh? Hopefully Eclipse will one day do this. - 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]
[app-bug] Anyone interested in chasing down a bug?
In HARMONY-956, I noted a bug that seems to point to a classpath management problem. I was just trying to run our own buildtest framework using the latest JRE, and I get : [exec] Uncaught exception in Thread-2: [exec] java.lang.NoClassDefFoundError: org/apache/log4j/spi/VectorWriter [exec] at org.apache.log4j.spi.LoggingEvent.init(LoggingEvent.java:126) [exec] at org.apache.log4j.Category.forcedLog(Category.java:375) [exec] at org.apache.log4j.Category.log(Category.java:869) [exec] at org.apache.commons.logging.impl.Log4JLogger.warn(Log4JLogger.java:176) [exec] at org.mortbay.jetty.servlet.WebApplicationContext.doStart(WebApplicationContext.java:521) [exec] at org.mortbay.util.Container.start(Container.java:72) [exec] at org.mortbay.http.HttpServer.doStart(HttpServer.java:755) [exec] at org.mortbay.util.Container.start(Container.java:72) [exec] at CruiseControlWithJetty$1.run(CruiseControlWithJetty.java:86) [exec] at java.lang.Thread.run() It may be really easy, but I don't have the time today... just a hint for someone that's interested. What I did was : 1) get the snapshot for windows (see download page on site) 2) do a checkout of the buildtest part of harmony 3) run 'ant setup' to get it setup (don't waste the time having it checkout the source for classlib and drlvm - just let it get CC and set that up. 4) run 'ant' 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] Using Yoko as CORBA for Harmony
Alexey Petrenko wrote: 2006/7/22, Geir Magnusson Jr [EMAIL PROTECTED]: Alexey Petrenko wrote: There are not much news to share... First of all I realized that I did not completely build Yoko. My build was failed with the test failure. I thought that all the tests are at the end so all the sources are built. But Yoko runs the tests after building each module... I reviewed Yoko bug database and found the issue corresponding to my failure, applied fix to my repository and definitely finished the build after that :) Ok. I've tried to run Maven on Harmony classlib+drlvm but have failed with it. Ant lets to define Java executable to run on by environment variable but I could not find such option for Maven. I've renamed ij.exe into java.exe and set JAVA_HOME to drlvm location. Maven started with Harmony after that but failed with Java version check. Drlvm shows version like 11.smth.smth. Probably we should fix this in drlvm. Or at least discuss this. Both are fixed in current version, or should be if it's just using the first line reported by -versin Investigation shown that Maven checks for java.class.version property value. Ah. Ok, I just fixed that in SVN. It's an awful fix, but it's no worse than it was, and I'll fix correctly later. I also found a shell script inside Yoko which can run Yoko tests without Maven. But I had not time to try it yet... Ok - I don't understand quite what you are trying to do. The goal is to integrate yoko to satisfy the corba requirements for java 5. it sounds like you are trying to run Yoko using Harmony. This is something that will happen, but w/o any integration into classlib, right now no one can look at this with you. Can you come up with a first-pass, simple, just-get-it-in-there integration into the classlibrary? geir SY, Alexey 2006/7/21, Geir Magnusson Jr [EMAIL PROTECTED]: So how goes the YOKO battle? Alexey Petrenko wrote: Guys, There is a CORBA implementation in Apache incubator named Yoko. http://incubator.apache.org/yoko/ I've built and reviewed it... It seems that Yoko have almost all the packages from the 1.5 specification. So it looks like a good candidate for using as CORBA for Harmony. The only problem is that Yoko has even more packages in org.omg then specified by 1.5 specification. So we should decide what to do with them. I'm planing to do the following things in nearest future: 1. Get the list of the not implemented classes in Yoko according to 1.5 spec. 2. Check that we have all the classes needed by Yoko in Harmony. Thoughts? Comments? SY, Alexey - 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] Using Yoko as CORBA for Harmony
This is excellent news! So, how do we get it integrated? :) geir Alexey Petrenko wrote: 2006/7/18, Alexey Petrenko [EMAIL PROTECTED]: Guys, There is a CORBA implementation in Apache incubator named Yoko. http://incubator.apache.org/yoko/ I've built and reviewed it... It seems that Yoko have almost all the packages from the 1.5 specification. So it looks like a good candidate for using as CORBA for Harmony. The only problem is that Yoko has even more packages in org.omg then specified by 1.5 specification. So we should decide what to do with them. I'm planing to do the following things in nearest future: 1. Get the list of the not implemented classes in Yoko according to 1.5 spec. I've attached the japi results of comparison of Yoko Core vs 1.5 spec... The summary is: Success rate is 77.6%. Bad: 112 classes, 50 interfaces, 576 methods. Missing: 3 packages, 21 classes, 13 interfaces, 37 methods, 2 constructors. Abs.add: 2 methods SY, Alexey - 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] Using Yoko as CORBA for Harmony
Yoko guys are preparing M1 release... Probably they will put all jars needed by us right after their M1 :) It seems that we (I) should start discussion on Yoko dev list to make Yoko compatible with 1.5. If it will not brake their plans. And make some fixes for Yoko. SY, Alexey 2006/7/25, Geir Magnusson Jr [EMAIL PROTECTED]: This is excellent news! So, how do we get it integrated? :) geir Alexey Petrenko wrote: 2006/7/18, Alexey Petrenko [EMAIL PROTECTED]: Guys, There is a CORBA implementation in Apache incubator named Yoko. http://incubator.apache.org/yoko/ I've built and reviewed it... It seems that Yoko have almost all the packages from the 1.5 specification. So it looks like a good candidate for using as CORBA for Harmony. The only problem is that Yoko has even more packages in org.omg then specified by 1.5 specification. So we should decide what to do with them. I'm planing to do the following things in nearest future: 1. Get the list of the not implemented classes in Yoko according to 1.5 spec. I've attached the japi results of comparison of Yoko Core vs 1.5 spec... The summary is: Success rate is 77.6%. Bad: 112 classes, 50 interfaces, 576 methods. Missing: 3 packages, 21 classes, 13 interfaces, 37 methods, 2 constructors. Abs.add: 2 methods SY, Alexey - 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] -- Alexey A. Petrenko 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] Using Yoko as CORBA for Harmony
Alexey Petrenko wrote: Yoko guys are preparing M1 release... Probably they will put all jars needed by us right after their M1 :) It seems that we (I) should start discussion on Yoko dev list to make Yoko compatible with 1.5. If it will not brake their plans. And make some fixes for Yoko. Agreed, but what about integration into Harmony? Can we start there? SY, Alexey 2006/7/25, Geir Magnusson Jr [EMAIL PROTECTED]: This is excellent news! So, how do we get it integrated? :) geir Alexey Petrenko wrote: 2006/7/18, Alexey Petrenko [EMAIL PROTECTED]: Guys, There is a CORBA implementation in Apache incubator named Yoko. http://incubator.apache.org/yoko/ I've built and reviewed it... It seems that Yoko have almost all the packages from the 1.5 specification. So it looks like a good candidate for using as CORBA for Harmony. The only problem is that Yoko has even more packages in org.omg then specified by 1.5 specification. So we should decide what to do with them. I'm planing to do the following things in nearest future: 1. Get the list of the not implemented classes in Yoko according to 1.5 spec. I've attached the japi results of comparison of Yoko Core vs 1.5 spec... The summary is: Success rate is 77.6%. Bad: 112 classes, 50 interfaces, 576 methods. Missing: 3 packages, 21 classes, 13 interfaces, 37 methods, 2 constructors. Abs.add: 2 methods SY, Alexey - 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] Using Yoko as CORBA for Harmony
Alexey Petrenko wrote: Yep, we can integrate it immediatly they put M1 jars to the site. Or our guys can build it by themselves. Ok - so the integration will be the same style as mx4j, right? I'll prepare the list of the files which we need to implement in Harmony for Yoko. If there is unimplemented files... Does any boudy know some tool for such task? :) SY, Alexey 2006/7/25, Geir Magnusson Jr [EMAIL PROTECTED]: Alexey Petrenko wrote: Yoko guys are preparing M1 release... Probably they will put all jars needed by us right after their M1 :) It seems that we (I) should start discussion on Yoko dev list to make Yoko compatible with 1.5. If it will not brake their plans. And make some fixes for Yoko. Agreed, but what about integration into Harmony? Can we start there? SY, Alexey 2006/7/25, Geir Magnusson Jr [EMAIL PROTECTED]: This is excellent news! So, how do we get it integrated? :) geir Alexey Petrenko wrote: 2006/7/18, Alexey Petrenko [EMAIL PROTECTED]: Guys, There is a CORBA implementation in Apache incubator named Yoko. http://incubator.apache.org/yoko/ I've built and reviewed it... It seems that Yoko have almost all the packages from the 1.5 specification. So it looks like a good candidate for using as CORBA for Harmony. The only problem is that Yoko has even more packages in org.omg then specified by 1.5 specification. So we should decide what to do with them. I'm planing to do the following things in nearest future: 1. Get the list of the not implemented classes in Yoko according to 1.5 spec. I've attached the japi results of comparison of Yoko Core vs 1.5 spec... The summary is: Success rate is 77.6%. Bad: 112 classes, 50 interfaces, 576 methods. Missing: 3 packages, 21 classes, 13 interfaces, 37 methods, 2 constructors. Abs.add: 2 methods SY, Alexey - 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]
[classlib][html] Should we try to be binary compatible with Sun's bdtd?
Hi: Working on the HTML parser, I found the following problem. The HTML parser can be parameterized by a DTD. The class javax.swing.text.html.parser.DTD has a method read(DataInputStream), that reads a DTD in binary format. AFAIK, there is no public specification of this format, and the recent contribution of the HTML component (HARMONY-948) seems to use its own binary format. Although I don´t know if there are applications out there using this method to load custom DTDs, the method is public, so I think we should be compatible with Sun. That is, we should be able to read Sun's bdtd, and our bdtd should be readable by Sun's implementation. Am i missing something? Does anyone know if there is a specification? Is it OK to reverse engineer the file html32.bdtd? -- Miguel Montes
Re: [drlvm] uses deprecated pthread function
On Wednesday 26 July 2006 01:18 Geir Magnusson Jr wrote: Gregory Shimansky wrote: Hello I've tried to build drlvm on Linux and it didn't compile because when compiling signals_ia32.cpp file compiler produced a warning that pthread_attr_getstackaddr is deprecated. I looked in /usr/include/pthread.h [1] and found out that it is really deprecated by __attribute_deprecated__. I don't know why everything is fine for others but for me gcc [2] does gives a warning on this function. I used the recommended replacement pthread_attr_getstack which gives both address and stack size in one call. The patch is in HARMONY-977. StackTest and other vm smoke tests pass for me now. Weird. It always has built for me on ubuntu 5/6 and passed the smoke tests. Is it marked as deprecated in your /usr/include/pthread.h header too? I googled a bit and found some references to Debian and Fedora that pthread_attr_getstackaddr is deprecated. There are even a bugs on Sun JDK about it [1]. Maybe this change just didn't make it into Ubuntu yet. [1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6349489 and http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6339849 -- 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]
some question about drlvm
does drlvm support for swing classlib? when I run Java2Demo.jar which is compiled with jdk, some error comes: java.lang.NoClassDefFoundError: javax/swing/JPanel at java.lang.VMClassRegistry.defineClass() at java.lang.ClassLoader.defineClass() at java.security.SecureClassLoader.defineClass() at java.net.URLClassLoader.findClassImpl() at java.net.URLClassLoader$4.run() at java.security.AccessController.doPrivilegedImpl() at java.security.AccessController.doPrivileged() at java.net.URLClassLoader.findClass() at java.lang.ClassLoader.loadClass() at java.net.URLClassLoader$SubURLClassLoader.loadClass() Caused by: java.lang.ClassNotFoundException: javax.swing.JPanel at java.net.URLClassLoader.findClass() at java.lang.ClassLoader.loadClass() at java.net.URLClassLoader$SubURLClassLoader.loadClass() at java.lang.ClassLoader.loadClass() at java.lang.VMClassRegistry.defineClass() how can i solve the problem? Thanks a lot.
Re: some question about drlvm
fc5 gcc-3.4.6 2006/7/26, Geir Magnusson Jr [EMAIL PROTECTED]: Are you using a snapshot or did you build it yourself? What platform? geir zouqiong wrote: does drlvm support for swing classlib? when I run Java2Demo.jar which is compiled with jdk, some error comes: java.lang.NoClassDefFoundError: javax/swing/JPanel at java.lang.VMClassRegistry.defineClass() at java.lang.ClassLoader.defineClass() at java.security.SecureClassLoader.defineClass() at java.net.URLClassLoader.findClassImpl() at java.net.URLClassLoader$4.run() at java.security.AccessController.doPrivilegedImpl() at java.security.AccessController.doPrivileged() at java.net.URLClassLoader.findClass() at java.lang.ClassLoader.loadClass() at java.net.URLClassLoader$SubURLClassLoader.loadClass() Caused by: java.lang.ClassNotFoundException: javax.swing.JPanel at java.net.URLClassLoader.findClass() at java.lang.ClassLoader.loadClass() at java.net.URLClassLoader$SubURLClassLoader.loadClass() at java.lang.ClassLoader.loadClass() at java.lang.VMClassRegistry.defineClass() how can i solve the problem? Thanks a lot. - 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-948 : HTML sub-component of Swing
+1 -Stepan. On 7/24/06, Geir Magnusson Jr wrote: All is in order and in SVN for Harmony-948 wrt BCC and ACQ. Please vote to accept or reject this codebase into the Apache Harmony class library : [ ] + 1 Accept [ ] -1 Reject (provide reason below) Lets let this run a minimum of 3 days unless a) someone states they need more time or b) we get all committer votes before then. geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][html] Should we try to be binary compatible with Sun's bdtd?
Miguel Montes 写道: Hi: Working on the HTML parser, I found the following problem. The HTML parser can be parameterized by a DTD. The class javax.swing.text.html.parser.DTD has a method read(DataInputStream), that reads a DTD in binary format. AFAIK, there is no public specification of this format, and the recent contribution of the HTML component (HARMONY-948) seems to use its own binary format. Although I don´t know if there are applications out there using this method to load custom DTDs, the method is public, so I think we should be compatible with Sun. That is, we should be able to read Sun's bdtd, and our bdtd should be readable by Sun's implementation. Sounds reasonable. Am i missing something? Does anyone know if there is a specification? Is it OK to reverse engineer the file html32.bdtd? -- Spark Shen China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib]bug-to-bug compatibility j.u.Formatter
On 7/25/06, Richard Liang wrote:
Hello All,
As we have further discussion about our Compatibility issues, I'd like
to summarize this particular problems and ask for comments. Thanks a lot.
If we pass a null to j.u.Formatter.Formatter(Appendable a), when we try
to get the destination of the formatter's output by calling
formatter.out(), RI will thrown a java.util.FormatterClosedException.
But according to the specification, the destination should be a
StringBuilder.
Shall we follow RI or specification?
(My opinion is: Following spec, and record a Non-bug differences from
RI in JIRA)
+1 for following the spec. and filling corresponding JIRA
Thanks,
Stepan
The following test passes on Harmony, but fails on RI.
public void test_ConstructorLjava_lang_Appendable() {
Formatter formatter = new Formatter((Appendable) null);
Appendable out = formatter.out();
assertTrue(out instanceof StringBuilder);
}
SNIP
--
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: some question about drlvm
From this I deduce you built it yourself :) If you want Swing/AWT included, you need to : 1) Follow directions in depends/lib/build to get the dependencies. 2) set the property with.awt.swing to true when building... geir zouqiong wrote: fc5 gcc-3.4.6 2006/7/26, Geir Magnusson Jr [EMAIL PROTECTED]: Are you using a snapshot or did you build it yourself? What platform? geir zouqiong wrote: does drlvm support for swing classlib? when I run Java2Demo.jar which is compiled with jdk, some error comes: java.lang.NoClassDefFoundError: javax/swing/JPanel at java.lang.VMClassRegistry.defineClass() at java.lang.ClassLoader.defineClass() at java.security.SecureClassLoader.defineClass() at java.net.URLClassLoader.findClassImpl() at java.net.URLClassLoader$4.run() at java.security.AccessController.doPrivilegedImpl() at java.security.AccessController.doPrivileged() at java.net.URLClassLoader.findClass() at java.lang.ClassLoader.loadClass() at java.net.URLClassLoader$SubURLClassLoader.loadClass() Caused by: java.lang.ClassNotFoundException: javax.swing.JPanel at java.net.URLClassLoader.findClass() at java.lang.ClassLoader.loadClass() at java.net.URLClassLoader$SubURLClassLoader.loadClass() at java.lang.ClassLoader.loadClass() at java.lang.VMClassRegistry.defineClass() how can i solve the problem? Thanks a lot. - 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] uses deprecated pthread function
I have same issue for FC5. The patch for H-977 helps to resolve it. Therefore it'd be not bad to apply this patch to SVN repository for convenience. Thanks, Vladimir. On 7/26/06, Gregory Shimansky [EMAIL PROTECTED] wrote: On Wednesday 26 July 2006 01:18 Geir Magnusson Jr wrote: Gregory Shimansky wrote: Hello I've tried to build drlvm on Linux and it didn't compile because when compiling signals_ia32.cpp file compiler produced a warning that pthread_attr_getstackaddr is deprecated. I looked in /usr/include/pthread.h [1] and found out that it is really deprecated by __attribute_deprecated__. I don't know why everything is fine for others but for me gcc [2] does gives a warning on this function. I used the recommended replacement pthread_attr_getstack which gives both address and stack size in one call. The patch is in HARMONY-977. StackTest and other vm smoke tests pass for me now. Weird. It always has built for me on ubuntu 5/6 and passed the smoke tests. Is it marked as deprecated in your /usr/include/pthread.h header too? I googled a bit and found some references to Debian and Fedora that pthread_attr_getstackaddr is deprecated. There are even a bugs on Sun JDK about it [1]. Maybe this change just didn't make it into Ubuntu yet. [1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6349489 and http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6339849 -- 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/MMTk] v0.1 porting layer has been committed
On 7/24/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote:
Weldon Washburn wrote:
On 7/23/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote:
Are you up-to-date? We don't have ij.exe anymore...
I just did a clean svn checkout and now can build java.exe.
Actually, I tried several times over the weekend to do a fresh, new
svn checkout. I rolled back to a two week old revision. classlib
and drlvm downloaded OK but I get the following compile time error:
[javac]
C:\t_harmony\classlib\trunk\modules\auth\src\main\java\windows\org\a
pache\harmony\auth\module\NTLoginModule.java:43:
org.apache.harmony.auth.module.
NTLoginModule is not abstract and does not override abstract method
initialize(j
avax.security.auth.Subject,javax.security.auth.callback.CallbackHandler,java.uti
l.Mapjava.lang.String,?,java.util.Mapjava.lang.String,?) in
javax.security.a
uth.spi.LoginModule
[javac] public class NTLoginModule implements LoginModule {
Since the svn commits don't interact with the build at this point, I
went back to a two week old tree to demo the MMTk porting bugs.
This brings up a point. What should we do when we discover an svn
checkout and build is broken?
I'm not convinced it's broken. I've been building just fine all weekend
to create the JRE and HDK downloads, so I think that it's local to your
box.
It is local to my box afterall. It took a while but I discovered I
was using an old beta version of J2SE 1.5.
We get broken build messages on the commit list from IBM (and we need to
add that feature to our build-test infra so other can do that)
I figure I would wait until Monday to
retry. If it is still broken, then start looking at the logs.
Perhaps we should post a [classlib] revision 999 is broken
message with the problem in the body of the message??
Try a fresh checkout and see what happens.
geir
-
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: [continuum] BUILD FAILURE: Classlib/win.ia32 Build/Test
Can anyone recreate this failure? I can't. [exec] [junit] TEST org.apache.harmony.tests.internal.net.www.protocol.http.HttpURLConnectionTes t FAILED Is there any way we can get the JUnit results for these builds? I can never recreate these failures on my machine and I don't have anywhere to start debugging. I don't even know which test method failed. -Nathan -Original Message- From: Apache Harmony Build [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 26, 2006 12:19 AM To: [EMAIL PROTECTED] Subject: [continuum] BUILD FAILURE: Classlib/win.ia32 Build/Test Online report : http://ibmonly.hursley.ibm.com/continuum/win.ia32/servlet/continuum/target /ProjectBuild.vm/view/ProjectBuild/id/6/buildId/1948 Build statistics: State: Failed Previous State: Ok Started at: Wed, 26 Jul 2006 06:06:48 +0100 Finished at: Wed, 26 Jul 2006 06:18:37 +0100 Total time: 11m 48s Build Trigger: Schedule Exit code: 1 Building machine hostname: hy1 Operating system : Windows XP(Service Pack 2) Java version : 1.5.0_06(Sun Microsystems Inc.) Changes classlib\modules\logging\src\main\java\java\util\logging\LogManager.java - 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/MMTk] v0.1 porting layer has been committed
On 7/25/06, Alex Astapchuk [EMAIL PROTECTED] wrote: Weldon, I've updated the magics.cpp with fromLong/toLong fixed. But I suspect other issues as well, and I'm working on it, so please expect more commits of magics.cpp to come. Please reserve the word commit to refer to an svn commit. Otherwise everyone will be confused. To be clear, magics.cpp has been posted to JIRA Harmony-816. It has not been commited to svn repository. In any case, I got the new magics.cpp and it seems the long problem has been fixed. -- Thanks, Alex Alex Astapchuk wrote: Weldon, I also recently discovered what could be problem with jitrino.JET compiling OPCODE_LCMP. Jitrino.JET is core dumping. This problem I'm looking into the issue. Could you please share the class/method that causes assertion ? - 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: [vote] acceptance of HARMONY-948 : HTML sub-component of Swing
+1 2006/7/26, Stepan Mishura [EMAIL PROTECTED]: +1 -Stepan. On 7/24/06, Geir Magnusson Jr wrote: All is in order and in SVN for Harmony-948 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] -- Alexey A. Petrenko 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]
