[classlib] More build file simplification
I've thought of another few items that I'd like to sort out. 10) Currently the 'build' directory contains sub-directories for 'tests' and 'test_report' but the compiled classes aren't in a sub-directory. This seems a bit confused. Perhaps they should go in a sub-directory 'classes' or 'main'? (Also at the module level the tests get put in a directory called 'bin/test' which seems rather inconsistent.) 11) The basedir for module ant files is the main module directory - e.g. module/luni. But the tests run in module/luni/bin/test. This means that relative paths in the ant file all start with ../.. *except* the bootclasspath appends which start ../../../.. which is a little confusing. Perhaps it would simplify things if tests ran from the main module directory? And a quick update on the other items... 1) Moved build.xml up to top-level. Add targets to make top-level *the* top-level API for developers. I also added a 'help' target with brief usage information. Done. Well almost. You can do: ant -Dbuild.module=luni and/or: ant -Dbuild.module=luni test But: ant -Dbuild.module=luni clean probably doesn't do what you might expect. 2) Moved build.xml from modules/*/make to modules/*. Done. 3) Top-level build target doesn't clean anymore. The 'rebuild' target does. Done. (By Geir IIRC.) 4) Module ant file layers compressed back to one file. Done. 5) Convert XML properties to text. Not sure this is as easy as I first thought. 6) Use of macros. Ongoing. 7) Removed verbose init targets from module ant files. Done. 8) Fixed module ant file 'clean' targets to clean the class files they create. Done. 9) Separate exclude lists. Ongoing resurrecting HARMONY-263. -Mark. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] More build file simplification
2006/6/21, Mark Hindess [EMAIL PROTECTED]: I've thought of another few items that I'd like to sort out. 10) Currently the 'build' directory contains sub-directories for 'tests' and 'test_report' but the compiled classes aren't in a sub-directory. This seems a bit confused. Perhaps they should go in a sub-directory 'classes' or 'main'? (Also at the module level the tests get put in a directory called 'bin/test' which seems rather inconsistent.) 11) The basedir for module ant files is the main module directory - e.g. module/luni. But the tests run in module/luni/bin/test. This means that relative paths in the ant file all start with ../.. *except* the bootclasspath appends which start ../../../.. which is a little confusing. Perhaps it would simplify things if tests ran from the main module directory? And a quick update on the other items... 1) Moved build.xml up to top-level. Add targets to make top-level *the* top-level API for developers. I also added a 'help' target with brief usage information. Done. Well almost. You can do: ant -Dbuild.module=luni how to run tests from two modules and get a single report? and/or: ant -Dbuild.module=luni test But: ant -Dbuild.module=luni clean probably doesn't do what you might expect. 2) Moved build.xml from modules/*/make to modules/*. Done. 3) Top-level build target doesn't clean anymore. The 'rebuild' target does. Done. (By Geir IIRC.) 4) Module ant file layers compressed back to one file. Done. 5) Convert XML properties to text. Not sure this is as easy as I first thought. 6) Use of macros. Ongoing. 7) Removed verbose init targets from module ant files. Done. 8) Fixed module ant file 'clean' targets to clean the class files they create. Done. 9) Separate exclude lists. Ongoing resurrecting HARMONY-263. -Mark. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] milestones and roadmap
17) Release engineering: regular building and publishing of the binaries of HDK for downloading. 18) Don't we want to include applications which will show how mature Harmony is as milestone goals? For example, be able to run Eclipse stably enough to use it as development platform. Thanks, Vladimir On 6/21/06, Rana Dasgupta [EMAIL PROTECTED] wrote: On 6/20/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: I'd like to start assembling a high-level roadmap of the milestones we'd like to achieve in the next 12 months. I volunteer to track and organize, but this clearly is a community activity so lets start by just tossing out ideas. 1) By ApcheCon EU - a combined snapshot that is a pure open source VM + classlib. Issues - I assume we'll use DRLVM. 7) Test coverage - should we think about targets for test coverage ? It would be nice to merge requirements from 1) and 7) and identify a basic distribution( classlib + VM ) along with some platform targets, and tests for the same ...(as Mikhail says) a test suite of acceptance tests( for JIRA submissions ), stress tests, performance tests, some automated round the clock testing etc. Some of this probably has implications on the infrastructure needed? Thanks, Rana 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] More build file simplification
On 21 June 2006 at 13:10, Mikhail Loenko [EMAIL PROTECTED] wrote: how to run tests from two modules and get a single report? ant -Dbuild.module=luni test; ant -Dbuild.module=nio test patches welcome ;-) Tricky without the ant for/if extensions I think. Regards, Mark - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[classlib][math] Location of performance tests (was: Re: performance improvement for java.math package)
I'd like to bring it to common judgment. AFAIU we have two basic options for performance tests location: make them module level or make a top-level tests subtree that would contain all types of the tests except for unit tests BTW, In the testing convention my intent was to cover unit tests only. Though we did not agree which exactly tests are unit, so I avoided that word. But I definitely did not mean performance, stress and whatever special types of the tests. If no one objects I'll add some clarification to the conventions proposal. Thanks, Mikhail 2006/6/20, Vladimir Strigun [EMAIL PROTECTED]: On 6/20/06, Mikhail Loenko [EMAIL PROTECTED] wrote: I think they are not unit tests and should go to a different (performance?) test suite. Right now we don't have one but it seems to be time to create it Of course, it's not unit tests, but my suggestion was based on our testing convention. What do you think about modulename/src/tests/performance ? Thanks, Vladimir. Thanks, Mikhail 2006/6/20, Vladimir Strigun [EMAIL PROTECTED]: Hi Mikhail, AFAIK, we haven't such kind of tests in svn yet. It's hard to define best place for it, but since this suite is intended for java.math testing only and it's implementation-independent tests, I believe modules/math/src/test/java/tests/api is appropriate place. If you agree with this I will create patch for suite, add copyright and change package definition of classes. What do you think about it? Thanks, Vladimir. On 6/13/06, Mikhail Loenko [EMAIL PROTECTED] wrote: Hi Vladimir What do you think the most appropriate location and suite for the tests in the HARMONY-551 are? Thanks, Mikhail 2006/6/2, Vladimir Strigun [EMAIL PROTECTED]: Our team has done some analysis of current Harmony implementation of java.math package. The implementation was considered from the performance point of view and I'd like to share results of our work with you. The analysis and tuning was made from the enterprise-level applications point of view which are known to use BigInteger and BigDecimal for storing numeric information. In most cases the numbers there fit well within 32 bits. So coming from the BigDecimal perspective which is really important for these applications and taking into account some specifics (small numbers) we made some optimizations in both BigDecimal and BigInteger. The latter was tuned specifically for BigDecimal: - Special handling for small numbers (fit within 32 bit) was added to all methods - Frequently used constants (0..10) were cached and reused by valueOf method (no need to create a new instance of BigInteger) - as well as were powers of 10 (0..10) - methods add(), divide(), divideAndRemainer() in BigInteger were optimized for short values if both arguments can fit in 32 bits the resulting BigInteger is created by valueOf method. If we consider enterprise level applications, we can imagine that toString() method is also frequently used. The method was analyzed and as a result we combined toString() methods in BigDecimal and BigInteger to one unified method in BigInteger. Method BigInteger.toDecimalScaledString(int scale) now is used from both BigInteger and BigDecimal. This way allows reducing amount of created objects and data copying. In addition, size calculation was modified for resulting array. In the new implementation the size is calculated with less precision. Because allocated char array will be copied into String and collected by GC after toString() then it is not a problem if the allocated char array will be slightly bigger then necessary. I've attached the changes we made for BigInteger and BigDecimal to Harmony-551 We also have created a set of micro benchmarks (which I'll to attach to JIRA as well) which shows that our special-case handling doesn't break the performance for other cases and we do not degrade in common, and, of course, all unit tests pass with new version. Below you can find several comparisons in performance between current version and the fixed one. === Ops/sec for toString() method of BigDecimal Number Current fixed one of digits version 2 11215354 4 774 7514 8 615 6748 12 743 5543 16 623 4494 24 389 4895 32 306 3496 48 232 5815 64 224 3761 128 91 87 Ops/sec for divide method of BigInteger Number Current fixed one of digits version 2 52476315 4 46236497 8 55607491 12 838 838 16 25332063 24 16891717 32 23972494 48 21432131 64 613 525 128 13991418
Re: [classlib] More build file simplification
2006/6/21, Mark Hindess [EMAIL PROTECTED]: On 21 June 2006 at 13:10, Mikhail Loenko [EMAIL PROTECTED] wrote: how to run tests from two modules and get a single report? ant -Dbuild.module=luni test; ant -Dbuild.module=nio test it does not work: the second ant cleans result of the first one Thanks, Mikhail patches welcome ;-) Tricky without the ant for/if extensions I think. Regards, Mark - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[classlib] Help wanted!
I was looking at building (and testing) with Eclipse + IBM VME. I think this is really important since ecj has a much cleaner classpath when it compiles so it helps us find errors quicker. The logs come out at over 3MB! There are lots of warnings about less than ideal type checking - mostly as a result of our adoption of more generics. For example: [javac] 1. WARNING in /pbuilder/tmp/Harmony.my/modules/accessibility/src/mai n/java/javax/accessibility/AccessibleRelationSet.java [javac] (at line 44) [javac] relations.add(relation); [javac] ^^^ [javac] Type safety: The method add(Object) belongs to the raw type Vector. References to generic type VectorE should be parameterized [javac] -- [javac] 2. WARNING in /pbuilder/tmp/Harmony.my/modules/accessibility/src/mai n/java/javax/accessibility/AccessibleRelationSet.java [javac] (at line 88) [javac] (AccessibleRelation[])relations.toArray(new AccessibleRelation[r elations.size()]); [javac] ^^ ^ [javac] Type safety: The method toArray(Object[]) belongs to the raw type Ve ctor. References to generic type VectorE should be parameterized I think we should try to improve these, but there are rather too many for me to do on my own! What do others think? I think we could disable the warnings from Eclipse but I don't think that's really the right thing to do. The distribution of warnings is as follows: 4 accessibility 24 archive 90 auth 707 awt 61 beans 7 crypto 128 jndi 206 luni 10 luni-kernel 4 misc 8 nio 7 nio_char 32 prefs 17 regex 260 rmi 568 security 936 swing 26 text 14 x-net Regards, Mark. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] Help wanted!
Hello Mark, How about advocating all code contributers to eliminate such warnings in their interested module? It's really a big task for one or two committers. I'm willing to help to check NIO module. Thanks! On 6/21/06, Mark Hindess [EMAIL PROTECTED] wrote: I was looking at building (and testing) with Eclipse + IBM VME. I think this is really important since ecj has a much cleaner classpath when it compiles so it helps us find errors quicker. The logs come out at over 3MB! There are lots of warnings about less than ideal type checking - mostly as a result of our adoption of more generics. For example: [javac] 1. WARNING in /pbuilder/tmp/Harmony.my/modules/accessibility/src/mai n/java/javax/accessibility/AccessibleRelationSet.java [javac] (at line 44) [javac] relations.add(relation); [javac] ^^^ [javac] Type safety: The method add(Object) belongs to the raw type Vector. References to generic type VectorE should be parameterized [javac] -- [javac] 2. WARNING in /pbuilder/tmp/Harmony.my/modules/accessibility/src/mai n/java/javax/accessibility/AccessibleRelationSet.java [javac] (at line 88) [javac] (AccessibleRelation[])relations.toArray(new AccessibleRelation[r elations.size()]); [javac] ^^ ^ [javac] Type safety: The method toArray(Object[]) belongs to the raw type Ve ctor. References to generic type VectorE should be parameterized I think we should try to improve these, but there are rather too many for me to do on my own! What do others think? I think we could disable the warnings from Eclipse but I don't think that's really the right thing to do. The distribution of warnings is as follows: 4 accessibility 24 archive 90 auth 707 awt 61 beans 7 crypto 128 jndi 206 luni 10 luni-kernel 4 misc 8 nio 7 nio_char 32 prefs 17 regex 260 rmi 568 security 936 swing 26 text 14 x-net Regards, Mark. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Andrew Zhang China Software Development Lab, IBM
Re: [classlib] More build file simplification
On 21 June 2006 at 13:36, Mikhail Loenko [EMAIL PROTECTED] wrote: 2006/6/21, Mark Hindess [EMAIL PROTECTED]: On 21 June 2006 at 13:10, Mikhail Loenko [EMAIL PROTECTED] wrote: how to run tests from two modules and get a single report? ant -Dbuild.module=luni test; ant -Dbuild.module=nio test it does not work: the second ant cleans result of the first one Argh ... default clean ... How would you suggest we fix it? patches welcome ;-) Tricky without the ant for/if extensions I think. Regards, Mark. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] More build file simplification
An easy way is return per module targets to build-test.xml and run them old way. What do you think? I'd personally avoid spoiling top-level build.xml with too many targets like that. Thanks, Mikhail 2006/6/21, Mark Hindess [EMAIL PROTECTED]: On 21 June 2006 at 13:36, Mikhail Loenko [EMAIL PROTECTED] wrote: 2006/6/21, Mark Hindess [EMAIL PROTECTED]: On 21 June 2006 at 13:10, Mikhail Loenko [EMAIL PROTECTED] wrote: how to run tests from two modules and get a single report? ant -Dbuild.module=luni test; ant -Dbuild.module=nio test it does not work: the second ant cleans result of the first one Argh ... default clean ... How would you suggest we fix it? patches welcome ;-) Tricky without the ant for/if extensions I think. Regards, Mark. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib]native codes layout question(was Re: [classlib][NIO|VMI]JNI 1.4 enhancement on ByteBuffer)
Hi Oliver: I've seen the modularisation on native, that's great! :) But I have a question here. As I work on native before, I usually build the whole native code once, and then make seperate modules alone, e.g., luni, or nio. It was easy to enter directory luni and force build by make and create a new DLL/so file. In this way it is easy to write codes and debug. However after modularisation nowadays, as there are envionment variables in the makefile, which are defined in the build.xml, I have no idea but build whole native with ant, even after changing a single line. So I turn to help for if there's an easy way to build single module alone? Thanks! at 06-6-20，Oliver Deakin [EMAIL PROTECTED] wrote： Paulex Yang wrote: Seems no one objects this proposal:), so I'm going to implement the JNI1.4 enhancement in nio module, i.e, provide patch to Harmony-578, Because this implementation requires some native codes, so I probably need to reintroduce hynio.dll(.so), but I have some questions.(Excuse me about my ignorance on the native layout evolution). At first, seems native codes will be separated into modules(I guess Oli is working on?), so should I assume my native codes will be directly put into nio modules, or still in native-src/win.IA32/nio directory? because I'm used to provide a shell to move/svn add new files in the patch, so it will be easier for me to know how others think about it. It depends on whether you want to wait for what I'm doing or not :) If you want to get the code out now, then you can temporarily put it under native-src/win.IA32/nio and I will move it later as part of the natives modularisation. However, if you don't mind waiting a day or so I should be able to submit my first patch to move the prefs natives. This ought to be enough of an example for you to put your native code directly into modules/nio/src/main/native. And second, the native codes probably need portlib, so the portlib's header file must be accessible, say, portsock.h, but now it has been moved into luni/src/main/native/blabla, should I include one in my patch so that nio module can have a copy? or the header file itself should be put some other well known directory(deploy/build/include I guess)? At build time, the copy.native.includes target in luni/make/build.xml is called - it copies a selection of the header files in luni/src/main/native/include that need to be shared between modules into the deploy/include directory. This is done with an explicit fileset in luni/make/build.xml - if you need to have portsock.h added to the list of shared header files, then this is the place to make that change. Just add its filename to the list, and next time you build it will appear in the deploy/include directory. Your nio code should include the headers from the deploy/include dir, and *not* directly from the luni/src/main/native/include dir. I hope this makes more sense now - if it doesn't, please let me know. I am in the process of writing up some documentation for the website on the natives layout and where headers should go (and also how modules should build against the HDK) - once that is complete it should all be a lot clearer. Regards, Oliver -- Oliver Deakin IBM United Kingdom Limited - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM
Re: Pack200 -- can now obtain files stored in archive
On 21/06/06, Stepan Mishura [EMAIL PROTECTED] wrote: On 6/21/06, Alex Blewitt wrote: We agreed to separate providers implementation [1]. But I'm not sure the same should be done for a concrete class implementation. In you case it is implementation of java.util.jar.Pack200 but there are lots of other cases ,for example, java.security.Policy. So we'll got a lot of modules with only one class inside. It's not just a concrete class, though. The API basically boils down to two methods: unpack() pack() The thing is, that an implementation of this JSR isn't just a simple class that provides a couple of methods. There's a lot of detail in the coding, decoding, and subsequent parsing that goes on. There's also a few other utilities that would be useful for performing compression on data streams if people would be interested in using them. So don't confuse a simple API with a simple solution :-) The providers/ would be exactly the right place for this kind of code to live (at least, for the implementation). There are stub classes that are needed in the archive/ module, such as java.util.jar.Packer along with the factory code to instantiate the provider; but the factory instantiating the provider is actually specified as part of the Packer's static access methods. Alex. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Pack200 -- can now obtain files stored in archive
By the way, one of the tests has a Pack200 archive with Java classes in it, and one of the tests attempts to unpack that archive. With the recent change in 415891, it's possible that this test will fail now. But then, I'm not sure whether the tests are being run ? If not, it's relatively easy to replace the HelloWorld.pack with a packed Jar file that just contains resources (e.g. GIFs, text files) to resolve the problem. Alex. On 20/06/06, Alex Blewitt [EMAIL PROTECTED] wrote: I've jumped ahead a bit on the pack200 archive, and written the unpacking for file data stored in a pack200 archive. The current implementation will barf if the file size is 2Gb, because I'm pulling all the data into a byte array at present (it's pretty memory hungry anyway). I've not got any output mechanisms coded yet, but performing a Segment.parse(in) on a pack200 will return you a Segment, and from there you can get the file_bits to reconstitute the data files. Should be relatively easy to export those into an appropriate output format at a later stage. If there's any classes in the pack file at the moment, it will fall over -- but that's because the format is organised as [constant pool, class/bytecode stuff, file data]. So if there'sno class/bytecode stuff, it just falls through to the file data afterwards. Obviously this isn't a particularly likely scenario (unless source files are stored in a Zip and then packed?) but at least it shows it's on the right track. The prior caveats still apply; it only works for un-Gzipped pack files (i.e. those created with --no-gzip) and there's no reconstitution of the goods at the other end. I'll probably spend some time on decoding the bytecode in the near future, but that will take some time. In other news, there was interest in getting the pack200 stuff under a dual licence so that it could be included in the Gnu Classpath libs too ... I'm open to that idea, as long as forking doesn't become an issue. I've also put some notes together in OPML as to the ordering of bands in a pack200 file in a separate harmony bug; not sure if it will make it into the SVN tree in a suitable location. I'd also like to suggest that we try to move the pack200 code out of the archive module into its own dedicated archive-pack200 module. If this code is to be reused in other environments (whether part of a classlib/J2SE implementation, or as a library/driver for other VMs) then it would be a good idea to separate out the implementation from the Java interfaces. After all, the standard Sun VM allows you to switch to a different pack200 provider using the java.util.jar.Pack200.Unpacker system property. It would probably not make sense for a provider to also have the remainder of the java.util.jar classes in there. Alex. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Eclipse Plug-in Dependencies not resolving
I agree. One of my pet peeves was that Eclipse moved from a nice, structured, parsable format in the form of XML to a bastardised text format that uses ;name=value to attach parameters with weird syntax (like the fact that leading whitespace is ignored and means line continuation so you end up with trailing whitespace to separate the Jars -- or in the OSGi's case, a comma). And technically, 72 chars is the max length of a line, though in practice everyone seems to ignore it. Peter Kriens doesn't seem to like XML files, which might explain it: http://www.osgi.org/blog/2006/04/maven.html How anybody can use XML for a human writeable/readable format escapes me, but it has taken epidemic forms. Perhaps because it doesn't suffer from the insane fragility that Manifest.MF and Makefiles before them? Alex. On 21/06/06, Nathan Beyer [EMAIL PROTECTED] wrote: Was it just that the value of the Import-Package had a newline before the actual package names? I was just frustrated with myself that I couldn't figure it out. I like how OSGi uses the manifest, but manifest file format is the most fragile thing I've ever dealt with; one wrong whitespace or extra character and BOOM. -Nathan -Original Message- From: George Harley [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 20, 2006 8:42 AM To: harmony-dev@incubator.apache.org Subject: Re: Eclipse Plug-in Dependencies not resolving Hi Tim, Thank you very much, it all works fine for me now. Hopefully things are now fixed for Nathan (and everyone else) too. Best regards, George Tim Ellison wrote: I've been through and fixed the manifest and classpath files for the incoming Swing/AWT/Accessibility/Misc code (in repo r415629). Regards, Tim George Harley wrote: Hi Nathan, Yes, seeing this too. Suspect that the Swing and AWT manifests are currently broken and that this is upsetting PDE. Perhaps things can be temporarily solved for you by reverting your Eclipse PDE target to a build prior to the Swing/AWT ? Assuming you have one lying around. Best regards, George Nathan Beyer wrote: Is anyone else that's using Eclipse having trouble resolving the Plug- in Dependencies? When I updated and rebuilt everything after the Swing/AWT code was introduced none of the plug-in dependencies resolve any longer, so my projects don't compile. I'm back to just manually adding all of the JARs from the build to the project. -Nathan - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r415716 - in /incubator/harmony/enhanced/classlib/trunk/modules/security/src: main/java/common/java/security/AlgorithmParameterGenerator.java test/api/java/org/apache/harmony/security/
Oops, thanks for catching that Stepan,
Looking again I was reading this version:
public final void init(AlgorithmParameterSpec genParamSpec)
throws InvalidAlgorithmParameterException
I'll back out that change.
Regards,
Tim
Stepan Mishura wrote:
Hi Tim,
AlgorithmParameterGenerator.init(int) doesn't declare exceptions to be
thrown[1].
Thanks,
Stepan.
[1]
http://java.sun.com/j2se/1.5.0/docs/api/java/security/AlgorithmParameterGenerator.html#init(int
)
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Tuesday, June 20, 2006 10:55 PM
To: [EMAIL PROTECTED]
Subject: svn commit: r415716 - in
/incubator/harmony/enhanced/classlib/trunk/modules/security/src:
main/java/common/java/security/AlgorithmParameterGenerator.java
test/api/java/org/apache/harmony/security/tests/java/security/AlgorithmParameterGenerator1Test.java
Author: tellison
Date: Tue Jun 20 08:54:49 2006
New Revision: 415716
URL: http://svn.apache.org/viewvc?rev=415716view=rev
Log:
Add exception throws declaration as in spec.
Modified:
incubator/harmony/enhanced/classlib/trunk/modules/security/src/main/java/common/java/security/AlgorithmParameterGenerator.java
incubator/harmony/enhanced/classlib/trunk/modules/security/src/test/api/java/org/apache/harmony/security/tests/java/security/AlgorithmParameterGenerator1Test.java
Modified:
incubator/harmony/enhanced/classlib/trunk/modules/security/src/main/java/common/java/security/AlgorithmParameterGenerator.java
URL:
http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/modules/security/src/main/java/common/java/security/AlgorithmParameterGenerator.java?rev=415716r1=415715r2=415716view=diff
==
---
incubator/harmony/enhanced/classlib/trunk/modules/security/src/main/java/common/java/security/AlgorithmParameterGenerator.java
(original)
+++
incubator/harmony/enhanced/classlib/trunk/modules/security/src/main/java/common/java/security/AlgorithmParameterGenerator.java
Tue Jun 20 08:54:49 2006
@@ -143,7 +143,7 @@
* @com.intel.drl.spec_ref
*
*/
-public final void init(int size) {
+public final void init(int size) throws
InvalidAlgorithmParameterException {
spiImpl.engineInit(size, randm);
}
Modified:
incubator/harmony/enhanced/classlib/trunk/modules/security/src/test/api/java/org/apache/harmony/security/tests/java/security/AlgorithmParameterGenerator1Test.java
URL:
http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/modules/security/src/test/api/java/org/apache/harmony/security/tests/java/security/AlgorithmParameterGenerator1Test.java?rev=415716r1=415715r2=415716view=diff
==
---
incubator/harmony/enhanced/classlib/trunk/modules/security/src/test/api/java/org/apache/harmony/security/tests/java/security/AlgorithmParameterGenerator1Test.java
(original)
+++
incubator/harmony/enhanced/classlib/trunk/modules/security/src/test/api/java/org/apache/harmony/security/tests/java/security/AlgorithmParameterGenerator1Test.java
Tue Jun 20 08:54:49 2006
@@ -306,7 +306,7 @@
* Assertion: returns AlgorithmParameters object
*/
public void testAlgorithmParameterGenerator10()
-throws NoSuchAlgorithmException {
+throws NoSuchAlgorithmException,
InvalidAlgorithmParameterException {
if (!DSASupported) {
fail(validAlgName + algorithm is not supported);
return;
--
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] what's next?
On 6/21/06, Weldon Washburn [EMAIL PROTECTED] wrote: I agree with java 5 being #1. Some additional thoughts. GCV4 needs replacing for a variety of reasons. The port of MMTk should pick up a bunch of the great GC work being done in the Jikes/MMTk community. It would also be nice to have a simple C generational collector. I am real busy with MMTk port. Otherwise I would volunteer to look into porting SableVM's generational collector. I think it was written by Carl Lebsack. Porting both MMTk and SableVM GC would give DRLVM a much better basis for generic VM/GC interfaces. If no one else is doing it, I will start the porting of SableVM's gen GC into DRLVM. Thanks, xiaofeng - 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: r415681 - in /incubator/harmony/enhanced/classlib/trunk/modules/auth: build.xml make/build.xml make/common/ make/hyproperties.xml
On 21 June 2006 at 10:35, Stepan Mishura [EMAIL PROTECTED] wrote:
Hi Mark,
I believe that 'move' means copying file with its revisions history. This
can be done by 'svn move'. You did this for 'hyproperties.xml' file but not
for 'build.xml' file. Why? Yes, it is possible to figure out from its
initial revision (415681) what was the origin. But I prefer to have unbroken
revisions history.
I probably should have provided more information on the commit message.
Sorry.
The move (as discussed on the Simplifying... thread) actually took
all but a few lines of _both_:
make/common/build.xml, and
make/common/build.xml
I don't believe there is a way to keep the history of both and keeping
history of just one would probably have been equally confusing.
Happy to take suggestions on what you think I should have done.
Regards,
Mark.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Tuesday, June 20, 2006 9:52 PM
To: [EMAIL PROTECTED]
Subject: svn commit: r415681 - in
/incubator/harmony/enhanced/classlib/trunk/modules/auth:
build.xmlmake/build.xml make/common/ make/hyproperties.xml
Author: hindessm
Date: Tue Jun 20 07:52:28 2006
New Revision: 415681
URL: http://svn.apache.org/viewvc?rev=415681view=rev
Log:
Move auth build.xml up one level.
Added:
incubator/harmony/enhanced/classlib/trunk/modules/auth/build.xml
incubator/harmony/enhanced/classlib/trunk/modules/auth/make/hyproperties.xml
- copied unchanged from r415565,
incubator/harmony/enhanced/classlib/trunk/modules/auth/make/common/hyproperti
es.xml
Removed:
incubator/harmony/enhanced/classlib/trunk/modules/auth/make/build.xml
incubator/harmony/enhanced/classlib/trunk/modules/auth/make/common/
Added: incubator/harmony/enhanced/classlib/trunk/modules/auth/build.xml
URL:
http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/module
s/auth/build.xml?rev=415681view=auto
=
=
--- incubator/harmony/enhanced/classlib/trunk/modules/auth/build.xml (added)
+++ incubator/harmony/enhanced/classlib/trunk/modules/auth/build.xml Tue Jun
20 07:52:28 2006
@@ -0,0 +1,180 @@
+?xml version=1.0 encoding=ISO-8859-1?
+
+!--
+Copyright 2006 The Apache Software Foundation or its
+licensors, as applicable.
+
+Licensed under the Apache License, Version 2.0 (the License);
+you may not use this file except in compliance with the License.
+You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing, software
+distributed under the License is distributed on an AS IS BASIS,
+WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
implied.
+See the License for the specific language governing permissions and
+limitations under the License.
+--
+
+project name=AUTH Build default=build basedir=.
+descriptionBuild for AUTH component/description
+
+!-- import common properties --
+import file=${basedir}/../../make/properties.xml /
+
+!-- set global properties for this build. --
+xmlproperty file=make/hyproperties.xml semanticAttributes=true /
+
+!-- Set build.compiler to org.eclipse.jdt.core.JDTCompilerAdapter to
+ use the Eclipse Java compiler. --
+property name=build.compiler value=modern /
+
+property file=../../make/depends.properties /
+
+property name=hy.auth.src.main.java.platform
+ value=${hy.auth.src.main.java}/../${hy.os} /
+
+property name=hy.auth.src.test.java.platform
+ value=${hy.auth.src.test.java}/../${hy.os} /
+
+target name=build depends=compile.java, build.jar /
+
+target name=test depends=build, compile.tests, run.tests /
+
+target name=clean
+delete failonerror=false
+fileset dir=${hy.build}
+ includesfile=${hy.auth}/make/patternset.txt /
+fileset dir=${hy.auth.bin.test} /
+/delete
+/target
+
+target name=compile.java
+echo message=Compiling AUTH classes /
+
+mkdir dir=${hy.build} /
+
+javac sourcepath=
+ destdir=${hy.build}
+ source=${hy.javac.source}
+ target=${hy.javac.target}
+ debug=${hy.javac.debug}
+
+src
+pathelement location=${hy.auth.src.main.java}/
+pathelement location=${hy.auth.src.main.java.platform}
/
+/src
+
+bootclasspath
+fileset dir=${hy.jdk}/jre/lib/boot
+include name=**/*.jar /
+/fileset
+/bootclasspath
+/javac
+/target
+
+target name=build.jar
+jar destfile=${hy.jdk}/jre/lib/boot/${hy.auth.packaging.jarname
}.jar
+
Re: Eclipse Plug-in Dependencies not resolving
Nathan Beyer wrote: Was it just that the value of the Import-Package had a newline before the actual package names? I was just frustrated with myself that I couldn't figure it out. Well originally I thought it was, but actually when I looked at the manifest after Ant had put it into the JAR file, the new line after Import had been removed (and all the crazy line wrapping conducted), so that appears to be valid. The real problem was that Swing was missing a required java.lang.ref as an import, and AWT was not exporting it's org.apache.harmony.awt.* packages that were being imported by Swing. This mean that Swing and AWT would not resolve. Since our bundles have cyclical dependencies, and Swing and AWT would not resolve, therefore Beans (which requires AWT APIs), and Archive (which requires Beans APIs), and LUNI (which requires Archive APIs), and the rest of the world (that requires LUNI APIs) would also not resolve. The house of cards came tumbling down, and unfortunately figuring out the root cause in such cases is non-trivial with today's tools (I keep moaning to the Eclipse PDE guys about it, and things are gradually improving). To find this problem I (temporarily) added the full JRE library onto AWT build path so that it did not suffer from upstream resolution failures, then could fix AWT and Swing, and then it all worked again. I like how OSGi uses the manifest, but manifest file format is the most fragile thing I've ever dealt with; one wrong whitespace or extra character and BOOM. Yup -- and I think the tools could help better. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r415681 - in /incubator/harmony/enhanced/classlib/trunk/modules/auth: build.xml make/build.xml make/common/ make/hyproperties.xml
On 6/21/06, Mark Hindess wrote: On 21 June 2006 at 10:35, Stepan Mishura wrote: Hi Mark, I believe that 'move' means copying file with its revisions history. This can be done by 'svn move'. You did this for 'hyproperties.xml' file but not for 'build.xml' file. Why? Yes, it is possible to figure out from its initial revision (415681) what was the origin. But I prefer to have unbroken revisions history. I probably should have provided more information on the commit message. Sorry. The move (as discussed on the Simplifying... thread) actually took all but a few lines of _both_: make/common/build.xml, and make/common/build.xml Did you mean make/common/build.xml, and make/build.xml I don't believe there is a way to keep the history of both and keeping history of just one would probably have been equally confusing. Yes, you are right there is no such way. But I expected that make/common/build.xml would be the origin for module's build.xml. Happy to take suggestions on what you think I should have done. May be I missed something in the Simplifying... thread so I expected to see something like: 'svn move make/common/build.xml build.xml' + some edits in moved build.xml IMHO, it makes easer to track what was changed. Thanks, Stepan. Regards, Mark. 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: Pack200 -- can now obtain files stored in archive
Alex, Don't worry too much about the code being in the archive module, I agree that it makes sense to keep the Pack200 code separate so that it can be reused in Eclipse/Classpath/whatever and putting it into archive does not preclude that. The harmony archive component keeps it separated for access control reasons (based on people's prior access as declared in the contributor questionnaire) and for harmony corresponds to a packaging/modularity story (the code will go into archive.jar). As you know, you have a separate package space in archive (o.a.h.a.i.pack200) and there is no reason why that package (or any others that you need with that prefix) cannot be extracted, built and packaged separately for sharing. Obviously you have to continue to ensure that you implement with Java APIs that will be found elsewhere, and harmony will ensure that there is loose coupling into the pack200 implementation. So keep going! If you would prefer to see a separate target in the archive build.xml that produces just a pack200.jar then I'm sure that could be arranged too. Thanks for the continued contribution. Regards, Tim Alex Blewitt wrote: On 21/06/06, Stepan Mishura [EMAIL PROTECTED] wrote: On 6/21/06, Alex Blewitt wrote: We agreed to separate providers implementation [1]. But I'm not sure the same should be done for a concrete class implementation. In you case it is implementation of java.util.jar.Pack200 but there are lots of other cases ,for example, java.security.Policy. So we'll got a lot of modules with only one class inside. It's not just a concrete class, though. The API basically boils down to two methods: unpack() pack() The thing is, that an implementation of this JSR isn't just a simple class that provides a couple of methods. There's a lot of detail in the coding, decoding, and subsequent parsing that goes on. There's also a few other utilities that would be useful for performing compression on data streams if people would be interested in using them. So don't confuse a simple API with a simple solution :-) The providers/ would be exactly the right place for this kind of code to live (at least, for the implementation). There are stub classes that are needed in the archive/ module, such as java.util.jar.Packer along with the factory code to instantiate the provider; but the factory instantiating the provider is actually specified as part of the Packer's static access methods. Alex. - 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: Pack200 -- can now obtain files stored in archive
Alex Blewitt wrote: By the way, one of the tests has a Pack200 archive with Java classes in it, and one of the tests attempts to unpack that archive. With the recent change in 415891, it's possible that this test will fail now. Looks ok on the latest test results (for r415945). But then, I'm not sure whether the tests are being run ? Yes, the tests are being run. I see the following test counts: org.apache.harmony.archive.tests.internal.pack200 CodecTest = 6 SegmentOptionstest = 1 Segmenttest = 1 Regards, Tim If not, it's relatively easy to replace the HelloWorld.pack with a packed Jar file that just contains resources (e.g. GIFs, text files) to resolve the problem. Alex. On 20/06/06, Alex Blewitt [EMAIL PROTECTED] wrote: I've jumped ahead a bit on the pack200 archive, and written the unpacking for file data stored in a pack200 archive. The current implementation will barf if the file size is 2Gb, because I'm pulling all the data into a byte array at present (it's pretty memory hungry anyway). I've not got any output mechanisms coded yet, but performing a Segment.parse(in) on a pack200 will return you a Segment, and from there you can get the file_bits to reconstitute the data files. Should be relatively easy to export those into an appropriate output format at a later stage. If there's any classes in the pack file at the moment, it will fall over -- but that's because the format is organised as [constant pool, class/bytecode stuff, file data]. So if there'sno class/bytecode stuff, it just falls through to the file data afterwards. Obviously this isn't a particularly likely scenario (unless source files are stored in a Zip and then packed?) but at least it shows it's on the right track. The prior caveats still apply; it only works for un-Gzipped pack files (i.e. those created with --no-gzip) and there's no reconstitution of the goods at the other end. I'll probably spend some time on decoding the bytecode in the near future, but that will take some time. In other news, there was interest in getting the pack200 stuff under a dual licence so that it could be included in the Gnu Classpath libs too ... I'm open to that idea, as long as forking doesn't become an issue. I've also put some notes together in OPML as to the ordering of bands in a pack200 file in a separate harmony bug; not sure if it will make it into the SVN tree in a suitable location. I'd also like to suggest that we try to move the pack200 code out of the archive module into its own dedicated archive-pack200 module. If this code is to be reused in other environments (whether part of a classlib/J2SE implementation, or as a library/driver for other VMs) then it would be a good idea to separate out the implementation from the Java interfaces. After all, the standard Sun VM allows you to switch to a different pack200 provider using the java.util.jar.Pack200.Unpacker system property. It would probably not make sense for a provider to also have the remainder of the java.util.jar classes in there. Alex. - 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: [apps] azureus (was Re: [testing] AWT, Swing Java2D)
Thorbjørn Ravn Andersen wrote: Stefano Mazzocchi skrev den 20-06-2006 19:21: If you guys write a little how to on the wiki on how to build the thing from scratch on linux from sources, I'll be happy to try azureus on harmony with some 10Gb torrent files and report back on the wiki. I did that recently with the IBM JVM, (see http://www.mail-archive.com/harmony-dev@incubator.apache.org/msg08346.html) but those instructions check out the whole Harmony SVN tree, and I believe that a newer version of the IBM JVM is necessary. If you mentally rewrite those to deal with the harmony/enhanced/classlib subdirectory instead, you should be able to get it up and running. I left it there since apparently I was the only one needing such instructions :) As it appears not to, I'd be happy to shape it up for submission. The build instructions are here [1], let me know if they need updating. For example, I think they may need to catch up with the build.xml file movement that took place yesterday. [1] http://incubator.apache.org/harmony/subcomponents/classlibrary/build_classlib.html 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: [apps] azureus (was Re: [testing] AWT, Swing Java2D)
I've tried to run Azureus on Windows XP from NAT-ed network - with RI it worked fine, with Harmony (classlib revision 415631) an error appeared: 'Too many successive failures occured on port 55255, UDP - processing abandoned. Please check firewall settings for this port to ensure that it is enabled for receiving connections' -- 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: [Fwd: [classlib][NIO|VMI]Interruptible channel implementation - how to interact with Thread?]
(switching charset encoding) Paulex Yang wrote: Archie Cobbs wrote: Paulex Yang wrote: OK, this is nice and simple.. installing an interrupt action is a clean and Java-centric way to make the handling of interrupts explicit. It may be technically unnecessary (if POSIX signals were available) but has the advantage of being less tied to the O/S and VM internals. Great, so may I assume you agree with the VMI modification to add Thread.setInterruptAction()? Yes, looks good. Great! So if no one objects, I will raise JIRA and provide the patch for AbstractInterruptibleChannel, but I have no idea how to patch the VMI/kernel class(any committer kindly help?). Good to watch this get worked out. Paulex, I suggest that you submit a patch for: - AbstractInterruptibleChannel - kernel-luni's Thread stubs - the VMI documentation It will require a tweak to the various VMs/adapter to get that patch supported. Once you raise the JIRA perhaps we can point to it from a new mail thread and discuss its application. 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: [Fwd: [classlib][NIO|VMI]Interruptible channel implementation - how to interact with Thread?]
Tim Ellison wrote: (switching charset encoding) Paulex Yang wrote: Archie Cobbs wrote: Paulex Yang wrote: OK, this is nice and simple.. installing an interrupt action is a clean and Java-centric way to make the handling of interrupts explicit. It may be technically unnecessary (if POSIX signals were available) but has the advantage of being less tied to the O/S and VM internals. Great, so may I assume you agree with the VMI modification to add Thread.setInterruptAction()? Yes, looks good. Great! So if no one objects, I will raise JIRA and provide the patch for AbstractInterruptibleChannel, but I have no idea how to patch the VMI/kernel class(any committer kindly help?). Good to watch this get worked out. Paulex, I suggest that you submit a patch for: - AbstractInterruptibleChannel - kernel-luni's Thread stubs - the VMI documentation It will require a tweak to the various VMs/adapter to get that patch supported. Once you raise the JIRA perhaps we can point to it from a new mail thread and discuss its application. Thank you very much for your suggestion, Tim. I've raised Harmony-635 for this issue. Regards, Tim -- Paulex Yang China Software Development Lab IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib]native codes layout question(was Re: [classlib][NIO|VMI]JNI 1.4 enhancement on ByteBuffer)
Hi Jimmy, LvJimmy，Jing wrote: Hi Oliver: I've seen the modularisation on native, that's great! :) But I have a question here. As I work on native before, I usually build the whole native code once, and then make seperate modules alone, e.g., luni, or nio. It was easy to enter directory luni and force build by make and create a new DLL/so file. In this way it is easy to write codes and debug. However after modularisation nowadays, as there are envionment variables in the makefile, which are defined in the build.xml, I have no idea but build whole native with ant, even after changing a single line. So I turn to help for if there's an easy way to build single module alone? Thanks! If you want to rebuild all the natives in one go, you can still (currently) go to the native-src directory and run ant. This will rebuild all the native components. Rebuilding a single component can also be done. For example, to rebuild the hyluni.dll you would: 1. cd to native-src/platform/luni 2. set the HY_HDK environment variable to point to a directory where you have a complete prebuilt HDK (which could be the deploy dir if you have previously run a global build). 3. Run make/nmake. The hyluni.dll will be built against the libs already in HY_HDK, and the generated dll will be placed into the native-src/platform directory, where you can then copy it wherever you want Once the natives are all modularised (so native-src no longer exists) you will be able to just go to the module you want and run ant build.native (or some similarly name target) and the natives will be incrementally rebuilt and automatically placed into your target directory. Hope this helps, Oliver at 06-6-20，Oliver Deakin [EMAIL PROTECTED] wrote： Paulex Yang wrote: Seems no one objects this proposal:), so I'm going to implement the JNI1.4 enhancement in nio module, i.e, provide patch to Harmony-578, Because this implementation requires some native codes, so I probably need to reintroduce hynio.dll(.so), but I have some questions.(Excuse me about my ignorance on the native layout evolution). At first, seems native codes will be separated into modules(I guess Oli is working on?), so should I assume my native codes will be directly put into nio modules, or still in native-src/win.IA32/nio directory? because I'm used to provide a shell to move/svn add new files in the patch, so it will be easier for me to know how others think about it. It depends on whether you want to wait for what I'm doing or not :) If you want to get the code out now, then you can temporarily put it under native-src/win.IA32/nio and I will move it later as part of the natives modularisation. However, if you don't mind waiting a day or so I should be able to submit my first patch to move the prefs natives. This ought to be enough of an example for you to put your native code directly into modules/nio/src/main/native. And second, the native codes probably need portlib, so the portlib's header file must be accessible, say, portsock.h, but now it has been moved into luni/src/main/native/blabla, should I include one in my patch so that nio module can have a copy? or the header file itself should be put some other well known directory(deploy/build/include I guess)? At build time, the copy.native.includes target in luni/make/build.xml is called - it copies a selection of the header files in luni/src/main/native/include that need to be shared between modules into the deploy/include directory. This is done with an explicit fileset in luni/make/build.xml - if you need to have portsock.h added to the list of shared header files, then this is the place to make that change. Just add its filename to the list, and next time you build it will appear in the deploy/include directory. Your nio code should include the headers from the deploy/include dir, and *not* directly from the luni/src/main/native/include dir. I hope this makes more sense now - if it doesn't, please let me know. I am in the process of writing up some documentation for the website on the natives layout and where headers should go (and also how modules should build against the HDK) - once that is complete it should all be a lot clearer. Regards, Oliver -- Oliver Deakin IBM United Kingdom Limited - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- 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]native codes layout question(was Re: [classlib][NIO|VMI]JNI 1.4 enhancement on ByteBuffer)
Oliver Deakin wrote: Rebuilding a single component can also be done. For example, to rebuild the hyluni.dll you would: 1. cd to native-src/platform/luni 2. set the HY_HDK environment variable to point to a directory where you have a complete prebuilt HDK (which could be the deploy dir if you have previously run a global build). Can we have it set to the deploy dir by default? 3. Run make/nmake. The hyluni.dll will be built against the libs already in HY_HDK, and the generated dll will be placed into the native-src/platform directory, where you can then copy it wherever you want Once the natives are all modularised (so native-src no longer exists) you will be able to just go to the module you want and run ant build.native (or some similarly name target) and the natives will be incrementally rebuilt and automatically placed into your target directory. This is the mode of working that people should get used to, so that if/when we have ./configure steps too they will still build the natives the same way (i.e. rather than just typing (n)make). Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib]native codes layout question(was Re: [classlib][NIO|VMI]JNI 1.4 enhancement on ByteBuffer)
Tim Ellison wrote: Oliver Deakin wrote: Rebuilding a single component can also be done. For example, to rebuild the hyluni.dll you would: 1. cd to native-src/platform/luni 2. set the HY_HDK environment variable to point to a directory where you have a complete prebuilt HDK (which could be the deploy dir if you have previously run a global build). Can we have it set to the deploy dir by default? This is only a temporary step while the natives are still in native-src. Once all the native code is moved into the modules the default will be the deploy directory. In fact, if you go to the prefs module and type in Ant build.native it will build the prefs native code and place the output libs into the deploy directory. (ok, that's not strictly true - you need to use Ant -Dmake.command=nmake build.native because the modular scripts dont pick up this variable from /make/properties.xml yet, but this will be fixed in the future.) 3. Run make/nmake. The hyluni.dll will be built against the libs already in HY_HDK, and the generated dll will be placed into the native-src/platform directory, where you can then copy it wherever you want Once the natives are all modularised (so native-src no longer exists) you will be able to just go to the module you want and run ant build.native (or some similarly name target) and the natives will be incrementally rebuilt and automatically placed into your target directory. This is the mode of working that people should get used to, so that if/when we have ./configure steps too they will still build the natives the same way (i.e. rather than just typing (n)make). Agreed Regards, Oliver Regards, Tim -- 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: [drlvm] what's next?
2006/6/21, Weldon Washburn [EMAIL PROTECTED]: On 6/20/06, Gregory Shimansky [EMAIL PROTECTED] wrote: On Tuesday 20 June 2006 19:44 Salikh Zakirov wrote: Geir Magnusson Jr wrote: Build and dependency issues aside, what are the next functional enhancements / features for DRLVM? I think #1 is to get it to function with Java 5 classfiles, so we can make the switch throughout the project. Thoughts? What else? As far as I can tell, general DRLVM development directions are * more features, e.g. JVMTI I am also trying to improve the current JVMTI support which works on interpreter only at the moment. I am trying to prepare a patch with implementation of some debugging functions for JIT mode. It should contain stack trace group of functions, exception, method enter/exit events and breakpoints using int3 trap in the compiled code. Excellent. Will it work with Jitrino.JET? Yes it will work with Jitrino.JET and for now only wirh it. This is done because compilation optimizations may lose exact bytecode and local variables mapping which are required for debugging. If JVMTI is enabled on the command line only Jitrino.JET will be enabled automatically. It would be great if this debugger could be used during the port of MMTk. You can also encounter bugs which happen because of not really well tested code of debugger interferes into exeuction of GC :) -- Gregory Shimansky, Intel Middleware Products Division
Re: [general] milestones and roadmap
Lots of good ideas expressed already. I'll add : - get some of the principal JDK tools in place - expand the committer gene pool - graduate from incubator Regards, Tim Geir Magnusson Jr wrote: I'd like to start assembling a high-level roadmap of the milestones we'd like to achieve in the next 12 months. I volunteer to track and organize, but this clearly is a community activity so lets start by just tossing out ideas. 1) By ApcheCon EU - a combined snapshot that is a pure open source VM + classlib. Issues - I assume we'll use DRLVM. 2) Integration of Doug Lea's java.util.concurrency package. Issues - right now, Nathan is looking at it, and we'll need support from the various VMs. 3) Build framework - I'm hoping Mark/IBM is able to get us booted on this via a contribution to /testing that makes it easy for people to do the same CI runs that he's doing 4) Incorporate the Java SE TCK into build framework. This requires a few things, first the build framework and people interested in working on that, and second, the Java SE TCK. I'm working on the latter in my role as the ASFs JCP rep, and I'm guessing this will take a while. 5) Switch to Java 5 - in both classlib and our VMs 6) CORBA - start looking at Yoko to see what we can reuse for Harmony, and start integrating that. 7) Test coverage - should we think about targets for test coverage ? 8) Package completion roadmap 9) JMX - right now, I believe mark has finished integrating MX4J, but we need to start enhancing that with Java 5 features. What else? :) 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. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Fwd: [classlib][NIO|VMI]Interruptible channel implementation - how to interact with Thread?]
Paulex Yang wrote: I'm still curious what mechanism will be used to wakeup blocked threads though. And when Thread.interrupt() executes the interruptAction and closes the channel, generally the blocking I/O operation will return with an error code, and if Harmony user implements a subclass of AbstractInterruptibleChannel, he is required by spec to implement implCloseChannel(which is invoked by close()) in similar way, in both cases, the thread is waken up as by product. The blocking select is waken up in similar way by invoke wakeup() in interruptAction. Thanks.. for the other cases.. e.g. a thread blocked in Object.wait(), Thread.join(), or Thread.sleep(), I guess they will require an interrupt action which invokes a native method (equivalent to the current situation), right? I.e., these cases would be handled entirely by the VM. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][vm] Prerequisites for java.util.concurrent
On 6/18/06, Nathan Beyer [EMAIL PROTECTED] wrote: Thanks. How does the Atomics class work in regards to volatile reads of elements of an array? Here's the class I'm looking at implementing with the Atomics API [1]. The CAS operations are trivial. It's the 'get' and 'set' methods that I'm trying to figure out. Hi Nathan, Atomics in drlvm has a function MemoryReadWriteBarrier() defined in atomics.h (see http://svn.apache.org/viewvc/incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/include/atomics.h) which can be utilized for implementing volatile reads and writes for AtomicIntegerArray. Some work, however, will still be needed for atomics.cpp to add volatile set() and get() implementations accessible through JNI interface. Another approach to implement AtomicArray.get and set could be via CAS operation. For example, for set() method, you simply can do something like: int orig = arr[i]; // guess original master value compareAndSet(i, orig, newValue); // set new value; if the original value is unexpected, it would just mean that someone else has changed it concurrently which is OK for this case and we just do nothing; For get() method, algorithm could be like: int orig = arr[i]; compareAndSet(i, 0, 0); // do CAS with whatever value, this ensures cache is flushed; return arr[i]; // return the master value In terms of the speed, it must be almost same as doing mfense, at least on IA32 (mfense is probably 20-30% faster). Thank you, Andrey Chernyshev Intel Middleware Products Division -Nathan [1] http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/main/java/util/concu rrent/atomic/AtomicIntegerArray.java?rev=1.19only_with_tag=JSR166_PFDconte nt-type=text/vnd.viewcvs-markup -Original Message- From: Artem Aliev [mailto:[EMAIL PROTECTED] Sent: Friday, June 16, 2006 6:52 AM To: harmony-dev@incubator.apache.org Subject: Re: [classlib][vm] Prerequisites for java.util.concurrent Nathan, VMI Atomicity/Lock API - All of the AtomicXXX classes are delegated to a VM-specific API for atomic gets and sets. This API will need to be defined and then implemented by the various VMs. Many of the lock APIs also make use of this API. I have done some experiments with concurrent in DRLVM. So there are two kernel classes in the DRLVM that, probably, provide full set of VM dependent functionality required by util.concurrent. Both have special VM support. vm/vmcore/src/kernel_classes/javasrc/java/util/concurrent/locks/LockSuppor t.java -- park/unpark methods The special queue could be used in case you need to implement it in VM independent way. vm/vmcore/src/kernel_classes/javasrc/org/apache/harmony/util/concurrent/At omics.java -- CAS operations on references, ints, longs etc. The methods are aware of internal object layout and reference format. VM independent implementation could be done base on java monitors, but it kills the idea of the util.concurrent. Thanks Artem Aliev Intel Middleware Product Division On 6/14/06, Nathan Beyer [EMAIL PROTECTED] wrote: I stubbed out the method in luni-kernel (as well as two other methods that were missing). I looked at DRLVM and it already has nanoTime implementation, but it's not using the method you mentioned. I took a peek at the JCHEVM/classlibadaptar, but I couldn't quite discern the various artifacts. -Nathan -Original Message- From: Tim Ellison [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 13, 2006 6:34 AM To: harmony-dev@incubator.apache.org Subject: Re: [classlib][vm] Prerequisites for java.util.concurrent Nathan Beyer wrote: snip Does this mean we can stub out the luni-kernel System and just get the VMs to implement it in their kernel classes using this method? That's what I was thinking, and we can implement it in the luni-kernel / classpathadapter as a reference for VMs if we so choose. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - 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: r415979 - in /incubator/harmony/enhanced/drlvm/trunk/build/make: lnx.properties win.properties
huh? Are you sure this isn't your proxy or something? http works fine for me. I think that you should fix your proxy and reverse this when fixed. geir [EMAIL PROTECTED] wrote: Author: hindessm Date: Wed Jun 21 05:50:15 2006 New Revision: 415979 URL: http://svn.apache.org/viewvc?rev=415979view=rev Log: SVN checkout over http seems to be failing, but https works. Modified: incubator/harmony/enhanced/drlvm/trunk/build/make/lnx.properties incubator/harmony/enhanced/drlvm/trunk/build/make/win.properties Modified: incubator/harmony/enhanced/drlvm/trunk/build/make/lnx.properties URL: http://svn.apache.org/viewvc/incubator/harmony/enhanced/drlvm/trunk/build/make/lnx.properties?rev=415979r1=415978r2=415979view=diff == --- incubator/harmony/enhanced/drlvm/trunk/build/make/lnx.properties (original) +++ incubator/harmony/enhanced/drlvm/trunk/build/make/lnx.properties Wed Jun 21 05:50:15 2006 @@ -65,7 +65,7 @@ # LOG4CXX, svn revision 365029 # http://logging.apache.org/site/cvs-repositories.html -remote.LOG4CXX.archive=-r 365029 http://svn.apache.org/repos/asf/logging/log4cxx/trunk +remote.LOG4CXX.archive=-r 365029 https://svn.apache.org/repos/asf/logging/log4cxx/trunk remote.LOG4CXX.archive.type=svn # IJ Eclipse plugin Modified: incubator/harmony/enhanced/drlvm/trunk/build/make/win.properties URL: http://svn.apache.org/viewvc/incubator/harmony/enhanced/drlvm/trunk/build/make/win.properties?rev=415979r1=415978r2=415979view=diff == --- incubator/harmony/enhanced/drlvm/trunk/build/make/win.properties (original) +++ incubator/harmony/enhanced/drlvm/trunk/build/make/win.properties Wed Jun 21 05:50:15 2006 @@ -68,7 +68,7 @@ remote.APRICONV.archive=http://apache.reverse.net/pub/apache/apr/apr-iconv-1.1.1-win32-src.zip # LOG4CXX, svn revision 365029 -remote.LOG4CXX.archive=-r 365029 http://svn.apache.org/repos/asf/logging/log4cxx/trunk +remote.LOG4CXX.archive=-r 365029 https://svn.apache.org/repos/asf/logging/log4cxx/trunk remote.LOG4CXX.archive.type=svn # IJ Eclipse plugin - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[drlvm] Help building on Windows!
Hi all, I'm trying to build drlvm, and with a small amount of effort Ive got its prereqs and got it to start building, which is great. However, I hit a snag which stops the build from completing (8 mins in, sigh): build.native.init: [echo] ## Building native of 'vm.vmi' build.native.c: [cc] 0 total files to be compiled. build.native.cpp: [cc] 2 total files to be compiled. [cc] j9vmls.cpp [cc] C:\Program Files\eclipse.3.2.RC1a\workspace\drlvm\trunk\vm\vmi\src\j9 vmls.cpp(20) : fatal error C1083: Cannot open include file: 'hyvmls.h': No such file or directory [cc] vmi.cpp [cc] C:\Program Files\eclipse.3.2.RC1a\workspace\drlvm\trunk\vm\vmi\src\vm i.cpp(25) : fatal error C1083: Cannot open include file: 'zipsup.h': No such fil e or directory [cc] Generating Code... BUILD FAILED C:\PROGRA~1\eclipse.3.2.RC1a\workspace\drlvm\trunk\build\make\build.xml:373: The following error occurred while executing this line: C:\PROGRA~1\eclipse.3.2.RC1a\workspace\drlvm\trunk\build\make\build.xml:380: The following error occurred while executing this line: C:\PROGRA~1\eclipse.3.2.RC1a\workspace\drlvm\trunk\build\make\build_component.xml :72: The following error occurred while executing this line: C:\PROGRA~1\eclipse.3.2.RC1a\workspace\drlvm\trunk\build\win_ia32_msvc_release\se mis\build\targets\build.native.xml:75: cl failed with return code 2 Total time: 7 minutes 50 seconds It looks like the build cannot find the classlib header files it needs. Unfortunately the error messages are unhelpful in that they don't tell me anything about the include paths used. I have set the CLASSLIB_HOME variable in make/win.properties to point to a prebuilt classlib/trunk checkout. Is there something else I need to set? Thanks, Oliver -- Oliver Deakin IBM United Kingdom Limited - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [drlvm] Help building on Windows!
Since I'm responsible for current config, I'll take a look. Maybe osmething changed because of the classlib structure changes geir -- Geir Magnusson Jr SSG/MPD [EMAIL PROTECTED] +1 203 665 6437 -Original Message- From: Oliver Deakin [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 21, 2006 11:10 AM To: harmony-dev@incubator.apache.org Subject: [drlvm] Help building on Windows! Hi all, I'm trying to build drlvm, and with a small amount of effort Ive got its prereqs and got it to start building, which is great. However, I hit a snag which stops the build from completing (8 mins in, sigh): build.native.init: [echo] ## Building native of 'vm.vmi' build.native.c: [cc] 0 total files to be compiled. build.native.cpp: [cc] 2 total files to be compiled. [cc] j9vmls.cpp [cc] C:\Program Files\eclipse.3.2.RC1a\workspace\drlvm\trunk\vm\vmi\src\j9 vmls.cpp(20) : fatal error C1083: Cannot open include file: 'hyvmls.h': No such file or directory [cc] vmi.cpp [cc] C:\Program Files\eclipse.3.2.RC1a\workspace\drlvm\trunk\vm\vmi\src\vm i.cpp(25) : fatal error C1083: Cannot open include file: 'zipsup.h': No such fil e or directory [cc] Generating Code... BUILD FAILED C:\PROGRA~1\eclipse.3.2.RC1a\workspace\drlvm\trunk\build\make\ build.xml:373: The following error occurred while executing this line: C:\PROGRA~1\eclipse.3.2.RC1a\workspace\drlvm\trunk\build\make\ build.xml:380: The following error occurred while executing this line: C:\PROGRA~1\eclipse.3.2.RC1a\workspace\drlvm\trunk\build\make\ build_component.xml :72: The following error occurred while executing this line: C:\PROGRA~1\eclipse.3.2.RC1a\workspace\drlvm\trunk\build\win_i a32_msvc_release\se mis\build\targets\build.native.xml:75: cl failed with return code 2 Total time: 7 minutes 50 seconds It looks like the build cannot find the classlib header files it needs. Unfortunately the error messages are unhelpful in that they don't tell me anything about the include paths used. I have set the CLASSLIB_HOME variable in make/win.properties to point to a prebuilt classlib/trunk checkout. Is there something else I need to set? Thanks, Oliver -- Oliver Deakin IBM United Kingdom Limited - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - 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] Help building on Windows!
I just did a svn update, build.bat clean, and build.bat and it ran to completion. Tests worked too. svn stat from /trunk shows nothing not checked in.. Are you building against classlib as it is in SVN, or something that you've been working on? Also, it assumes you already build classlib. maybe... - right now, it assumes that drlvm and classlib are in parallel directories. You can adjust via the external.deps.CLASSLIB property in build.xml geir Magnusson, Geir wrote: Since I'm responsible for current config, I'll take a look. Maybe osmething changed because of the classlib structure changes geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] what's next?
On 6/21/06, Gregory Shimansky [EMAIL PROTECTED] wrote: Yes it will work with Jitrino.JET and for now only wirh it. This is done because compilation optimizations may lose exact bytecode and local variables mapping which are required for debugging. If JVMTI is enabled on the command line only Jitrino.JET will be enabled automatically. Perfect timing! It may be easier for unoptimized code but ties in really nicely with the proposed MMTk and WB work around .Jet etc. You can also encounter bugs which happen because of not really well tested code of debugger interferes into exeuction of GC :) No worries, we will then use your debugger to debug its own problems :-)
Re: [classlib] More build file simplification
--- Mark Hindess [EMAIL PROTECTED] wrote:
On 21 June 2006 at 13:10, Mikhail Loenko
[EMAIL PROTECTED] wrote:
how to run tests from two modules and get a single
report?
ant -Dbuild.module=luni test; ant -Dbuild.module=nio
test
patches welcome ;-) Tricky without the ant for/if
extensions I think.
Au contraire... the following test snippet should give
you an example to help:
project
fail unless=build.module /
property name=module.dir location=modules /
subant
dirset dir=${module.dir}
includes=${build.module} /
/subant
/project
i.e., 'ant -Dbuild.module=luni,nio,math'
-Matt
Regards,
Mark
-
Terms of use :
http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [classlib] Help wanted!
I've been hacking away at those warnings every chance I get. The 'luni' module is going to be filled warnings until we can begin using annotations, specifically the @SuppressWarning, especially the Collections classes. There are a number of cases where unchecked type uses are a requirement because of limitations in current APIs, backwards compatability and generic array construction. Here are some of the major pieces that can't be avoided and need suppressing annotations: * Cloning - When you clone a generified object you have no choice but to do an unchecked cast. * Generic Array Construction - The only thing you can do is T[] = (T[])new Object[size]; and suppress the warning. In any case, I'm all for keep this stuff as clean as possible. I have my Eclipse compiler settings cranked to the max in the IDE. -Nathan -Original Message- From: Mark Hindess [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 21, 2006 12:49 AM To: Apache Harmony Dev List Subject: [classlib] Help wanted! I was looking at building (and testing) with Eclipse + IBM VME. I think this is really important since ecj has a much cleaner classpath when it compiles so it helps us find errors quicker. The logs come out at over 3MB! There are lots of warnings about less than ideal type checking - mostly as a result of our adoption of more generics. For example: [javac] 1. WARNING in /pbuilder/tmp/Harmony.my/modules/accessibility/src/mai n/java/javax/accessibility/AccessibleRelationSet.java [javac] (at line 44) [javac] relations.add(relation); [javac] ^^^ [javac] Type safety: The method add(Object) belongs to the raw type Vector. References to generic type VectorE should be parameterized [javac] -- [javac] 2. WARNING in /pbuilder/tmp/Harmony.my/modules/accessibility/src/mai n/java/javax/accessibility/AccessibleRelationSet.java [javac] (at line 88) [javac] (AccessibleRelation[])relations.toArray(new AccessibleRelation[r elations.size()]); [javac] ^^ ^ [javac] Type safety: The method toArray(Object[]) belongs to the raw type Ve ctor. References to generic type VectorE should be parameterized I think we should try to improve these, but there are rather too many for me to do on my own! What do others think? I think we could disable the warnings from Eclipse but I don't think that's really the right thing to do. The distribution of warnings is as follows: 4 accessibility 24 archive 90 auth 707 awt 61 beans 7 crypto 128 jndi 206 luni 10 luni-kernel 4 misc 8 nio 7 nio_char 32 prefs 17 regex 260 rmi 568 security 936 swing 26 text 14 x-net Regards, Mark. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] More build file simplification
On 21 June 2006 at 10:24, Matt Benson [EMAIL PROTECTED] wrote:
--- Mark Hindess [EMAIL PROTECTED] wrote:
On 21 June 2006 at 13:10, Mikhail Loenko
[EMAIL PROTECTED] wrote:
how to run tests from two modules and get a single
report?
ant -Dbuild.module=luni test; ant -Dbuild.module=nio
test
patches welcome ;-) Tricky without the ant for/if
extensions I think.
Au contraire... the following test snippet should give
you an example to help:
project
fail unless=build.module /
property name=module.dir location=modules /
subant
dirset dir=${module.dir}
includes=${build.module} /
/subant
/project
i.e., 'ant -Dbuild.module=luni,nio,math'
Matt,
Thanks for the ant lesson (again!). That's is very helpful!
Mikhail,
Testing works as we'd like now and we don't have to maintain multiple
targets.
Regards,
Mark.
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [apps] azureus (was Re: [testing] AWT, Swing Java2D)
Tim Ellison skrev den 21-06-2006 11:58: The build instructions are here [1], let me know if they need updating. Just got around to update and check. The reference to the build.xml file in the help text shown if the dependencies have not been downloaded does not reflect that it now is ant -f make/depends.xml download instead. For example, I think they may need to catch up with the build.xml file movement that took place yesterday. [1] http://incubator.apache.org/harmony/subcomponents/classlibrary/build_classlib.html While it is building I would like to mention that the primary reason why I did what I did was to see if it was necessary at all to download Sun's JDK (to get tools.jar) to build on Ubuntu. It isn't - by downloading ecj and telling ant to use it - you can get by just with a JRE or a clone like gcj (or perhaps kaffe), which is available in the default repositories. Personally I like this approach the best :) -- Thorbjørn smime.p7s Description: S/MIME Cryptographic Signature
Re: [drlvm] Help building on Windows!
Thanks Geir - setting external.dep.CLASSLIB did the job. So, in summary for those interested, to build drlvm against a prebuilt classlib/trunk in any location you need to change: - the value of CLASSLIB_HOME in make/win.properties - the value of external.dep.CLASSLIB in build/make/build.xml so they both point to the root dir of the classlib/trunk checkout. Regards, Oliver Geir Magnusson Jr wrote: I just did a svn update, build.bat clean, and build.bat and it ran to completion. Tests worked too. svn stat from /trunk shows nothing not checked in.. Are you building against classlib as it is in SVN, or something that you've been working on? Also, it assumes you already build classlib. maybe... - right now, it assumes that drlvm and classlib are in parallel directories. You can adjust via the external.deps.CLASSLIB property in build.xml geir Magnusson, Geir wrote: Since I'm responsible for current config, I'll take a look. Maybe osmething changed because of the classlib structure changes geir - 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: [apps] azureus (was Re: [testing] AWT, Swing Java2D)
On 21 June 2006 at 19:51, =?ISO-8859-1?Q?Thorbj=F8rn_Ravn_Andersen?= [EMAIL PROTECTED] wrote: Tim Ellison skrev den 21-06-2006 11:58: The build instructions are here [1], let me know if they need updating. Just got around to update and check. The reference to the build.xml file in the help text shown if the dependencies have not been downloaded does not reflect that it now is ant -f make/depends.xml download instead. D'oh. Geir changed it from ant -f depends.xml download just a few days ago! It was the right thing to do at the time. I've now changed it to ant fetch-depends. -Mark. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] More build file simplification
--- Mark Hindess [EMAIL PROTECTED] wrote: [SNIP] Matt, Thanks for the ant lesson (again!). That's is very helpful! Aw... that's what I'm here for, since I can't make a _real_ contribution. :) -Matt Mikhail, Testing works as we'd like now and we don't have to maintain multiple targets. Regards, Mark. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] Help building on Windows!
You can always take a look at what command lines build calls C compiler if you call build.bat with -d switch (it is just passed to ant). I am not sure if it is the case but could it be spaces in the path like Documents and Settings? On Wednesday 21 June 2006 19:09 Oliver Deakin wrote: Hi all, I'm trying to build drlvm, and with a small amount of effort Ive got its prereqs and got it to start building, which is great. However, I hit a snag which stops the build from completing (8 mins in, sigh): build.native.init: [echo] ## Building native of 'vm.vmi' build.native.c: [cc] 0 total files to be compiled. build.native.cpp: [cc] 2 total files to be compiled. [cc] j9vmls.cpp [cc] C:\Program Files\eclipse.3.2.RC1a\workspace\drlvm\trunk\vm\vmi\src\j9 vmls.cpp(20) : fatal error C1083: Cannot open include file: 'hyvmls.h': No such file or directory [cc] vmi.cpp [cc] C:\Program Files\eclipse.3.2.RC1a\workspace\drlvm\trunk\vm\vmi\src\vm i.cpp(25) : fatal error C1083: Cannot open include file: 'zipsup.h': No such fil e or directory [cc] Generating Code... BUILD FAILED C:\PROGRA~1\eclipse.3.2.RC1a\workspace\drlvm\trunk\build\make\build.xml:373 : The following error occurred while executing this line: C:\PROGRA~1\eclipse.3.2.RC1a\workspace\drlvm\trunk\build\make\build.xml:380 : The following error occurred while executing this line: C:\PROGRA~1\eclipse.3.2.RC1a\workspace\drlvm\trunk\build\make\build_compone nt.xml :72: The following error occurred while executing this line: C:\PROGRA~1\eclipse.3.2.RC1a\workspace\drlvm\trunk\build\win_ia32_msvc_rele ase\se mis\build\targets\build.native.xml:75: cl failed with return code 2 Total time: 7 minutes 50 seconds It looks like the build cannot find the classlib header files it needs. Unfortunately the error messages are unhelpful in that they don't tell me anything about the include paths used. I have set the CLASSLIB_HOME variable in make/win.properties to point to a prebuilt classlib/trunk checkout. Is there something else I need to set? Thanks, Oliver -- 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] Help building on Windows!
The one in win.properties is probably irrelevant. It's my intention to just remove that, and I guess now is as good as a time as any. I'll also update the readme. Sorry - I should have done that. Geir -- Geir Magnusson Jr SSG/MPD [EMAIL PROTECTED] +1 203 665 6437 -Original Message- From: Oliver Deakin [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 21, 2006 2:23 PM To: harmony-dev@incubator.apache.org Subject: Re: [drlvm] Help building on Windows! Thanks Geir - setting external.dep.CLASSLIB did the job. So, in summary for those interested, to build drlvm against a prebuilt classlib/trunk in any location you need to change: - the value of CLASSLIB_HOME in make/win.properties - the value of external.dep.CLASSLIB in build/make/build.xml so they both point to the root dir of the classlib/trunk checkout. Regards, Oliver Geir Magnusson Jr wrote: I just did a svn update, build.bat clean, and build.bat and it ran to completion. Tests worked too. svn stat from /trunk shows nothing not checked in.. Are you building against classlib as it is in SVN, or something that you've been working on? Also, it assumes you already build classlib. maybe... - right now, it assumes that drlvm and classlib are in parallel directories. You can adjust via the external.deps.CLASSLIB property in build.xml geir Magnusson, Geir wrote: Since I'm responsible for current config, I'll take a look. Maybe osmething changed because of the classlib structure changes geir - 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] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Created: (HARMONY-638) [classlib] Tests hang on in luni : tests.api.java.io.FileTest / test_setReadOnly on Ubunti 6.06
I remember seeing problems like this before, in a non-Harmony jre, where a Runtime.exec() would never return. I hunted around and found an interesting page on JavaWorld: http://www.javaworld.com/javaworld/jw-12-2000/jw-1229-traps.html I found the Why Runtime.exec() hangs section very useful, and it solved my problem at the time. I'm not saying that what you're seeing is definitely the same thing that I encountered, but it may help. I notice that in this test stdout and stderr for the process are not read - is it possible that it is producing some output, and since it isn't being read the process just waits leading to the exec never exiting? Regards, Oliver Geir Magnusson Jr (JIRA) wrote: [classlib] Tests hang on in luni : tests.api.java.io.FileTest / test_setReadOnly on Ubunti 6.06 --- Key: HARMONY-638 URL: http://issues.apache.org/jira/browse/HARMONY-638 Project: Harmony Type: Bug Components: Classlib Reporter: Geir Magnusson Jr it seems that exec() doesn't work - it never returns. Bug in IBM j9 kernel classes? Mark Hindress is trying to duplcate to reconfirm. ubuntu 6.06 gcc 3.4 invoked by Sun Java 1.5.0_07 IBM J9 for linux, v3 mk II -- 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] More build file simplification
Mark Hindess wrote: 9) Separate exclude lists. Ongoing resurrecting HARMONY-263. If this is the one I'm thinking of, and I recall correctly, I'm opposed to further weaving JUnit dependencies into our infrastructure. I would assume that we should be able to easily manage the include/exclude lists all from w/in Ant... I'll re-read and post more thoughts later. geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] More build file simplification
Mark Hindess wrote: And a quick update on the other items... 1) Moved build.xml up to top-level. Add targets to make top-level *the* top-level API for developers. I also added a 'help' target with brief usage information. Done. Well almost. You can do: For the record, I really am happy to see this back. It's such a pleasure. [SNIP] 5) Convert XML properties to text. Not sure this is as easy as I first thought. Why? Maybe someone has an idea... 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] More build file simplification
That was a real one. Keep them coming. geir Matt Benson wrote: --- Mark Hindess [EMAIL PROTECTED] wrote: [SNIP] Matt, Thanks for the ant lesson (again!). That's is very helpful! Aw... that's what I'm here for, since I can't make a _real_ contribution. :) -Matt Mikhail, Testing works as we'd like now and we don't have to maintain multiple targets. Regards, Mark. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Created: (HARMONY-638) [classlib] Tests hang on in luni : tests.api.java.io.FileTest / test_setReadOnly on Ubunti 6.06
Oliver Deakin wrote: I remember seeing problems like this before, in a non-Harmony jre, where a Runtime.exec() would never return. I hunted around and found an interesting page on JavaWorld: http://www.javaworld.com/javaworld/jw-12-2000/jw-1229-traps.html I found the Why Runtime.exec() hangs section very useful, and it solved my problem at the time. I'm not saying that what you're seeing is definitely the same thing that I encountered, but it may help. I notice that in this test stdout and stderr for the process are not read - is it possible that it is producing some output, and since it isn't being read the process just waits leading to the exec never exiting? I think the phrasing in the article is misleading, because we're not seeing exec() *return*, which is a different issue than the case that they are talking about, namely the subsequent waitFor() not returning. So I think this doesn't apply. Interesting reading, though. 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: [apps] azureus (was Re: [testing] AWT, Swing Java2D)
Thorbjørn Ravn Andersen wrote: Tim Ellison skrev den 21-06-2006 11:58: The build instructions are here [1], let me know if they need updating. Just got around to update and check. The reference to the build.xml file in the help text shown if the dependencies have not been downloaded does not reflect that it now is ant -f make/depends.xml download instead. That's only because I took out the make/ in the error message, which was there forever (and didn't make sense), except since the change yeterday, it now makes sense to have it there :) 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: [jira] Created: (HARMONY-638) [classlib] Tests hang on in luni : tests.api.java.io.FileTest / test_setReadOnly on Ubunti 6.06
The example returns once they have fixed it. If you look at the example just before the Why Runtime.exec() hangs heading (BadExecJava2.java) you will see a situation that is almost exactly the same as in the test case. i.e. an exec followed by a waitFor(), without any reading of streams. In this case the exec never returns. The later example is how to fix it. Regards, Oliver Geir Magnusson Jr wrote: Oliver Deakin wrote: I remember seeing problems like this before, in a non-Harmony jre, where a Runtime.exec() would never return. I hunted around and found an interesting page on JavaWorld: http://www.javaworld.com/javaworld/jw-12-2000/jw-1229-traps.html I found the Why Runtime.exec() hangs section very useful, and it solved my problem at the time. I'm not saying that what you're seeing is definitely the same thing that I encountered, but it may help. I notice that in this test stdout and stderr for the process are not read - is it possible that it is producing some output, and since it isn't being read the process just waits leading to the exec never exiting? I think the phrasing in the article is misleading, because we're not seeing exec() *return*, which is a different issue than the case that they are talking about, namely the subsequent waitFor() not returning. So I think this doesn't apply. Interesting reading, though. geir - 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: [jira] Commented: (HARMONY-634) Pack200 file with just resources
(Apologies for the large to: list; I'm still unsure how to reply to
automatically generated e-mails)
It wouldn't hurt having the resources test as well as the hello world
test. At some point, I should probably expand the test to check for
the right filename etc. But we don't have to comment out the
helloworld test if it's still working.
Alex.
On 21/06/06, Tim Ellison (JIRA) [EMAIL PROTECTED] wrote:
[
http://issues.apache.org/jira/browse/HARMONY-634?page=comments#action_12417080 ]
Tim Ellison commented on HARMONY-634:
-
So given that the SegmentTest is still working ok with the HelloWorld.pack, do
you still want to apply this and switch to the resources file?
Pack200 file with just resources
Key: HARMONY-634
URL: http://issues.apache.org/jira/browse/HARMONY-634
Project: Harmony
Type: Bug
Components: Classlib
Reporter: Alex Blewitt
Assignee: Tim Ellison
Priority: Trivial
Attachments: JustResources.pack, JustResources.patch
This file is a pack200 Jar file that just contains resources, which can be
used to substitute the HelloWorld.pack that's used in the SegmentTest test case.
I've commented out the one that will fail and the JustResources.pack can be put in
the same place as the HelloWorld.pack one
Index:
/Users/alex/Documents/HarmonyWorkspace/Pack200/src/test/java/org/apache/harmony/archive/tests/internal/pack200/SegmentTest.java
===
---
/Users/alex/Documents/HarmonyWorkspace/Pack200/src/test/java/org/apache/harmony/archive/tests/internal/pack200/SegmentTest.java
(revision 415823)
+++
/Users/alex/Documents/HarmonyWorkspace/Pack200/src/test/java/org/apache/harmony/archive/tests/internal/pack200/SegmentTest.java
(working copy)
@@ -29,9 +29,17 @@
* @param args
* @throws Exception
*/
- public void testHelloWorld() throws Exception {
+// public void testHelloWorld() throws Exception {
+// assertNotNull(Segment.parse(Segment.class
+//
.getResourceAsStream(/org/apache/harmony/archive/tests/internal/pack200/HelloWorld.pack)));
+// }
+ /**
+ * @param args
+ * @throws Exception
+ */
+ public void testJustResources() throws Exception {
assertNotNull(Segment.parse(Segment.class
-
.getResourceAsStream(/org/apache/harmony/archive/tests/internal/pack200/HelloWorld.pack)));
+
.getResourceAsStream(/org/apache/harmony/archive/tests/internal/pack200/JustResources.pack)));
}
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Created: (HARMONY-638) [classlib] Tests hang on in luni : tests.api.java.io.FileTest / test_setReadOnly on Ubunti 6.06
Oliver Deakin wrote: The example returns once they have fixed it. If you look at the example just before the Why Runtime.exec() hangs heading (BadExecJava2.java) you will see a situation that is almost exactly the same as in the test case. i.e. an exec followed by a waitFor(), without any reading of streams. In this case the exec never returns. The later example is how to fix it. I don't think so. When they are saying the exec never returns, they are meaning that from the POV of the programmer, the spawned thing never returns. That's why you can do exec() do IO waitFor() done However, in our case, when I say exec never returns I mean exec() never returns. so you'd never actually get to do IO above, because you are hanging in exec(). Big difference, right? 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: [jira] Commented: (HARMONY-634) Pack200 file with just resources
Alex Blewitt wrote:
(Apologies for the large to: list; I'm still unsure how to reply to
automatically generated e-mails)
Hit reply on you mailer?
The reply-to is set to the list.
It wouldn't hurt having the resources test as well as the hello world
test. At some point, I should probably expand the test to check for
the right filename etc. But we don't have to comment out the
helloworld test if it's still working.
Alex.
On 21/06/06, Tim Ellison (JIRA) [EMAIL PROTECTED] wrote:
[
http://issues.apache.org/jira/browse/HARMONY-634?page=comments#action_12417080
]
Tim Ellison commented on HARMONY-634:
-
So given that the SegmentTest is still working ok with the
HelloWorld.pack, do you still want to apply this and switch to the
resources file?
Pack200 file with just resources
Key: HARMONY-634
URL: http://issues.apache.org/jira/browse/HARMONY-634
Project: Harmony
Type: Bug
Components: Classlib
Reporter: Alex Blewitt
Assignee: Tim Ellison
Priority: Trivial
Attachments: JustResources.pack, JustResources.patch
This file is a pack200 Jar file that just contains resources, which
can be used to substitute the HelloWorld.pack that's used in the
SegmentTest test case. I've commented out the one that will fail and
the JustResources.pack can be put in the same place as the
HelloWorld.pack one
Index:
/Users/alex/Documents/HarmonyWorkspace/Pack200/src/test/java/org/apache/harmony/archive/tests/internal/pack200/SegmentTest.java
===
---
/Users/alex/Documents/HarmonyWorkspace/Pack200/src/test/java/org/apache/harmony/archive/tests/internal/pack200/SegmentTest.java
(revision 415823)
+++
/Users/alex/Documents/HarmonyWorkspace/Pack200/src/test/java/org/apache/harmony/archive/tests/internal/pack200/SegmentTest.java
(working copy)
@@ -29,9 +29,17 @@
* @param args
* @throws Exception
*/
- public void testHelloWorld() throws Exception {
+// public void testHelloWorld() throws Exception {
+// assertNotNull(Segment.parse(Segment.class
+//
.getResourceAsStream(/org/apache/harmony/archive/tests/internal/pack200/HelloWorld.pack)));
+// }
+ /**
+ * @param args
+ * @throws Exception
+ */
+ public void testJustResources() throws Exception {
assertNotNull(Segment.parse(Segment.class
-
.getResourceAsStream(/org/apache/harmony/archive/tests/internal/pack200/HelloWorld.pack)));
+
.getResourceAsStream(/org/apache/harmony/archive/tests/internal/pack200/JustResources.pack)));
}
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
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: [jira] Commented: (HARMONY-634) Pack200 file with just resources
Not from the JIRA e-mails I get ... the reply to results in
[EMAIL PROTECTED]. I'm using GoogleMail from a Mac on Safari.
Alex.
On 21/06/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote:
Alex Blewitt wrote:
(Apologies for the large to: list; I'm still unsure how to reply to
automatically generated e-mails)
Hit reply on you mailer?
The reply-to is set to the list.
It wouldn't hurt having the resources test as well as the hello world
test. At some point, I should probably expand the test to check for
the right filename etc. But we don't have to comment out the
helloworld test if it's still working.
Alex.
On 21/06/06, Tim Ellison (JIRA) [EMAIL PROTECTED] wrote:
[
http://issues.apache.org/jira/browse/HARMONY-634?page=comments#action_12417080
]
Tim Ellison commented on HARMONY-634:
-
So given that the SegmentTest is still working ok with the
HelloWorld.pack, do you still want to apply this and switch to the
resources file?
Pack200 file with just resources
Key: HARMONY-634
URL: http://issues.apache.org/jira/browse/HARMONY-634
Project: Harmony
Type: Bug
Components: Classlib
Reporter: Alex Blewitt
Assignee: Tim Ellison
Priority: Trivial
Attachments: JustResources.pack, JustResources.patch
This file is a pack200 Jar file that just contains resources, which
can be used to substitute the HelloWorld.pack that's used in the
SegmentTest test case. I've commented out the one that will fail and
the JustResources.pack can be put in the same place as the
HelloWorld.pack one
Index:
/Users/alex/Documents/HarmonyWorkspace/Pack200/src/test/java/org/apache/harmony/archive/tests/internal/pack200/SegmentTest.java
===
---
/Users/alex/Documents/HarmonyWorkspace/Pack200/src/test/java/org/apache/harmony/archive/tests/internal/pack200/SegmentTest.java
(revision 415823)
+++
/Users/alex/Documents/HarmonyWorkspace/Pack200/src/test/java/org/apache/harmony/archive/tests/internal/pack200/SegmentTest.java
(working copy)
@@ -29,9 +29,17 @@
* @param args
* @throws Exception
*/
- public void testHelloWorld() throws Exception {
+// public void testHelloWorld() throws Exception {
+// assertNotNull(Segment.parse(Segment.class
+//
.getResourceAsStream(/org/apache/harmony/archive/tests/internal/pack200/HelloWorld.pack)));
+// }
+ /**
+ * @param args
+ * @throws Exception
+ */
+ public void testJustResources() throws Exception {
assertNotNull(Segment.parse(Segment.class
-
.getResourceAsStream(/org/apache/harmony/archive/tests/internal/pack200/HelloWorld.pack)));
+
.getResourceAsStream(/org/apache/harmony/archive/tests/internal/pack200/JustResources.pack)));
}
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
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: [jira] Commented: (HARMONY-634) Pack200 file with just resources
Odd - my reply using thunderbird on a JIRA email does the right thing...
geir
Alex Blewitt wrote:
Not from the JIRA e-mails I get ... the reply to results in
[EMAIL PROTECTED]. I'm using GoogleMail from a Mac on Safari.
Alex.
On 21/06/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote:
Alex Blewitt wrote:
(Apologies for the large to: list; I'm still unsure how to reply to
automatically generated e-mails)
Hit reply on you mailer?
The reply-to is set to the list.
It wouldn't hurt having the resources test as well as the hello world
test. At some point, I should probably expand the test to check for
the right filename etc. But we don't have to comment out the
helloworld test if it's still working.
Alex.
On 21/06/06, Tim Ellison (JIRA) [EMAIL PROTECTED] wrote:
[
http://issues.apache.org/jira/browse/HARMONY-634?page=comments#action_12417080
]
Tim Ellison commented on HARMONY-634:
-
So given that the SegmentTest is still working ok with the
HelloWorld.pack, do you still want to apply this and switch to the
resources file?
Pack200 file with just resources
Key: HARMONY-634
URL: http://issues.apache.org/jira/browse/HARMONY-634
Project: Harmony
Type: Bug
Components: Classlib
Reporter: Alex Blewitt
Assignee: Tim Ellison
Priority: Trivial
Attachments: JustResources.pack, JustResources.patch
This file is a pack200 Jar file that just contains resources, which
can be used to substitute the HelloWorld.pack that's used in the
SegmentTest test case. I've commented out the one that will fail and
the JustResources.pack can be put in the same place as the
HelloWorld.pack one
Index:
/Users/alex/Documents/HarmonyWorkspace/Pack200/src/test/java/org/apache/harmony/archive/tests/internal/pack200/SegmentTest.java
===
---
/Users/alex/Documents/HarmonyWorkspace/Pack200/src/test/java/org/apache/harmony/archive/tests/internal/pack200/SegmentTest.java
(revision 415823)
+++
/Users/alex/Documents/HarmonyWorkspace/Pack200/src/test/java/org/apache/harmony/archive/tests/internal/pack200/SegmentTest.java
(working copy)
@@ -29,9 +29,17 @@
* @param args
* @throws Exception
*/
- public void testHelloWorld() throws Exception {
+// public void testHelloWorld() throws Exception {
+// assertNotNull(Segment.parse(Segment.class
+//
.getResourceAsStream(/org/apache/harmony/archive/tests/internal/pack200/HelloWorld.pack)));
+// }
+ /**
+ * @param args
+ * @throws Exception
+ */
+ public void testJustResources() throws Exception {
assertNotNull(Segment.parse(Segment.class
-
.getResourceAsStream(/org/apache/harmony/archive/tests/internal/pack200/HelloWorld.pack)));
+
.getResourceAsStream(/org/apache/harmony/archive/tests/internal/pack200/JustResources.pack)));
}
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the
administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
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]
[drlvm] Doing the minimum to support Java 5 classfiles
It seems we're in general agreement that getting DRLVM to deal with Java 5 classfiles is a good place to start. It supports our project desire to get off the target=jsr14 hack for compiling. So, for those that know the DRLVM codebase, what are the steps? Anyone who throws the One Big Patch over the wall will be summarily beaten about the head and neck with a trout, by the way, and we may not defrost the trout first... lets use this as an exercise to start learning about the DRLVM and get people talking about how to do these things together, with small patches once we agree on the strategy :) 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: [jira] Commented: (HARMONY-634) Pack200 file with just resources
Here's what it looks like in GMail. Normally, the reply-to looks OK,
but in the [jira] case, it's not filled in. And here's the GMail mail
header:
X-Gmail-Received: 6912720e939c46a2efe12022cbcd40744ee744be
Delivered-To: [EMAIL PROTECTED]
Received: by 10.70.103.19 with SMTP id a19cs319376wxc;
Wed, 21 Jun 2006 04:31:36 -0700 (PDT)
Received: by 10.64.179.19 with SMTP id b19mr784713qbf;
Wed, 21 Jun 2006 04:31:36 -0700 (PDT)
Return-Path: [EMAIL PROTECTED]
Received: from brutus.apache.org (brutus.apache.org [209.237.227.198])
by mx.gmail.com with ESMTP id e15si351702qbe.2006.06.21.04.31.35;
Wed, 21 Jun 2006 04:31:36 -0700 (PDT)
Received-SPF: pass (gmail.com: best guess record for domain of
[EMAIL PROTECTED] designates 209.237.227.198 as permitted sender)
Received: from brutus (localhost [127.0.0.1])
by brutus.apache.org (Postfix) with ESMTP id A846E410007
for [EMAIL PROTECTED]; Wed, 21 Jun 2006 11:30:30 + (GMT)
Message-ID: [EMAIL PROTECTED]
Date: Wed, 21 Jun 2006 11:30:30 + (GMT+00:00)
From: Tim Ellison (JIRA) [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: [jira] Commented: (HARMONY-634) Pack200 file with just resources
In-Reply-To: [EMAIL PROTECTED]
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
[
http://issues.apache.org/jira/browse/HARMONY-634?page=comments#action_12417080
]
There doesn't look like there's a Reply-To set there. What does the
mail header look like to you? Is it GMail that's stripping it out?
Alex.
PS I'm glad I got a chance to use OmniDazzle. Funky, huh?
On 21/06/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote:
Odd - my reply using thunderbird on a JIRA email does the right thing...
geir
Alex Blewitt wrote:
Not from the JIRA e-mails I get ... the reply to results in
[EMAIL PROTECTED]. I'm using GoogleMail from a Mac on Safari.
Alex.
On 21/06/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote:
Alex Blewitt wrote:
(Apologies for the large to: list; I'm still unsure how to reply to
automatically generated e-mails)
Hit reply on you mailer?
The reply-to is set to the list.
It wouldn't hurt having the resources test as well as the hello world
test. At some point, I should probably expand the test to check for
the right filename etc. But we don't have to comment out the
helloworld test if it's still working.
Alex.
On 21/06/06, Tim Ellison (JIRA) [EMAIL PROTECTED] wrote:
[
http://issues.apache.org/jira/browse/HARMONY-634?page=comments#action_12417080
]
Tim Ellison commented on HARMONY-634:
-
So given that the SegmentTest is still working ok with the
HelloWorld.pack, do you still want to apply this and switch to the
resources file?
Pack200 file with just resources
Key: HARMONY-634
URL: http://issues.apache.org/jira/browse/HARMONY-634
Project: Harmony
Type: Bug
Components: Classlib
Reporter: Alex Blewitt
Assignee: Tim Ellison
Priority: Trivial
Attachments: JustResources.pack, JustResources.patch
This file is a pack200 Jar file that just contains resources, which
can be used to substitute the HelloWorld.pack that's used in the
SegmentTest test case. I've commented out the one that will fail and
the JustResources.pack can be put in the same place as the
HelloWorld.pack one
Index:
/Users/alex/Documents/HarmonyWorkspace/Pack200/src/test/java/org/apache/harmony/archive/tests/internal/pack200/SegmentTest.java
===
---
/Users/alex/Documents/HarmonyWorkspace/Pack200/src/test/java/org/apache/harmony/archive/tests/internal/pack200/SegmentTest.java
(revision 415823)
+++
/Users/alex/Documents/HarmonyWorkspace/Pack200/src/test/java/org/apache/harmony/archive/tests/internal/pack200/SegmentTest.java
(working copy)
@@ -29,9 +29,17 @@
* @param args
* @throws Exception
*/
- public void testHelloWorld() throws Exception {
+// public void testHelloWorld() throws Exception {
+// assertNotNull(Segment.parse(Segment.class
+//
.getResourceAsStream(/org/apache/harmony/archive/tests/internal/pack200/HelloWorld.pack)));
+// }
+ /**
+ * @param args
+ * @throws Exception
+ */
+ public void testJustResources() throws Exception {
assertNotNull(Segment.parse(Segment.class
-
.getResourceAsStream(/org/apache/harmony/archive/tests/internal/pack200/HelloWorld.pack)));
+
.getResourceAsStream(/org/apache/harmony/archive/tests/internal/pack200/JustResources.pack)));
}
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the
administrators:
Re: [jira] Created: (HARMONY-638) [classlib] Tests hang on in luni : tests.api.java.io.FileTest / test_setReadOnly on Ubunti 6.06
Geir Magnusson Jr wrote: Oliver Deakin wrote: The example returns once they have fixed it. If you look at the example just before the Why Runtime.exec() hangs heading (BadExecJava2.java) you will see a situation that is almost exactly the same as in the test case. i.e. an exec followed by a waitFor(), without any reading of streams. In this case the exec never returns. The later example is how to fix it. I don't think so. When they are saying the exec never returns, they are meaning that from the POV of the programmer, the spawned thing never returns. That's why you can do exec() do IO waitFor() done However, in our case, when I say exec never returns I mean exec() never returns. so you'd never actually get to do IO above, because you are hanging in exec(). Big difference, right? Certainly - do you have a stack trace that gives more info for what each of the threads are doing? Could you attach it to the JIRA if you do please - Ive just tried running a cut down version of the test on my SLES9 machine and it exited fine, so it would be useful to have a trace from your machine to see what's happening. Thanks, Oliver geir - 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: [jira] Created: (HARMONY-638) [classlib] Tests hang on in luni : tests.api.java.io.FileTest / test_setReadOnly on Ubunti 6.06
Oliver Deakin wrote: Geir Magnusson Jr wrote: However, in our case, when I say exec never returns I mean exec() never returns. so you'd never actually get to do IO above, because you are hanging in exec(). Big difference, right? Certainly So I assume you agree? (Just want to make sure that I'm not missing something terribly important here...) - do you have a stack trace that gives more info for what each of the threads are doing? Could you attach it to the JIRA if you do please - Ive just tried running a cut down version of the test on my SLES9 machine and it exited fine, so it would be useful to have a trace from your machine to see what's happening. Done geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] what's next?
On 6/21/06, Xiao-Feng Li [EMAIL PROTECTED] wrote: If no one else is doing it, I will start the porting of SableVM's gen GC into DRLVM. Good idea. Go for it. I talked to Carl Lebsack today. He mentioned that SableVM asked permission to relicense his generational GC under Apache license. It seems possible that all of SableVM will be relicensed under Apache license. :) Carl mentioned that the SableVM/GC interface is not well defined but sees value in what we are proposing here. Thanks, xiaofeng - 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]
[drlvm/mmtk] jitrino.jet write barrier design questions
It would be really nice if jitrino.jet allowed the write barrier to be
selected at the start of jitting an individual method. Is this
possible?
The selections would be mutually exclusive:
1)
no write barrier (for the existing GCV4)
2)
write barrier written in Java (for MMTk)
3)
write barrier written in C (for the yet to be determined basic generational GC)
Allowing the java write barrier to be selected on a method by method
basis would be very useful for MMTk bring up. The concept is to
initially run MMTK sort of like a user mode linux. That is, startup
the JVM w/o barriers turned on. Run hello world. Then switch on
MMTK collector/allocator and Java write barriers and compile/run the
following method:
public class InitialMMTkBringup {
public int stressTheMMTkAllocator () {
while(true) {
Object obj = new Object();
Object [] ia = new Object[100];
//at a later stage, add code that causes a write barrier
//at a later stage, add code that will randomly chain Object
arrays together...
}
}
The above would be running while the underlying JVM GC is running. If
not careful this could cause lots of confusion. The intention is to
run MMTk in user mode only to the point where MMTk alloc,
collection, write barrier code paths are exercised. Provided we do
not do anything to cause the underlying JVM GC to kick in, we should
be OK.
As a second step actually integrate MMTk into the JVM. Note that
basic garden variety Java debugger should work w/o modification with a
user mode MMTk.
--
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: [jira] Created: (HARMONY-638) [classlib] Tests hang on in luni : tests.api.java.io.FileTest / test_setReadOnly on Ubunti 6.06
From: Oliver Deakin [mailto:[EMAIL PROTECTED] Geir Magnusson Jr wrote: Oliver Deakin wrote: The example returns once they have fixed it. If you look at the example just before the Why Runtime.exec() hangs heading (BadExecJava2.java) you will see a situation that is almost exactly the same as in the test case. i.e. an exec followed by a waitFor(), without any reading of streams. In this case the exec never returns. The later example is how to fix it. I don't think so. When they are saying the exec never returns, they are meaning that from the POV of the programmer, the spawned thing never returns. That's why you can do exec() do IO waitFor() done However, in our case, when I say exec never returns I mean exec() never returns. so you'd never actually get to do IO above, because you are hanging in exec(). Big difference, right? Certainly - do you have a stack trace that gives more info for what each of the threads are doing? Could you attach it to the JIRA if you do please - Ive just tried running a cut down version of the test on my SLES9 machine and it exited fine, so it would be useful to have a trace from your machine to see what's happening. Could you send me the code for Process so I can see what's going on here? :) Geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
build problems
1) the dependency on ecj_3.2RC5 is not checked:
[copy] Copying
C:\harmony\trunk_0427\depends\jars\bcprov-jdk14-133\bcprov.jar to
C:\harmony\trunk_0427\deploy\jdk\jre\lib\ext\bcprov.jar
BUILD FAILED
C:\harmony\trunk_0427\build.xml:83: The following error occurred while
executing this line:
C:\harmony\trunk_0427\make\build-java.xml:161:
C:\harmony\trunk_0427\depends\jars\ecj_3.2RC5 not found.
Total time: 2 minutes 31 seconds
...
2) the build failed on java-compilation on the WinXP with 1Gb RAM (650Mb
free) as:
...
compile:
[mkdir] Created dir: C:\users\TCKTeam\ws\trunk\build
[javac] Compiling 2895 source files to C:\users\TCKTeam\ws\trunk\build
[javac] The system is out of resources.
[javac] Consult the following stack trace for details.
[javac] java.lang.OutOfMemoryError: Java heap space
BUILD FAILED
C:\users\TCKTeam\ws\trunk\build.xml:83: The following error occurred while
executing this line:
C:\users\TCKTeam\ws\trunk\make\build-java.xml:84: Compile failed; see the
compiler error output for details.
Total time: 1 minute 8 seconds
To fix it the build-java.xml was updated (locally) as:
javac fork=yes memoryInitialSize=512M memoryMaximumSize=600M
destdir=${build.output} source=${hy.javac.source} target=${
hy.javac.target} debug=on
Thanks, Vladimir
Re: [classlib][math] Location of performance tests (was: Re: performance improvement for java.math package)
I've confused all the things. Sorry. Of course the tests should go to math/src/test/performance Vladimir, is it possible to convert the test to JUnit format and make them report pass/fail status rather than printing log? Thanks, Mikhail 2006/6/21, Mikhail Loenko [EMAIL PROTECTED]: I'd like to bring it to common judgment. AFAIU we have two basic options for performance tests location: make them module level or make a top-level tests subtree that would contain all types of the tests except for unit tests BTW, In the testing convention my intent was to cover unit tests only. Though we did not agree which exactly tests are unit, so I avoided that word. But I definitely did not mean performance, stress and whatever special types of the tests. If no one objects I'll add some clarification to the conventions proposal. Thanks, Mikhail 2006/6/20, Vladimir Strigun [EMAIL PROTECTED]: On 6/20/06, Mikhail Loenko [EMAIL PROTECTED] wrote: I think they are not unit tests and should go to a different (performance?) test suite. Right now we don't have one but it seems to be time to create it Of course, it's not unit tests, but my suggestion was based on our testing convention. What do you think about modulename/src/tests/performance ? Thanks, Vladimir. Thanks, Mikhail 2006/6/20, Vladimir Strigun [EMAIL PROTECTED]: Hi Mikhail, AFAIK, we haven't such kind of tests in svn yet. It's hard to define best place for it, but since this suite is intended for java.math testing only and it's implementation-independent tests, I believe modules/math/src/test/java/tests/api is appropriate place. If you agree with this I will create patch for suite, add copyright and change package definition of classes. What do you think about it? Thanks, Vladimir. On 6/13/06, Mikhail Loenko [EMAIL PROTECTED] wrote: Hi Vladimir What do you think the most appropriate location and suite for the tests in the HARMONY-551 are? Thanks, Mikhail 2006/6/2, Vladimir Strigun [EMAIL PROTECTED]: Our team has done some analysis of current Harmony implementation of java.math package. The implementation was considered from the performance point of view and I'd like to share results of our work with you. The analysis and tuning was made from the enterprise-level applications point of view which are known to use BigInteger and BigDecimal for storing numeric information. In most cases the numbers there fit well within 32 bits. So coming from the BigDecimal perspective which is really important for these applications and taking into account some specifics (small numbers) we made some optimizations in both BigDecimal and BigInteger. The latter was tuned specifically for BigDecimal: - Special handling for small numbers (fit within 32 bit) was added to all methods - Frequently used constants (0..10) were cached and reused by valueOf method (no need to create a new instance of BigInteger) - as well as were powers of 10 (0..10) - methods add(), divide(), divideAndRemainer() in BigInteger were optimized for short values if both arguments can fit in 32 bits the resulting BigInteger is created by valueOf method. If we consider enterprise level applications, we can imagine that toString() method is also frequently used. The method was analyzed and as a result we combined toString() methods in BigDecimal and BigInteger to one unified method in BigInteger. Method BigInteger.toDecimalScaledString(int scale) now is used from both BigInteger and BigDecimal. This way allows reducing amount of created objects and data copying. In addition, size calculation was modified for resulting array. In the new implementation the size is calculated with less precision. Because allocated char array will be copied into String and collected by GC after toString() then it is not a problem if the allocated char array will be slightly bigger then necessary. I've attached the changes we made for BigInteger and BigDecimal to Harmony-551 We also have created a set of micro benchmarks (which I'll to attach to JIRA as well) which shows that our special-case handling doesn't break the performance for other cases and we do not degrade in common, and, of course, all unit tests pass with new version. Below you can find several comparisons in performance between current version and the fixed one. === Ops/sec for toString() method of BigDecimal Number Current fixed one of digits version 2 11215354 4 774 7514 8 615 6748 12 743 5543 16 623 4494 24 389 4895 32 306 3496 48 232 5815 64 224 3761 128 91
Re: build problems
On 22 June 2006 at 10:25, Vladimir Ivanov [EMAIL PROTECTED] wrote:
1) the dependency on ecj_3.2RC5 is not checked:
[copy] Copying
C:\harmony\trunk_0427\depends\jars\bcprov-jdk14-133\bcprov.jar to
C:\harmony\trunk_0427\deploy\jdk\jre\lib\ext\bcprov.jar
BUILD FAILED
C:\harmony\trunk_0427\build.xml:83: The following error occurred while
executing this line:
C:\harmony\trunk_0427\make\build-java.xml:161:
C:\harmony\trunk_0427\depends\jars\ecj_3.2RC5 not found.
Total time: 2 minutes 31 seconds
...
Fixed in r416240. Thanks for the report.
2) the build failed on java-compilation on the WinXP with 1Gb RAM (650Mb
free) as:
...
compile:
[mkdir] Created dir: C:\users\TCKTeam\ws\trunk\build
[javac] Compiling 2895 source files to C:\users\TCKTeam\ws\trunk\build
[javac] The system is out of resources.
[javac] Consult the following stack trace for details.
[javac] java.lang.OutOfMemoryError: Java heap space
BUILD FAILED
C:\users\TCKTeam\ws\trunk\build.xml:83: The following error occurred while
executing this line:
C:\users\TCKTeam\ws\trunk\make\build-java.xml:84: Compile failed; see the
compiler error output for details.
Total time: 1 minute 8 seconds
To fix it the build-java.xml was updated (locally) as:
javac fork=yes memoryInitialSize=512M memoryMaximumSize=600M
destdir=${build.output} source=${hy.javac.source} target=${
hy.javac.target} debug=on
Good idea. Fixed in r416245.
Regards,
-Mark.
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
