[classlib]native codes layout question(was Re: [classlib][NIO|VMI]JNI 1.4 enhancement on ByteBuffer)
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. 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)? -- 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] Simplifying the ant files?
On 19 June 2006 at 8:55, Tim Ellison [EMAIL PROTECTED] wrote: Mark Hindess wrote: On 19 June 2006 at 14:03, Mikhail Loenko [EMAIL PROTECTED] wrote: Good stuff. I was also thinking about separating exclude list from modules' build.xml. Yes that definitely makes sense. (I did that in one of the old JIRAs but had forgotten about it.) And George had submitted a patch to do that too in HARMONY-263. That was a while ago and has languished while we had other things on our collective mind, maybe its time has come now. It would be a shame to reinvent it. I agree. George's patch was much more sophisticated and we should definitely use that approach. (That doesn't mean I wont pull them out in a trivial manner if it happens to simplify the other build.xml changes I'm making in the meantime.) I'll wait another 24 hours for comments and then I'll get started on these improvements. Are you volunteering to move the build.xml's up a level? I'm quite happy to do it, but don't want to step on your toes. Yes. Done at the top-level. I'm going to tackle the modules next. -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]native codes layout question(was Re: [classlib][NIO|VMI]JNI 1.4 enhancement on ByteBuffer)
On 20 June 2006 at 14:18, Paulex Yang [EMAIL PROTECTED] 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. If you aren't planning on waiting until Oliver has done at least some of the moves, then assume the old/current locations of native-src/*/nio. (I assume this will mostly be shared?) If you are planning on waiting, then use Oliver's work as a template for how the native build should proceed. (Personally, I'm waiting before doing the awt/swing native source integration.) 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)? Yes. Since this header forms part of the API it probably should be moved to deploy/include at build time - like the other headers for the classlib natives API. No code should reference the native source of another module directly only via the deploy tree. 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] [build] Precompiled libraries (was: awt and swing integration issues)
2006/6/20, Geir Magnusson Jr [EMAIL PROTECTED]: We don't want to do that, distribute third party code that we build. But as far as I understand we will do that... HDK will include this libraries. Isn't it? -- Alexey A. Petrenko Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] [testing] Coverage (was Re: 37% of total test execution time is spent in a single test)
Vladimir Ivanov wrote: Classes from exclude list are now specified as green. I've update wiki (http://wiki.apache.org/harmony/Coverage_information) and coverage pages. Great, thank you, Vladimir! Thanks, Vladimir On 6/16/06, Paulex Yang [EMAIL PROTECTED] wrote: Vladimir Vladimir Ivanov wrote: The current reports don't provide code source linking. Are you going to add it? There were no information for 'security' and 'auth' modules, but, I have updated the pages and now there is source code linking for all modules. One more issue to discuss: excluded classes present in the coverage table now with 0 coverage. May be it is more convenient do not have these classes in coverage tables at all? In this case one won't wonder why the class has 0 coverage - go to exclude list to look at the class and decide whether the class is really untested or just excluded from coverage, instead, all really uncovered classes will be shown with 0 coverage, if a class is missed in coverage table – it is in exclude list. +1 for current 0 coverage is not convenient. But if we can remove them from the report, how about just mark them in another way? say, mark the excluded class with different background colors? At least people don't need to care about two documents for one package. Thanks, Vladimir Now I have 2 questions/ issues to discuss: 1) preferable VM to calculate coverage (seems, the exclude list is a little bit different for j9 and drlvm) If the only difference is the exclude list then I'd suggest using VM with the shortest one. :-) 2) preferable sorting mode for results (by name, by blocks or by methods) IMHO, sorting by name looks more natural. Thanks, Stepan. Thanks, Vladimir SNIP -- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Paulex Yang China Software Development Lab IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- 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: [apps] azureus (was Re: [testing] AWT, Swing Java2D)
Anton and Tim,
FYI, the Selector implementation has been merged into SVN as patch of
Harmony-41 at revision 415279. So it should be ready to use now. Thank you.
Tim Ellison wrote:
Anton Luht wrote:
Good day,
I've tried to run Azureus, too, and saw all those problems (no SSL
provider, NotYetBoundException), too.
I've also seen messages
'VirtualChannelSelector.select() op called with null selector'
Digging the code I've found that the problem is that Selector.open()
returns null (not null in RI)
How did you get past the initialization part?
I have put my experiences here:
http://wiki.apache.org/harmony/Azureus
Test case is:
public class Test {
public static void main(String args[]) throws Exception {
System.err.println(java.nio.channels.Selector.open() != null ?
PASSED : FAILED);
}
}
Hmm, the Harmony impl looks like this:
public AbstractSelector openSelector() throws IOException {
// return new SelectorImpl(this);
//FIXME: wait for JIRA-41
return null;
}
Time to speak to Paulex nicely and see if he is working on it ;-)
Regards,
Tim
I've built RE manually using today SVN snapshot (412715) and
Harmony-vme-win.IA32-v3.zip as described in Harmony documentation
On 6/6/06, Mark Hindess [EMAIL PROTECTED] wrote:
On 5 June 2006 at 19:07, R.J. Lorimer [EMAIL PROTECTED]
wrote:
For the record (I didn't gather this anywhere from this discussion),
Azureus (while being a very non-trivial and cool Java application), is
not written in AWT/Swing, it is written with SWT (the same as Eclipse).
It's probably a good application to interact with for testing, but it's
not an AWT/Swing test.
So I theory, this might run now!
I tried running it but get lots of error output like:
DEBUG::Tue Jun 06 08:29:39 BST
2006::com.aelitis.azureus.core.networkmanager.impl.VirtualBlockingServerChannelSelector::accept_loop::138:
VirtualBlockingServerChannelSelector$1::runSupport::85,AEThread::run::69
java.nio.channels.NotYetBoundException
at
org.apache.harmony.nio.internal.ServerSocketChannelImpl.accept(ServerSocketChannelImpl.java:125)
at
com.aelitis.azureus.core.networkmanager.impl.VirtualBlockingServerChannelSelector.accept_loop(VirtualBlockingServerChannelSelector.java:129)
at
com.aelitis.azureus.core.networkmanager.impl.VirtualBlockingServerChannelSelector$1.runSupport(VirtualBlockingServerChannelSelector.java:85)
at org.gudy.azureus2.core3.util.AEThread.run(AEThread.java:69)
Definitely seems like a good thing to get working - it certainly
exercises quite a bit of the networking code.
Regards,
Mark.
Thorbjørn Ravn Andersen wrote:
Anton Luht skrev den 05-06-2006 19:21:
(http://sourceforge.net/top/topalltime.php?type=downloads) and found
at least one project that was never mentioned in this list: Azureus
(a BitTorent client). It has 118,5 millions of downloads and scores
8,700,000 in Google search.
I second that. Just downloaded the latest, and it is defintiively a
non-trivial application, which also knows how to open holes in uPnP
firewalls etc, has custom look-and-feel and very evidently is
multithreaded.
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Paulex Yang
China Software Development Lab
IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[classlib] Merging frameworks for testing serialization - first step
Hi,
I'm going to start merging existing frameworks for testing serialization.
As first step I've updated 'security' framework. The updated framework
searches and loads resource files according [1] and eliminates requirement
to extend SerializationTest. Also to provide smooth frameworks merging I've
put stub to let the framework search resources in the 'old' way (i.e. via
RESOURCE_DIR system property). The stub will be removed after completing
the merge.
The updated framework suggests the following way for testing serialization:
a) Compatibility – 4 new static methods are introduced.
verifyGolden(TestCase, Object)
verifyGolden(TestCase, Object, SerializableAssert)
verifyGolden(TestCase, Object[])
verifyGolden(TestCase, Object[], SerializableAssert)
A test should invoke one of above methods, for example,
public void testCompatibility() throws Exception {
SerializationTest.verifyGolden(this, new SomeSerializableClass ());
}
b) Self-testing: the same as for compatibility – there are 4 new static
methods that should be invoked from a test:
verifySelf(TestCase, Object)
verifySelf(Object, SerializableAssert)
verifySelf(TestCase, Object[])
verifySelf(Object[], SerializableAssert)
For example,
public void testSelf() throws Exception {
SerializationTest.verifySelf(new SomeSerializableClass(), new
MyComparator());
}
To complete frameworks merging I'd like to suggest the next steps:
2) Reviewing the update and the suggested way for testing serialization by
the community. Please let me know if it is acceptable and what can be
improved.
3) Replace SerializationTester class with SerializationTest. I'm going to
add more stubs to let existing tests work in the 'old' way.
4) Adjusting existing serialization tests (moving and renaming resource
files, replacing stubs invocation with new methods)
5) Removing stubs.
Thanks,
Stepan Mishura
Intel Middleware Products Division
[1]
http://incubator.apache.org/harmony/subcomponents/classlibrary/ser_testing.html
--
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][java.math]performance improvement for java.math package
Hi Daniel, Thank you for your response and sorry for delay with my answer. Please find my comments inside. On 6/15/06, Daniel Fridlender [EMAIL PROTECTED] wrote: Hi Vladimir, thank you very much for this new optimization of math from, as you said, enterprise-level applications point of view. Of course we are considering this optimization (H551) as well for the combination of the different math implementations into a new and more efficient one. In fact we are already working on a new version combining H39+380 with H199 and are introducing some of H551 optimizations as well. On the other hand, we are for the moment postponing some other of your optimizations for a future version since introducing them now would break, in my opinion prematurely, a nice design property we have so far: BigDecimal depends only on public features of BigInteger. Thanks for doing this. What kind of optimization you planned to add first? I can agree that it's good to have such design, but nevertheless since BigDecimal internally represented though BigInteger, possibly it should be also good to use some non public features of BigInteger. So, we are following this plan: 1) integration of H39+H380 with H199 and with part of H551 2) optimization of this with more advanced algorithms 3) introducing remaining optimization from H551 For the point 2) above I would still like to have independence between BigDecimal and BigInteger. I hope you agree with this plan. Yes, this plan sounds good for me. Let's follow it and compare implementations after 1st integration. We can use microbench that attached to the issue, or, possibly we should find another benchmark for it. What benchmarks you have used for performance measurement? I would also be grateful if you could be more specific when you mention enterprise-level applications. We are looking for realistic applications of math in order to be able to get an idea of how the implementations will work in practice. So far we had only found a few applications in cryptography and in number factorization (actually, they are applications of BigInteger only). Could you point me to the applications you had in mind so that we can add them to our (so far) small collection of applications? Are those applications for which float or double are not enough? I have in mind some banking software, online payment processing, etc. Within these type of application values usually fit to 32 bit, that's why we have special case for small numbers. Also, these optimizations do not degrade in common. Thanks, Vladimir. Thanks again, Daniel On 6/2/06, Vladimir Strigun [EMAIL PROTECTED] wrote: 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.
Re: [classlib][java.math]performance improvement for java.math package
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 Ops/sec for subtract method of BigInteger Number Current fixed one of digits version 2 39204394 4 33003302 8 51785640 12 957 913 16 37942904 24 20571962 32 34213241 48 34692828 64 652 610 128 23182246 === Unfortunately we haven't look thoroughly to ITC contribution, so it may happen that some of the optimizations described in this letter were already implemented there. Daniel, could you please consider our new implementation when you start to merge implementations math packages. If optimization methods described above already have been implemented in ITC contribution it will be great to compare internal representation of BigInteger and try to measure affect of different approaches. On 6/2/06, Vladimir Strigun (JIRA) [EMAIL PROTECTED] wrote: [ http://issues.apache.org/jira/browse/HARMONY-551?page=all ] Vladimir Strigun updated HARMONY-551: - Attachment: Harmony-551.diffs Please try my patch. Several features were added: - special handling for small value - frequently used constans were cached - several methods were modified and optimized for small value. etc. [classlib][java.math] performance improvement for
Attaching threads to classlib (was: Re: [jchevm+classlibadapter] Running classlib tests)
Archie Cobbs wrote: Ivan Volosyuk wrote: IMHO, Archie's suggestion is simplier and less intrusive, as the function Thread.attachInternal() can be native function implemented in classlibadapter itself. But Graeme is correct in that there could be initialization delay. I.e., if we're following the normal rules of Java, all the initialization associated with java.lang.Object, java.lang.String, etc. will have to occur before the very first thread can invoke any methods in java.lang.Thread (even if native). The idea is salvagable if we have a special classlib-specific launcher (i.e., C program using the JNI invocation interface to launch the JVM) We do have a Harmony launcher [1] that sets up the VMI structure to pass through to the VM and uses JNI invocation. [1] http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/native-src/shared/launcher/ which did the very first thread_attach() for the main thread. Then all the other threads could use Thread.attachThread() or whatever without all the initialization delay. We could attach the primordial thread in the launcher but of course that would not help when the VM is embedded in some other program and doesn't have the launcher's help. VMs should also be aware that attaching a thread that is already attached will set the hythread_t pointer arg to the original struct, and increment the attachment count. Yet another idea (probably not feasible) would be for classlib to: (a) check whether thread_attach() has been called yet for the current thread in any native method that requires this to be so, and if not, go ahead and do it itself This is do-able too by hijacking the THREAD_SELF macro, but a bit of a hack, and doesn't give a good story for thread death. (b) store its state in a ThreadLocal (so cleanup would be automatic) Well, unless you have to do some work on the thread death, if it were just TLS data then yes. Regards, Tim This would eliminate the requirement for the VM to be classlib-aware. -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] -- 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: awt and swing integration issues
Alexey Petrenko wrote: 2006/6/18, Mark Hindess [EMAIL PROTECTED]: On 18 June 2006 at 22:16, Alexey Petrenko [EMAIL PROTECTED] wrote: 2006/6/18, Mark Hindess [EMAIL PROTECTED]: c) I'm also wondering about the motivation for using C++ when I can't see any pressing reason to require this. You mean that most of the native code is C++ but not C? Yes. It seems to be a mixture of C and C++ and although I only looked at a couple of files I didn't see anything that really needed C++ features. For portability I'd stick to C if C++ isn't really required. But C++ gives at least 2 benefits for developer: 1. Strict type checking 2. It is allow to write env-FindClass(java/lang/Object) instead of (*env)-FindClass(env, java/lang/Object) :) Windows version also uses GDI+ which is class library. So I vote for C++... I remember this discussion ;-) I don't object to using C++ syntax, but let's try to avoid the use of STL and other minefields that vary across implementation/platforms. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] linking question
Hi,
The problem is in the order of the linked libs. the order is important for
gcc.
Change components/vm/vmi, the order must be:
libset libs=hyzip dir=${external.dep.CLASSLIB.libdir} /
libset libs=hypool dir=${external.dep.CLASSLIB.libdir} /
libset libs=hyprt dir=${external.dep.CLASSLIB.libdir} /
Marina
On 6/20/06, Mark Hindess [EMAIL PROTECTED] wrote:
On 20 June 2006 at 1:05, Geir Magnusson Jr [EMAIL PROTECTED] wrote:
I've been puttering about and am having a problem under linux.
Everything builds now, and APR is built using the standard ./configure
make combination. No big deal.
But I seem to have a linking problem - libvmi.so gets built w/o things
like pool_* entries resolved. I do believe that I'm pointing the linker
at the right files in /classlib via vmi.xml via libset. I think I'm
right as when I tweak the lib name, say from hypool to hypoolwoogie
the build complains.
But still - libvmi.so on my box is made w/o those deps.
Given that the cc and linker ant tasks are black magic to me, how
does one figure this out? can you make cc tell you want it's doing?
I have no idea what it's using to link, for example, and what the
invocation of the linker is in terms of flags and args.
Any help appreciated...
Does:
ANT_ARGS=-v sh build.sh
give you enough information?
-Mark.
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][testing]resource files: location and usage
Vladimir Ivanov wrote: On 6/20/06, Gregory Shimansky [EMAIL PROTECTED] wrote: On Monday 19 June 2006 20:33 Anton Luht wrote: It is not a good idea to put creation of such resources in something like setUp() method in JUnit test because who knows if a read-only file created by VM under test is really read-only or not :) Extending this question would be how do you know that JUnit framework executed by VM under test does actually produce the correct results? I think there should be some minimal trust in the means which tests use, resources creation included into it. It would be a good starting point at least for now. I agree, and even more - when we test some API we assume that the rest of API works fine. So if the method-not-under-test is used to create the resource it is OK to do it in the setUp() method. Indeed, unless you are extremely paranoid that all the other API implementations wrong, but are conspiring to make your test pass then you should assume that everything else is working ok and you are testing some specific piece of functionality. Our ability to run real world applications is part of the sanity check too. 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: awt and swing integration issues
2006/6/20, Tim Ellison [EMAIL PROTECTED]: Alexey Petrenko wrote: 2006/6/18, Mark Hindess [EMAIL PROTECTED]: On 18 June 2006 at 22:16, Alexey Petrenko [EMAIL PROTECTED] wrote: 2006/6/18, Mark Hindess [EMAIL PROTECTED]: c) I'm also wondering about the motivation for using C++ when I can't see any pressing reason to require this. You mean that most of the native code is C++ but not C? Yes. It seems to be a mixture of C and C++ and although I only looked at a couple of files I didn't see anything that really needed C++ features. For portability I'd stick to C if C++ isn't really required. But C++ gives at least 2 benefits for developer: 1. Strict type checking 2. It is allow to write env-FindClass(java/lang/Object) instead of (*env)-FindClass(env, java/lang/Object) :) Windows version also uses GDI+ which is class library. So I vote for C++... I remember this discussion ;-) I don't object to using C++ syntax, but let's try to avoid the use of STL and other minefields that vary across implementation/platforms. No objection on this :) SY, Alexey -- Alexey A. Petrenko Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][testing]resource files: location and usage
On 6/20/06, Vladimir Ivanov wrote: Thanks Stepan, 1. The decision about other resource files is: they should be stored into src/test/resources/ without further naming convention. Right? – then, a) Ideally, can we specify further (after src/test/resources/) naming convention for resource files as it is done for serialization files? Resource files for testing serialization is the first case. To work out further conventions we should at least understand what kinds of resource files are required for testing. For example, we may agree that resource files for net-based tests should be put separately in 'net' sub-folder. And I'd suggest to put all other resources into 'other' folder (i.esrc/test/resources/other). b) At least, specify that resource file name should contain test name – for easy resource file search? Agree. c) Shouldn't we move content of trunk/support/ into corresponding module's src/test/resources/ directories? – if yes, I can do it. No. IIRC we agreed to move 'things' used across different modules to trunk/support/. 2. Can we add a link to the http://incubator.apache.org/harmony/subcomponents/classlibrary/ser_testing.htmldocument at the testing page? Sure. I want to create a script which checks that tests are stored as it is described on testing and serialization convention pages. Yes, it'll be useful. But currently few resource files follow conventions :-) Thanks, Stepan. Thanks, Vladimir On 6/19/06, Stepan Mishura [EMAIL PROTECTED] wrote: On 6/19/06, Vladimir Ivanov wrote: It would be good if the page http://incubator.apache.org/harmony/subcomponents/classlibrary/testing.htmldescribes also location, name convention and access model for resource files used for testing, specifically, for testing serialization. At the present moment test's resource files stored in src/test/resources directory in modules structure. Serialization data stored as resources/ + serialization/ + package name or resources/ + package name + /serialization/ with .ser or .dat extension. Other resource files are stored in resources/ or in the resources/package name directory. I found two mechanisms of accessing resources in tests: 1) Get resource through ClassLoader.getResource (serialization/package name) 2) Get resource through reading file System.getProperty(RESOURCE_DIR + filename). Hi Vladimir, The second mechanismis used in 'security' testing framework (used by auth/crypto/security/x-net modules). We are agreed to merge two existing framework for testing serialization. Currently I'm preparing update for the 'security' framework - it will replace the second mechanism it with the first. Suggestion: 1) Ideal from my point of view variant: lets uniform access to resources throughout all tests (I can do it). Agreed. We should work out uniform access to resources. IIRC we agreed to access *all* resources via classpath. 2) If it's not good idea, then, lets just describe technique of working with resources on testing conventions page to limit the number of access techniques to only two (I can do it). Thoughts? see [1] for name conventions for serialization resource files. Thanks, Stepan. [1] http://incubator.apache.org/harmony/subcomponents/classlibrary/ser_testing.html -- 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)
Paulex Yang wrote: Mark Hindess wrote: snip Yes. Since this header forms part of the API it probably should be moved to deploy/include at build time - like the other headers for the classlib natives API. I see, but seems not all header files in LUNI are copied into deploy/include now, for example, portsock.h. So is there any rules which one is copied and which one is not? It should be all headers that are available externally to the module (i.e. just not those that are local impl. functions) so I would have expected portsock.h to be in there. 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)
Paulex Yang wrote: Anton and Tim, FYI, the Selector implementation has been merged into SVN as patch of Harmony-41 at revision 415279. So it should be ready to use now. Thank you. Cool -- thanks Paulex. Can you easily repeat the experiment Anton? It would be good if you put your method on the apps wiki page http://wiki.apache.org/harmony/Azureus so I can get further too. 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)
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]
Re: [classlib] Merging frameworks for testing serialization - first step
Stepan,
Cool! Basically I'm fine with the merging plan, and I'm very interested
in more details, please see my comments below:
Stepan Mishura wrote:
Hi,
I'm going to start merging existing frameworks for testing serialization.
As first step I've updated 'security' framework. The updated framework
searches and loads resource files according [1] and eliminates
requirement
to extend SerializationTest. Also to provide smooth frameworks merging
I've
put stub to let the framework search resources in the 'old' way (i.e. via
RESOURCE_DIR system property). The stub will be removed after
completing
the merge.
The updated framework suggests the following way for testing
serialization:
a) Compatibility – 4 new static methods are introduced.
verifyGolden(TestCase, Object)
I suppose the TestCase is used to locate the golden file, i.e.
BlablaTest will load BlablaTest.golden.ser?
verifyGolden(TestCase, Object, SerializableAssert)
Is the SerializableAssert a command object? Does it currently exist? if
not, what will it look like?
verifyGolden(TestCase, Object[])
verifyGolden(TestCase, Object[], SerializableAssert)
What's the meaning of Object[]? I guess the Object[i] is compared with
Test.golden.1.ser?
A test should invoke one of above methods, for example,
public void testCompatibility() throws Exception {
SerializationTest.verifyGolden(this, new SomeSerializableClass ());
}
b) Self-testing: the same as for compatibility – there are 4 new static
methods that should be invoked from a test:
verifySelf(TestCase, Object)
verifySelf(Object, SerializableAssert)
verifySelf(TestCase, Object[])
verifySelf(Object[], SerializableAssert)
What's the difference between methods with and without TestCase? Does
this imply if it needs to find persistent serialization files? And why
the methods with TestCase parameter don't need customized
SerializationAssert?
For example,
public void testSelf() throws Exception {
SerializationTest.verifySelf(new SomeSerializableClass(), new
MyComparator());
}
To complete frameworks merging I'd like to suggest the next steps:
2) Reviewing the update and the suggested way for testing
serialization by
the community. Please let me know if it is acceptable and what can be
improved.
3) Replace SerializationTester class with SerializationTest. I'm going to
add more stubs to let existing tests work in the 'old' way.
4) Adjusting existing serialization tests (moving and renaming resource
files, replacing stubs invocation with new methods)
5) Removing stubs.
Thank you, Stepan, it is a really good plan!
Thanks,
Stepan Mishura
Intel Middleware Products Division
[1]
http://incubator.apache.org/harmony/subcomponents/classlibrary/ser_testing.html
--
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Paulex Yang
China Software Development Lab
IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib]native codes layout question(was Re: [classlib][NIO|VMI]JNI 1.4 enhancement on ByteBuffer)
Oliver Deakin 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. I see, I can wait for your reference move:), it doesn't make sense to let you move them again later. 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. Got it, I will try. Thank you very much, Oli! 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 -- 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] Merging frameworks for testing serialization - first step
Hi Paulex,
see answers below
On 6/20/06, Paulex Yang wrote:
Stepan,
Cool! Basically I'm fine with the merging plan, and I'm very interested
in more details, please see my comments below:
Stepan Mishura wrote:
Hi,
I'm going to start merging existing frameworks for testing
serialization.
As first step I've updated 'security' framework. The updated framework
searches and loads resource files according [1] and eliminates
requirement
to extend SerializationTest. Also to provide smooth frameworks merging
I've
put stub to let the framework search resources in the 'old' way (i.e.
via
RESOURCE_DIR system property). The stub will be removed after
completing
the merge.
The updated framework suggests the following way for testing
serialization:
a) Compatibility – 4 new static methods are introduced.
verifyGolden(TestCase, Object)
I suppose the TestCase is used to locate the golden file, i.e.
BlablaTest will load BlablaTest.golden.ser?
Right, it is used to locate the golden file.
verifyGolden(TestCase, Object, SerializableAssert)
Is the SerializableAssert a command object? Does it currently exist? if
not, what will it look like?
verifyGolden(TestCase, Object[])
verifyGolden(TestCase, Object[], SerializableAssert)
What's the meaning of Object[]? I guess the Object[i] is compared with
Test.golden.1.ser?
Right again. So if you have one object to be verified you will use
verifyGolden(TestCase, Object) and if there are several objects to be tested
then you may wish to use verifyGolden(TestCase, Object[]).
A test should invoke one of above methods, for example,
public void testCompatibility() throws Exception {
SerializationTest.verifyGolden(this, new SomeSerializableClass ());
}
b) Self-testing: the same as for compatibility – there are 4 new static
methods that should be invoked from a test:
verifySelf(TestCase, Object)
verifySelf(Object, SerializableAssert)
verifySelf(TestCase, Object[])
verifySelf(Object[], SerializableAssert)
What's the difference between methods with and without TestCase?
The difference is quite simple: in case of TestCase the framework looks up
for an appropriate SerializationAssert. In other words, it is equivalent:
verifySelf(object, defineComparator(test, object));
May be methods with TestCase param are little bit confusing - it is possible
to remove them.
Does this imply if it needs to find persistent serialization files?
No, it doesn't.
And why the methods with TestCase parameter don't need
customized SerializationAssert?
As I wrote above the framework tries to figure out an appropriate
SerializationAssert.
For example,
public void testSelf() throws Exception {
SerializationTest.verifySelf(new SomeSerializableClass(), new
MyComparator());
}
To complete frameworks merging I'd like to suggest the next steps:
2) Reviewing the update and the suggested way for testing
serialization by
the community. Please let me know if it is acceptable and what can be
improved.
3) Replace SerializationTester class with SerializationTest. I'm going
to
add more stubs to let existing tests work in the 'old' way.
4) Adjusting existing serialization tests (moving and renaming resource
files, replacing stubs invocation with new methods)
5) Removing stubs.
Thank you, Stepan, it is a really good plan!
Thank you for your feedback.
- Stepan
--
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][luni-util]Scanner completion(was Re: [jira] Closed: (HARMONY-567) [classlib][luni]java.util.Scanner constructors not implemented)
Hello Paulex, I will start to implement the constructor and some simple methods such as ioException(), locale(), etc. Then I'm going to implement the methods from j.u.Iterator. At last, I will touch the pattern matching methods. Really, as you said, the complexity is far beyond my anticipation. ;-) Richard Liang wrote: Paulex Yang wrote: Ah, thank you, Richard, I modified the topic a little to make it more clear. You are right that I'm not working on Scanner, I created two patches related to Scanner just because some other modules needed a skeleton to compile. I'm a little distracted in NIO stuffs, further I owed some parts of j.u.Formatter(I'm frustrating on the facts that RI shows different behavior on java.text.DateFormat/NumberFormat and Formatter.format() for number/date, so it's more complex than I expected). So please feel free to complete the Scanner implementation, thank you. And please shout if you need help because it is a big stuff. Great. I'm sure I will need your a lots help. :-)Thank you in advance. BTW, I have an issue related to Scanner here, I had a look at the Scanner's document before, and I found there is some possibilities to make its implementation easier: Scanner has a match() method, which returns a MatchResult for last scanning operation, further, the MatchResult contains the actual regular expressions Scanner used for various type(digit, decimal, etc) and can be got by Matcher.pattern().toString(), so I wonder if it is permitted in legal for us to use RI's regular express directly in Harmony's Scanner? If so, it is much easier to make Scanner compatible with RI. How do you(and others) think about it? IMHO, we can use the *regular expression* because they are returned by public API. Any comments? Thanks a lot. Richard Liang wrote: Hello Paulex, I'm implementing some SMALL methods for j.u.Scanner, and I find there's a defect in its Constructor. It seems that you're focusing on NIO development. Do you still working on j.u.Scanner? If no, I'd like to provide patch for it. :-) Richard. [1] http://issues.apache.org/jira/browse/HARMONY-611 Mikhail Loenko (JIRA) wrote: [ http://issues.apache.org/jira/browse/HARMONY-567?page=all ] Mikhail Loenko closed HARMONY-567: -- verified by Paulex [classlib][luni]java.util.Scanner constructors not implemented -- Key: HARMONY-567 URL: http://issues.apache.org/jira/browse/HARMONY-567 Project: Harmony Type: Bug Components: Classlib Reporter: Paulex Yang Assignee: Mikhail Loenko Priority: Minor Attachments: 01.harmony567.diff, 02.harmony567.sh, ScannerTest.java Because of its big size, I'll try to implement Scanner in several steps, one JIRA/patch per step. Here goes the first one except the skeleton, the implementation of constructors. I'll attach patch soon. -- Richard Liang China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Eclipse Plug-in Dependencies not resolving
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]
Re: [jira] Created: (HARMONY-606) java.util.regex.Pattern fails to compile some patterns
Dear All,
I find this bug when preparing for implementing j.u.Scanner. Could
anyone have a look at this issue? Thanks a lot.
Richard Liang (JIRA) wrote:
java.util.regex.Pattern fails to compile some patterns
--
Key: HARMONY-606
URL: http://issues.apache.org/jira/browse/HARMONY-606
Project: Harmony
Type: Bug
Components: Classlib
Reporter: Richard Liang
Hello,
The following patterns are not supported by Harmony java.util.regex.Pattern:
\p{javaLowerCase}
\p{javaUpperCase}
\p{javaWhitespace}
\p{javaMirrored}
The test case fails on Harmony, but pass on RI.
public void test_compile() {
Pattern pattern = Pattern.compile(\\p{javaLowerCase}); //$NON-NLS-1$
assertNotNull(pattern);
}
Best regards,
Richard
--
Richard Liang
China Software Development Lab, IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][nio]NIO project cannot compile in Eclipse(Re: svn commit: r415333 ...)
Hi Paulex,
Sorry about that. Requested change made in revision 415600.
Best regards,
George
Paulex Yang wrote:
George,
nio project cannot compile in my Eclipse after this revision, seems
the MANIFEST.MF needs to add tests.util to Import-Package section as
below, would you please have a look? thank you very much!
- tests.support;resolution:=optional;hy_usage=test
+ tests.support;resolution:=optional;hy_usage=test,
+ tests.util;resolution:=optional;hy_usage=test
[EMAIL PROTECTED] wrote:
Author: gharley
Date: Mon Jun 19 07:04:04 2006
New Revision: 415333
URL: http://svn.apache.org/viewvc?rev=415333view=rev
Log:
HARMONY-620 : Tests for java.nio.BufferOverflowException are missing
Added:
incubator/harmony/enhanced/classlib/trunk/modules/nio/src/test/java/org/apache/harmony/tests/java/nio/BufferOverflowExceptionTest.java
(with props)
incubator/harmony/enhanced/classlib/trunk/modules/nio/src/test/resources/serialization/
incubator/harmony/enhanced/classlib/trunk/modules/nio/src/test/resources/serialization/java/
incubator/harmony/enhanced/classlib/trunk/modules/nio/src/test/resources/serialization/java/nio/
incubator/harmony/enhanced/classlib/trunk/modules/nio/src/test/resources/serialization/java/nio/BufferOverflowException.golden.ser
(with props)
Modified:
incubator/harmony/enhanced/classlib/trunk/modules/nio/make/common/build.xml
incubator/harmony/enhanced/classlib/trunk/modules/nio/src/test/java/org/apache/harmony/tests/java/nio/AllTests.java
Modified:
incubator/harmony/enhanced/classlib/trunk/modules/nio/make/common/build.xml
URL:
http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/modules/nio/make/common/build.xml?rev=415333r1=415332r2=415333view=diff
==
---
incubator/harmony/enhanced/classlib/trunk/modules/nio/make/common/build.xml
(original)
+++
incubator/harmony/enhanced/classlib/trunk/modules/nio/make/common/build.xml
Mon Jun 19 07:04:04 2006
@@ -46,7 +46,7 @@
/target
-target name=compile.tests
+target name=compile.tests depends=copy.test.resources
echo message=Compiling NIO tests from
${hy.nio.src.test.java} /
mkdir dir=${hy.nio.bin.test} /
@@ -121,5 +121,15 @@
target name=copy.resources
!-- Nothing for NIO --
/target
+
+target name=copy.test.resources
+mkdir dir=${hy.nio.bin.test} /
+copy todir=${hy.nio.bin.test} includeemptydirs=false
+fileset dir=${hy.nio.src.test.resources}
+exclude name=**/*.java /
+/fileset
+/copy
+/target
+
/project
Modified:
incubator/harmony/enhanced/classlib/trunk/modules/nio/src/test/java/org/apache/harmony/tests/java/nio/AllTests.java
URL:
http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/modules/nio/src/test/java/org/apache/harmony/tests/java/nio/AllTests.java?rev=415333r1=415332r2=415333view=diff
==
---
incubator/harmony/enhanced/classlib/trunk/modules/nio/src/test/java/org/apache/harmony/tests/java/nio/AllTests.java
(original)
+++
incubator/harmony/enhanced/classlib/trunk/modules/nio/src/test/java/org/apache/harmony/tests/java/nio/AllTests.java
Mon Jun 19 07:04:04 2006
@@ -31,6 +31,7 @@
public static Test suite() {
TestSuite suite = new TestSuite(Tests for java.nio);
// $JUnit-BEGIN$
+suite.addTestSuite(BufferOverflowExceptionTest.class);
suite.addTestSuite(BufferTest.class);
suite.addTestSuite(ByteBufferTest.class);
suite.addTestSuite(ByteOrderTest.class);
Added:
incubator/harmony/enhanced/classlib/trunk/modules/nio/src/test/java/org/apache/harmony/tests/java/nio/BufferOverflowExceptionTest.java
URL:
http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/modules/nio/src/test/java/org/apache/harmony/tests/java/nio/BufferOverflowExceptionTest.java?rev=415333view=auto
==
---
incubator/harmony/enhanced/classlib/trunk/modules/nio/src/test/java/org/apache/harmony/tests/java/nio/BufferOverflowExceptionTest.java
(added)
+++
incubator/harmony/enhanced/classlib/trunk/modules/nio/src/test/java/org/apache/harmony/tests/java/nio/BufferOverflowExceptionTest.java
Mon Jun 19 07:04:04 2006
@@ -0,0 +1,45 @@
+/* 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
Re: [classlib][nio]NIO project cannot compile in Eclipse(Re: svn commit: r415333 ...)
George,
It works now, thank you!
George Harley wrote:
Hi Paulex,
Sorry about that. Requested change made in revision 415600.
Best regards,
George
Paulex Yang wrote:
George,
nio project cannot compile in my Eclipse after this revision, seems
the MANIFEST.MF needs to add tests.util to Import-Package section
as below, would you please have a look? thank you very much!
- tests.support;resolution:=optional;hy_usage=test
+ tests.support;resolution:=optional;hy_usage=test,
+ tests.util;resolution:=optional;hy_usage=test
[EMAIL PROTECTED] wrote:
Author: gharley
Date: Mon Jun 19 07:04:04 2006
New Revision: 415333
URL: http://svn.apache.org/viewvc?rev=415333view=rev
Log:
HARMONY-620 : Tests for java.nio.BufferOverflowException are missing
Added:
incubator/harmony/enhanced/classlib/trunk/modules/nio/src/test/java/org/apache/harmony/tests/java/nio/BufferOverflowExceptionTest.java
(with props)
incubator/harmony/enhanced/classlib/trunk/modules/nio/src/test/resources/serialization/
incubator/harmony/enhanced/classlib/trunk/modules/nio/src/test/resources/serialization/java/
incubator/harmony/enhanced/classlib/trunk/modules/nio/src/test/resources/serialization/java/nio/
incubator/harmony/enhanced/classlib/trunk/modules/nio/src/test/resources/serialization/java/nio/BufferOverflowException.golden.ser
(with props)
Modified:
incubator/harmony/enhanced/classlib/trunk/modules/nio/make/common/build.xml
incubator/harmony/enhanced/classlib/trunk/modules/nio/src/test/java/org/apache/harmony/tests/java/nio/AllTests.java
Modified:
incubator/harmony/enhanced/classlib/trunk/modules/nio/make/common/build.xml
URL:
http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/modules/nio/make/common/build.xml?rev=415333r1=415332r2=415333view=diff
==
---
incubator/harmony/enhanced/classlib/trunk/modules/nio/make/common/build.xml
(original)
+++
incubator/harmony/enhanced/classlib/trunk/modules/nio/make/common/build.xml
Mon Jun 19 07:04:04 2006
@@ -46,7 +46,7 @@
/target
-target name=compile.tests
+target name=compile.tests depends=copy.test.resources
echo message=Compiling NIO tests from
${hy.nio.src.test.java} /
mkdir dir=${hy.nio.bin.test} /
@@ -121,5 +121,15 @@
target name=copy.resources
!-- Nothing for NIO --
/target
+ +target name=copy.test.resources
+mkdir dir=${hy.nio.bin.test} /
+copy todir=${hy.nio.bin.test} includeemptydirs=false
+fileset dir=${hy.nio.src.test.resources}
+exclude name=**/*.java /
+/fileset
+/copy
+/target
+/project
Modified:
incubator/harmony/enhanced/classlib/trunk/modules/nio/src/test/java/org/apache/harmony/tests/java/nio/AllTests.java
URL:
http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/modules/nio/src/test/java/org/apache/harmony/tests/java/nio/AllTests.java?rev=415333r1=415332r2=415333view=diff
==
---
incubator/harmony/enhanced/classlib/trunk/modules/nio/src/test/java/org/apache/harmony/tests/java/nio/AllTests.java
(original)
+++
incubator/harmony/enhanced/classlib/trunk/modules/nio/src/test/java/org/apache/harmony/tests/java/nio/AllTests.java
Mon Jun 19 07:04:04 2006
@@ -31,6 +31,7 @@
public static Test suite() {
TestSuite suite = new TestSuite(Tests for java.nio);
// $JUnit-BEGIN$
+suite.addTestSuite(BufferOverflowExceptionTest.class);
suite.addTestSuite(BufferTest.class);
suite.addTestSuite(ByteBufferTest.class);
suite.addTestSuite(ByteOrderTest.class);
Added:
incubator/harmony/enhanced/classlib/trunk/modules/nio/src/test/java/org/apache/harmony/tests/java/nio/BufferOverflowExceptionTest.java
URL:
http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/modules/nio/src/test/java/org/apache/harmony/tests/java/nio/BufferOverflowExceptionTest.java?rev=415333view=auto
==
---
incubator/harmony/enhanced/classlib/trunk/modules/nio/src/test/java/org/apache/harmony/tests/java/nio/BufferOverflowExceptionTest.java
(added)
+++
incubator/harmony/enhanced/classlib/trunk/modules/nio/src/test/java/org/apache/harmony/tests/java/nio/BufferOverflowExceptionTest.java
Mon Jun 19 07:04:04 2006
@@ -0,0 +1,45 @@
+/* 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
Re: [drlvm] linking question
splendid. Thanks Mark Hindess wrote: On 20 June 2006 at 1:05, Geir Magnusson Jr [EMAIL PROTECTED] wrote: I've been puttering about and am having a problem under linux. Everything builds now, and APR is built using the standard ./configure make combination. No big deal. But I seem to have a linking problem - libvmi.so gets built w/o things like pool_* entries resolved. I do believe that I'm pointing the linker at the right files in /classlib via vmi.xml via libset. I think I'm right as when I tweak the lib name, say from hypool to hypoolwoogie the build complains. But still - libvmi.so on my box is made w/o those deps. Given that the cc and linker ant tasks are black magic to me, how does one figure this out? can you make cc tell you want it's doing? I have no idea what it's using to link, for example, and what the invocation of the linker is in terms of flags and args. Any help appreciated... Does: ANT_ARGS=-v sh build.sh give you enough information? -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: [drlvm] linking question
Thanks!
Yes, that solved is.
Marina Goldburt wrote:
Hi,
The problem is in the order of the linked libs. the order is important for
gcc.
Change components/vm/vmi, the order must be:
libset libs=hyzip dir=${external.dep.CLASSLIB.libdir} /
libset libs=hypool dir=${external.dep.CLASSLIB.libdir} /
libset libs=hyprt dir=${external.dep.CLASSLIB.libdir} /
Marina
On 6/20/06, Mark Hindess [EMAIL PROTECTED] wrote:
On 20 June 2006 at 1:05, Geir Magnusson Jr [EMAIL PROTECTED] wrote:
I've been puttering about and am having a problem under linux.
Everything builds now, and APR is built using the standard
./configure
make combination. No big deal.
But I seem to have a linking problem - libvmi.so gets built w/o things
like pool_* entries resolved. I do believe that I'm pointing the
linker
at the right files in /classlib via vmi.xml via libset. I think I'm
right as when I tweak the lib name, say from hypool to hypoolwoogie
the build complains.
But still - libvmi.so on my box is made w/o those deps.
Given that the cc and linker ant tasks are black magic to me, how
does one figure this out? can you make cc tell you want it's doing?
I have no idea what it's using to link, for example, and what the
invocation of the linker is in terms of flags and args.
Any help appreciated...
Does:
ANT_ARGS=-v sh build.sh
give you enough information?
-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: [doc] [VM] have useful info on how to debug DRLVM Jitrino
Geir, There's some rather straight-forward stuff to do in Eclipse plus some less trivial config options description and some debug scenarios. I hope the info can be of help to you. I know it's hard to believe, but what about if someone isn't using eclipse? ;) The doc has some scenarios with gdb as well. Hope this helps. If you have it, how about posting as a JIRA in whatever form it is now so we can read it, and then try to make a patch to the harmony site, incorporating whatever feedback people throw at you (on this list). Done. Posted a JIRA issue - 626. You can now see the doc attached there. Does not look too nice - no style sheet - but readable. Cheers, Nadya - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][testing]resource files: location and usage
described on testing and serialization convention pages. Yes, it'll be useful. But currently few resource files follow conventions Not only resource files. The Testing convention document (testing.html) says: 1) Tests, their resources, and support classes are located under modulename/src/tests but actually they are located under modulename/src/test In this case seems the document should be updated. 2) document says: modulename/src/tests/api - Implementation-independent tests but many modules miss this level and define 'classpath tests' on this level. In this case tests should be relocated. Anyway, when one is not sure whether or not he puts the tests correctly, he can just run the script and receive all warnings. Thanks, Vladimir On 6/20/06, Stepan Mishura [EMAIL PROTECTED] wrote: On 6/20/06, Vladimir Ivanov wrote: Thanks Stepan, 1. The decision about other resource files is: they should be stored into src/test/resources/ without further naming convention. Right? – then, a) Ideally, can we specify further (after src/test/resources/) naming convention for resource files as it is done for serialization files? Resource files for testing serialization is the first case. To work out further conventions we should at least understand what kinds of resource files are required for testing. For example, we may agree that resource files for net-based tests should be put separately in 'net' sub-folder. And I'd suggest to put all other resources into 'other' folder (i.esrc/test/resources/other). b) At least, specify that resource file name should contain test name – for easy resource file search? Agree. c) Shouldn't we move content of trunk/support/ into corresponding module's src/test/resources/ directories? – if yes, I can do it. No. IIRC we agreed to move 'things' used across different modules to trunk/support/. 2. Can we add a link to the http://incubator.apache.org/harmony/subcomponents/classlibrary/ser_testing.htmldocument at the testing page? Sure. I want to create a script which checks that tests are stored as it is described on testing and serialization convention pages. Yes, it'll be useful. But currently few resource files follow conventions :-) Thanks, Stepan. Thanks, Vladimir On 6/19/06, Stepan Mishura [EMAIL PROTECTED] wrote: On 6/19/06, Vladimir Ivanov wrote: It would be good if the page http://incubator.apache.org/harmony/subcomponents/classlibrary/testing.htmldescribes also location, name convention and access model for resource files used for testing, specifically, for testing serialization. At the present moment test's resource files stored in src/test/resources directory in modules structure. Serialization data stored as resources/ + serialization/ + package name or resources/ + package name + /serialization/ with .ser or .dat extension. Other resource files are stored in resources/ or in the resources/package name directory. I found two mechanisms of accessing resources in tests: 1) Get resource through ClassLoader.getResource (serialization/package name) 2) Get resource through reading file System.getProperty(RESOURCE_DIR + filename). Hi Vladimir, The second mechanismis used in 'security' testing framework (used by auth/crypto/security/x-net modules). We are agreed to merge two existing framework for testing serialization. Currently I'm preparing update for the 'security' framework - it will replace the second mechanism it with the first. Suggestion: 1) Ideal from my point of view variant: lets uniform access to resources throughout all tests (I can do it). Agreed. We should work out uniform access to resources. IIRC we agreed to access *all* resources via classpath. 2) If it's not good idea, then, lets just describe technique of working with resources on testing conventions page to limit the number of access techniques to only two (I can do it). Thoughts? see [1] for name conventions for serialization resource files. Thanks, Stepan. [1] http://incubator.apache.org/harmony/subcomponents/classlibrary/ser_testing.html -- 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-606) java.util.regex.Pattern fails to compile some patterns
Hello Richard, Thank you for this find. For some reason I've missed these character classes. Will update JIRA issue in a moment. -- Regards, Nikolay Kuznetsov, Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][java.math]performance improvement for java.math package
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 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 Ops/sec for subtract method of BigInteger Number Current fixed one of digits version 2 39204394 4 33003302 8 51785640 12 957 913 16 37942904 24 20571962 32 34213241 48 34692828 64 652 610 128 23182246 === Unfortunately we haven't look thoroughly to ITC contribution, so it may happen that some of the optimizations described in this letter were already implemented there. Daniel, could you please consider our new implementation when you start to merge implementations math packages. If optimization methods described above already have been implemented in ITC contribution it will be great to compare internal representation of BigInteger and try to measure affect of different approaches. On 6/2/06, Vladimir Strigun (JIRA) [EMAIL PROTECTED] wrote: [ http://issues.apache.org/jira/browse/HARMONY-551?page=all ] Vladimir Strigun updated HARMONY-551:
Re: [classlib] [build] Precompiled libraries (was: awt and swing integration issues)
Alexey Petrenko wrote: 2006/6/20, Geir Magnusson Jr [EMAIL PROTECTED]: We don't want to do that, distribute third party code that we build. But as far as I understand we will do that... HDK will include this libraries. Isn't it? We will include third party libraries that are build and released by a third party, yes. Therefore, there is no need to host that stuff. geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][testing]resource files: location and usage
2006/6/20, Vladimir Ivanov [EMAIL PROTECTED]: Thanks Stepan, 1. The decision about other resource files is: they should be stored into src/test/resources/ without further naming convention. Right? – then, a) Ideally, can we specify further (after src/test/resources/) naming convention for resource files as it is done for serialization files? b) At least, specify that resource file name should contain test name – for easy resource file search? It does not work well. Single resource might be used by many tests c) Shouldn't we move content of trunk/support/ into corresponding module's src/test/resources/ directories? – if yes, I can do it. +1 It smells like we already discussed that and agreed to distribute trunk/support between modules. not sure. Thanks, Mikhail 2. Can we add a link to the http://incubator.apache.org/harmony/subcomponents/classlibrary/ser_testing.htmldocument at the testing page? I want to create a script which checks that tests are stored as it is described on testing and serialization convention pages. Thanks, Vladimir On 6/19/06, Stepan Mishura [EMAIL PROTECTED] wrote: On 6/19/06, Vladimir Ivanov wrote: It would be good if the page http://incubator.apache.org/harmony/subcomponents/classlibrary/testing.htmldescribes also location, name convention and access model for resource files used for testing, specifically, for testing serialization. At the present moment test's resource files stored in src/test/resources directory in modules structure. Serialization data stored as resources/ + serialization/ + package name or resources/ + package name + /serialization/ with .ser or .dat extension. Other resource files are stored in resources/ or in the resources/package name directory. I found two mechanisms of accessing resources in tests: 1) Get resource through ClassLoader.getResource(serialization/package name) 2) Get resource through reading file System.getProperty(RESOURCE_DIR + filename). Hi Vladimir, The second mechanismis used in 'security' testing framework (used by auth/crypto/security/x-net modules). We are agreed to merge two existing framework for testing serialization. Currently I'm preparing update for the 'security' framework - it will replace the second mechanism it with the first. Suggestion: 1) Ideal from my point of view variant: lets uniform access to resources throughout all tests (I can do it). Agreed. We should work out uniform access to resources. IIRC we agreed to access *all* resources via classpath. 2) If it's not good idea, then, lets just describe technique of working with resources on testing conventions page to limit the number of access techniques to only two (I can do it). Thoughts? see [1] for name conventions for serialization resource files. Thanks, Stepan. [1] http://incubator.apache.org/harmony/subcomponents/classlibrary/ser_testing.html -- 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] build works on linux
I now have drlvm working w/ independent classlib and configure/make building of APR on linux. I had a lot of fun working through a lot of the gcc issues that others have. It was a good refresher course for me. It's working on Ubuntu 6.whatever using gcc/g++ version 3.4 and Sun's java 5. I can now continue the federated build stuff I was doing last week, and will keep removing the self-hosted dependencies, and use properties to point to them, like APR. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[drlvm] what's next?
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? geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][testing]resource files: location and usage
2006/6/20, Vladimir Ivanov [EMAIL PROTECTED]: described on testing and serialization convention pages. Yes, it'll be useful. But currently few resource files follow conventions Not only resource files. The Testing convention document (testing.html) says: 1) Tests, their resources, and support classes are located under modulename/src/tests but actually they are located under modulename/src/test In this case seems the document should be updated. thanks! fixed. 2) document says: modulename/src/tests/api - Implementation-independent tests but many modules miss this level and define 'classpath tests' on this level. In this case tests should be relocated. Not necessarily. the doc says: This document provides general guidlines and recomendations that might be adapted/modified to reflect module specifics So if a module does not have some type of tests or platform division it might skip extra folders Thanks, Mikhail Anyway, when one is not sure whether or not he puts the tests correctly, he can just run the script and receive all warnings. Thanks, Vladimir On 6/20/06, Stepan Mishura [EMAIL PROTECTED] wrote: On 6/20/06, Vladimir Ivanov wrote: Thanks Stepan, 1. The decision about other resource files is: they should be stored into src/test/resources/ without further naming convention. Right? – then, a) Ideally, can we specify further (after src/test/resources/) naming convention for resource files as it is done for serialization files? Resource files for testing serialization is the first case. To work out further conventions we should at least understand what kinds of resource files are required for testing. For example, we may agree that resource files for net-based tests should be put separately in 'net' sub-folder. And I'd suggest to put all other resources into 'other' folder (i.esrc/test/resources/other). b) At least, specify that resource file name should contain test name – for easy resource file search? Agree. c) Shouldn't we move content of trunk/support/ into corresponding module's src/test/resources/ directories? – if yes, I can do it. No. IIRC we agreed to move 'things' used across different modules to trunk/support/. 2. Can we add a link to the http://incubator.apache.org/harmony/subcomponents/classlibrary/ser_testing.htmldocument at the testing page? Sure. I want to create a script which checks that tests are stored as it is described on testing and serialization convention pages. Yes, it'll be useful. But currently few resource files follow conventions :-) Thanks, Stepan. Thanks, Vladimir On 6/19/06, Stepan Mishura [EMAIL PROTECTED] wrote: On 6/19/06, Vladimir Ivanov wrote: It would be good if the page http://incubator.apache.org/harmony/subcomponents/classlibrary/testing.htmldescribes also location, name convention and access model for resource files used for testing, specifically, for testing serialization. At the present moment test's resource files stored in src/test/resources directory in modules structure. Serialization data stored as resources/ + serialization/ + package name or resources/ + package name + /serialization/ with .ser or .dat extension. Other resource files are stored in resources/ or in the resources/package name directory. I found two mechanisms of accessing resources in tests: 1) Get resource through ClassLoader.getResource (serialization/package name) 2) Get resource through reading file System.getProperty(RESOURCE_DIR + filename). Hi Vladimir, The second mechanismis used in 'security' testing framework (used by auth/crypto/security/x-net modules). We are agreed to merge two existing framework for testing serialization. Currently I'm preparing update for the 'security' framework - it will replace the second mechanism it with the first. Suggestion: 1) Ideal from my point of view variant: lets uniform access to resources throughout all tests (I can do it). Agreed. We should work out uniform access to resources. IIRC we agreed to access *all* resources via classpath. 2) If it's not good idea, then, lets just describe technique of working with resources on testing conventions page to limit the number of access techniques to only two (I can do it). Thoughts? see [1] for name conventions for serialization resource files. Thanks, Stepan. [1] http://incubator.apache.org/harmony/subcomponents/classlibrary/ser_testing.html -- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Terms of use :
Re: [classlib][testing]resource files: location and usage
Indeed, unless you are extremely paranoid that all the other API implementations wrong, but are conspiring to make your test pass then you should assume that everything else is working ok and you are testing some specific piece of functionality. Why should we have gold files then? Let's imagine we test deserialization. According to your proposal - we suppose that serialization works fine then. Let's serialize something in a file or an array, deserialize and compare - if non-transient fields are equal, it's OK. I suggest to trust only resources created outside Harmony VM - for example, created by Java executed in RI, application on any other language but Java or taken from SVN. Only paranoids survive :) -- 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]
[general] milestones and roadmap
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]
Re: [general] milestones and roadmap
2006/6/20, Geir Magnusson Jr [EMAIL PROTECTED]: I'd like to start assembling a high-level roadmap of the milestones we'd like to achieve in the next 12 months. I volunteer to track and organize, but this clearly is a community activity so lets start by just tossing out ideas. 1) By ApcheCon EU - a combined snapshot that is a pure open source VM + classlib. Issues - I assume we'll use DRLVM. 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? :) 10) Develop and execute test infrastructure: stability, reliability, stress, performance, whatever tests. Regular runs on various platforms geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] milestones and roadmap
11) em64t/ipf platform support On 6/20/06, Mikhail Loenko [EMAIL PROTECTED] wrote: 2006/6/20, Geir Magnusson Jr [EMAIL PROTECTED]: I'd like to start assembling a high-level roadmap of the milestones we'd like to achieve in the next 12 months. I volunteer to track and organize, but this clearly is a community activity so lets start by just tossing out ideas. 1) By ApcheCon EU - a combined snapshot that is a pure open source VM + classlib. Issues - I assume we'll use DRLVM. 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? :) 10) Develop and execute test infrastructure: stability, reliability, stress, performance, whatever tests. Regular runs on various platforms geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] milestones and roadmap
On 20 June 2006 at 19:24, Mikhail Loenko [EMAIL PROTECTED] wrote: 2006/6/20, Geir Magnusson Jr [EMAIL PROTECTED]: I'd like to start assembling a high-level roadmap of the milestones we'd like to achieve in the next 12 months. I volunteer to track and organize, but this clearly is a community activity so lets start by just tossing out ideas. 1) By ApcheCon EU - a combined snapshot that is a pure open source VM + classlib. Issues - I assume we'll use DRLVM. 1.5) Reduce classlib code to one implementation per module. 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? :) 10) Develop and execute test infrastructure: stability, reliability, stress, performance, whatever tests. Regular runs on various platforms 11) Use system libraries, dynamically where appropriate - libz, libpng, libjpeg, liblcms, libicu*, etc. 12) Port to a 64bit little endian platform - amd64 13) Port to a 64bit big endian platform - ppc64 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][java.math]performance improvement for java.math package
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 Ops/sec for subtract method of BigInteger Number Current fixed one of digits version 2 39204394 4 33003302 8 51785640 12 957 913 16 37942904 24 20571962 32 34213241 48 34692828 64 652 610 128 23182246 === Unfortunately we haven't look thoroughly to ITC contribution, so it may happen that some of the optimizations described in this letter were already implemented there. Daniel, could you please consider our new implementation when you start to merge implementations math packages. If optimization methods described above already have been
Re: [apps] azureus (was Re: [testing] AWT, Swing Java2D)
Great progress - it started and looks similar to Azureus launched on RI. Unfortunately I'm behind a firewall so I can't test it fully (and, frankly speaking, I've never used it before I tried to run it on Harmony so I don't know for sure how to use it properly :) ) -- 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?]
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. I'm still curious what mechanism will be used to wakeup blocked threads though. -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: [apps] azureus (was Re: [testing] AWT, Swing Java2D)
Anton Luht wrote: Great progress - it started and looks similar to Azureus launched on RI. Unfortunately I'm behind a firewall so I can't test it fully (and, frankly speaking, I've never used it before I tried to run it on Harmony so I don't know for sure how to use it properly :) ) Cool -- can't wait to try it. Did you have to hack any of the Azureus code assumptions to get it working? (i.e. BKS or HARMONY-536 JSSE provider) 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: Eclipse Plug-in Dependencies not resolving
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] -- 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)
Cool -- can't wait to try it. Did you have to hack any of the Azureus code assumptions to get it working? (i.e. BKS or HARMONY-536 JSSE provider) No, I just ran it 'as is' - old errors are in place: DEBUG::Tue Jun 20 18:25:02 MSD 2006::org.gudy.azureus2.core3.security.impl.SESecurityManagerImpl::initialise::137: No SSL provider available SESecurityManager::initialise::52,ConfigurationChecker::setSystemProperties::141,ConfigurationManager::initialise::138,ConfigurationManager::getInstance::71,LoggerImpl::init::90,Logger::clinit::48,J9VMInternals::initializeImpl::-2,J9VMInternals::initialize::185,StartServer::init::69,Main::init::56,Main::main::162 DEBUG::Tue Jun 20 18:25:02 MSD 2006::org.gudy.azureus2.core3.security.impl.SESecurityManagerImpl::ensureStoreExists::408: java.security.KeyStoreException: KeyStore JKS implementation not found -- 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: 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]
Re: svn commit: r415632 - /incubator/harmony/enhanced/classlib/trunk/modules/accessibility/bin/
Oops. Thanks Tim. And thanks for fixing up my Eclipse/MANIFEST mess. I'll try a little harder with my cut'n'paste creation of these next time. I wonder if we can add tests to the builds to catch these problems? Regards, Mark. On 20 June 2006 at 13:19, [EMAIL PROTECTED] wrote: Author: tellison Date: Tue Jun 20 06:19:18 2006 New Revision: 415632 URL: http://svn.apache.org/viewvc?rev=415632view=rev Log: Do not put accessibility/bin dir under version control. Removed: incubator/harmony/enhanced/classlib/trunk/modules/accessibility/bin/ - 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?
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 * higher performance: VM, JIT, GC Personally, I am going to look into following areas (in order) - extend JVMTI support in DRLVM: Heap group of functions. I have some code working already, but not yet ready for filing JIRA with patch yet. - play with class unloading and see what are the design consequences - then do a generational garbage collector (from scratch) I looked into this a little bit, but not quite sure when I'll be able to get something working. - 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
2006/6/20, Mark Hindess [EMAIL PROTECTED]: On 20 June 2006 at 19:24, Mikhail Loenko [EMAIL PROTECTED] wrote: 2006/6/20, Geir Magnusson Jr [EMAIL PROTECTED]: I'd like to start assembling a high-level roadmap of the milestones we'd like to achieve in the next 12 months. I volunteer to track and organize, but this clearly is a community activity so lets start by just tossing out ideas. 1) By ApcheCon EU - a combined snapshot that is a pure open source VM + classlib. Issues - I assume we'll use DRLVM. 1.5) Reduce classlib code to one implementation per module. 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? :) 10) Develop and execute test infrastructure: stability, reliability, stress, performance, whatever tests. Regular runs on various platforms 11) Use system libraries, dynamically where appropriate - libz, libpng, libjpeg, liblcms, libicu*, etc. 12) Port to a 64bit little endian platform - amd64 13) Port to a 64bit big endian platform - ppc64 14) Port to em64t platform (Lost from Marina's letter) 15) Port to ipf platform (Lost from Marina's letter) 16) Port to MacOS X It looks like roadmap for longer then 12 months period ;) -- Alexey A. Petrenko Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] what's next?
On 6/20/06, Geir Magnusson Jr [EMAIL PROTECTED] 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? 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. Another thing that needs to happen in DRLVM is a well designed VM-JIT-GC synchronization protocol. Clear, understandable system-wide synch protocol will be very nice to have when we get to the point of advanced threading module. This really does not exist today. If there is interest, I could start a harmony-dev email thread on this topic. geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Weldon Washburn Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] milestones and roadmap
On 20 June 2006 at 20:19, Alexey Petrenko [EMAIL PROTECTED] wrote: 2006/6/20, Mark Hindess [EMAIL PROTECTED]: On 20 June 2006 at 19:24, Mikhail Loenko [EMAIL PROTECTED] wrote: 2006/6/20, Geir Magnusson Jr [EMAIL PROTECTED]: I'd like to start assembling a high-level roadmap of the milestones we' d like to achieve in the next 12 months. I volunteer to track and organize, but this clearly is a community activity so lets start by just tossing out ideas. 1) By ApcheCon EU - a combined snapshot that is a pure open source VM + classlib. Issues - I assume we'll use DRLVM. 1.5) Reduce classlib code to one implementation per module. 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 w e need to start enhancing that with Java 5 features. What else? :) 10) Develop and execute test infrastructure: stability, reliability, stress, performance, whatever tests. Regular runs on various platforms 11) Use system libraries, dynamically where appropriate - libz, libpng, libjpeg, liblcms, libicu*, etc. 12) Port to a 64bit little endian platform - amd64 13) Port to a 64bit big endian platform - ppc64 14) Port to em64t platform (Lost from Marina's letter) Isn't this the same thing as 12? Or perhaps I'm missing something? 15) Port to ipf platform (Lost from Marina's letter) 16) Port to MacOS X This could be the same as 13 but I was thinking of linux/ppc64. MacOSX would be more interesting but I think it makes sense to change one aspect of the platform at a time. So you are right to make this a separate item. It looks like roadmap for longer then 12 months period ;) Maybe, but who would have thought we'd have got this far in (a little over) 12 months? 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: [general] milestones and roadmap
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? :) 0) port on macosx so that the other half of the devs on this list can do something -- Stefano. - 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)
Anton Luht wrote: Great progress - it started and looks similar to Azureus launched on RI. Unfortunately I'm behind a firewall so I can't test it fully (and, frankly speaking, I've never used it before I tried to run it on Harmony so I don't know for sure how to use it properly :) ) Azureus is probably one of the most stressing software for the JVM, network-wise and graphically-wise. The graphical part is handled by SWT so it's not really much for us, but the network part, especially the multiple UDP/TCP shuffling and tons of established network connections and files opened is critical. Also, the fact that you normally let it run for days if not weeks creates a huge challenge for the JVM for memory leaks, OS resource cleanups and the like. I recently tried Azureus on Ubuntu6 with the GCJ that comes with it and it kept giving me NullPointerExceptions after a day or so of continuous operation, so I installed sun's java5 and it worked like a charm. 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. -- Stefano. - 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
-Original Message- From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 20, 2006 1:16 PM To: harmony-dev@incubator.apache.org Subject: Re: [general] milestones and roadmap 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. [SNIP] What else? :) 0) port on macosx so that the other half of the devs on this list can do something As our mutual old friend Jon used to say Thanks for volunteering! :) 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: [general] milestones and roadmap
Magnusson, Geir wrote: -Original Message- From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 20, 2006 1:16 PM To: harmony-dev@incubator.apache.org Subject: Re: [general] milestones and roadmap 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. [SNIP] What else? :) 0) port on macosx so that the other half of the devs on this list can do something As our mutual old friend Jon used to say Thanks for volunteering! :) Last time I wrote something in C was around 1993 in highschool using Borland tools on DOS. Not sure you want me to try :-) -- Stefano. - 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
2006/6/20, Mark Hindess [EMAIL PROTECTED]: 16) Port to MacOS X This could be the same as 13 but I was thinking of linux/ppc64. MacOSX would be more interesting but I think it makes sense to change one aspect of the platform at a time. So you are right to make this a separate item. And I was thinking about MacOS X on Intel processors :) So we found one more task: Port to MacOS X on PowerPC... -- Alexey A. Petrenko Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] what's next?
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. -- 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: [general] milestones and roadmap
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: [apps] azureus (was Re: [testing] AWT, Swing Java2D)
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. -- Thorbjørn smime.p7s Description: S/MIME Cryptographic Signature
Pack200 -- can now obtain files stored in archive
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: [drlvm] what's next?
On 6/20/06, Geir Magnusson Jr [EMAIL PROTECTED] 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. Geir, Good question. By next, I guess we mean in the relatively near future...Some thoughts that come to mind in addition to 1.5 are: 1. We should start running classlibraries and existing api tests against the DRLVM bits. This is sure to identify bugs/issues that will need addressing. 2. We need to achieve completeness in the DRLVM VM functionality.we don't handle stack overflows well, efficient unmanagd heap management issues, there is functional completenes needed in the verifier, optimized locks( thin, deflatable, jit optimized ), improvements in JVMTI support as Gregory points out. 3. In garbage collection, one thread that Weldon has already started is MMTk integration which looks promising, but while we finish that work, it may also make sense to substitute the existing rudimentary GC with a more functional one with better performance that can work as the default GC outside the MMTk integrated suite. 4. We should also look at enhancements to the JITs ...and other than support for new platforms ( 64 bit , down level platforms that support x87 but not SSE* instructions..based on the minimum machine model we want to support eg a pentium III running Windows/Linux )some of this work would benefit from performance guidance...helpers should be inlined, some of the optimizations eg., devirtualization perfected, polling to support collection should consume less overhead, more optimized JNI invocation at some point. 5. This is also in reference to the other thread you started about goals for Harmony, it may help to establish some vectors that are important for us in Harmony eg., among...1.5 and TCK compatibility, performance( benchmarking ), startup time, memory footprint, and that in some sense will determine the priorities. The work to be done will fall out of this. Feedback most welcome :-) Thanks, Rana - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: A GC module written in Java for DRLVM
Ming,
I looked at JIRA 622. It looks like there are 22 pages of new
assembly code and about 26 pages of new java code. Perhaps you could
give us a summary of what the assembly code does and why it can't be
done in Java.
Also, I would like to see the code you developed that JITs the GC. It
might make sense to reuse this code for the MMTk port.
Thanks
Weldon
On 6/19/06, Ming Wu [EMAIL PROTECTED] wrote:
We have developed a Java GC with mark-sweep algorithm and integrated it into
the current drlvm code. The key feature is, the GC is not prebuilt into
binary, but loaded and jitted by the VM at runtime. Hopefully it is useful
to the existing efforts porting MMTk to DRLVM. It is actually the rewrite of
gc_mf of drlvm in Java language. It can run some simple Java applications,
but there is some issue with the build environment (different from what we
developed the GC with) that prevents us from running it with reasonable size
Java application. We tried to minimize the change to DRLVM existing code.
We have submitted the Java GC and patch file for VM to
JIRA(HARMONY-622http://issues.apache.org/jira/browse/HARMONY-622).
To run it, one should specify the classpath of the Java GC for the patched
VM, for example:
cd $JAVA_GC_HOME
tar zxvf javagc.tar.gz
ij -classpath ./:$JAVA_GC_HOME/javagc HelloWorld
You can switch the VM GC module back to GC_v4 in the following code
(vmcore/src/init/vm_main.cpp):
static int initialize_gc_component() {
if (0) { //change 0 to 1 to switch to GC_v4
initialize_c_gc_component();
} else {
initialize_java_gc();
}
}
If you want to completely disable this mechanisms of Java GC support in
DRLVM, please change the macro definition of GC_DLL to gc and remove the
invocation to initialize_gc_component in function vm_main.
--
Thanks,
Ming
--
Weldon Washburn
Intel Middleware Products Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] what's next?
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? It would be great if this debugger could be used during the port of MMTk. -- 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] -- Weldon Washburn Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] what's next?
On 6/20/06, Rana Dasgupta [EMAIL PROTECTED] wrote: On 6/20/06, Geir Magnusson Jr [EMAIL PROTECTED] 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. Geir, Good question. By next, I guess we mean in the relatively near future...Some thoughts that come to mind in addition to 1.5 are: 1. We should start running classlibraries and existing api tests against the DRLVM bits. This is sure to identify bugs/issues that will need addressing. 2. We need to achieve completeness in the DRLVM VM functionality.we don't handle stack overflows well, efficient unmanagd heap management issues, there is functional completenes needed in the verifier, optimized locks( thin, deflatable, jit optimized ), improvements in JVMTI support as Gregory points out. 3. In garbage collection, one thread that Weldon has already started is MMTk integration which looks promising, but while we finish that work, it may also make sense to substitute the existing rudimentary GC with a more functional one with better performance that can work as the default GC outside the MMTk integrated suite. +1 (+2 if we port an existing gc from another jvm) 4. We should also look at enhancements to the JITs ...and other than support for new platforms ( 64 bit , down level platforms that support x87 but not SSE* instructions..based on the minimum machine model we want to support eg a pentium III running Windows/Linux )some of this work would benefit from performance guidance...helpers should be inlined, some of the optimizations eg., devirtualization perfected, polling to support collection should consume less overhead, more optimized JNI invocation at some point. This brings up a good point. Performance is important but the subject of this thread is, ...what are the next functional enhancements? Should the scope be broadened to include performance goals? If true, perhaps start a discussion on this topic. 5. This is also in reference to the other thread you started about goals for Harmony, it may help to establish some vectors that are important for us in Harmony eg., among...1.5 and TCK compatibility, performance( benchmarking ), startup time, memory footprint, and that in some sense will determine the priorities. The work to be done will fall out of this. Feedback most welcome :-) Thanks, Rana - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Weldon Washburn Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Eclipse Plug-in Dependencies not resolving
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]
RE: [drlvm] what's next?
As mentioned in the [general] milestones and roadmap thread, work on integrating the concurrency APIs will require VM support and it seems like DRLVM is close to having some of it complete, so I would lobby for that. The VM APIs need are atomic CAS, parking and possibly methods for set/get of array elements as though they were volatile. DRLVM has a class stubbed for CAS [1] and lock support [2], the later of which I'd probably suggest moving to a VMI package. The piece about the set/get of array elements in a volatile fashion can be seen in the AtomicIntegerArray [3] class; look for putIntVolatile. I'm not completely clear on the details, but it seems to be necessary as array elements of an array aren't normally guaranteed to be treated like volatile fields and this method guarantees that. (I'm still trying to dig my way through the Java Memory Model stuff, so bear with me.) Do the current DRLVM build scripts build these utility classes [1][2] and their native counterparts? I was having trouble running the build scripts the other day (the Eclipse download killed me) and haven't had much time to experiment. The other piece that might need to be considered is how to handle AtomicLong on platforms that can't do 64-bit CAS natively. I was hoping this would be handled by the VM, but Doug's code [4] seems to handle it in the class itself. -Nathan [1] http://svn.apache.org/viewvc/incubator/harmony/enhanced/drlvm/trunk/vm/vmcor e/src/kernel_classes/javasrc/org/apache/harmony/util/concurrent/Atomics.java ?view=markup [2] http://svn.apache.org/viewvc/incubator/harmony/enhanced/drlvm/trunk/vm/vmcor e/src/kernel_classes/javasrc/java/util/concurrent/locks/LockSupport.java?vie w=markup [3] http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/main/java/util/concu rrent/atomic/AtomicIntegerArray.java?rev=1.25content-type=text/vnd.viewcvs- markup [4] http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/main/java/util/concu rrent/atomic/AtomicLongFieldUpdater.java?rev=1.23content-type=text/vnd.view cvs-markup -Original Message- From: Geir Magnusson Jr [mailto:[EMAIL PROTECTED] 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? geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r415681 - in /incubator/harmony/enhanced/classlib/trunk/modules/auth: build.xml make/build.xml make/common/ make/hyproperties.xml
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.
Thanks,
Stepan.
-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/hyproperties.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/modules/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
+ manifest=${hy.auth}/META-INF/MANIFEST.MF
+fileset dir=${hy.build}
+ includesfile=${hy.auth}/make/patternset.txt /
+/jar
+/target
+
+target name=compile.tests
+echo message=Compiling AUTH tests /
+
+mkdir dir=${hy.auth.bin.test} /
+
+javac destdir=${hy.auth.bin.test}
+source=${hy.javac.source}
+target=${hy.javac.target}
+debug=${hy.javac.debug}
+
+!-- FIXME: AUTH tests should not reach into security module
code --
+src
+pathelement location=${hy.auth.src.test.java}/
+pathelement
Re: Pack200 -- can now obtain files stored in archive
On 6/21/06, Alex Blewitt wrote: SNIP 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. 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. Thanks, Stepan [1] http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200601.mbox/[EMAIL PROTECTED] -- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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/
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]
Re: [Fwd: [classlib][NIO|VMI]Interruptible channel implementation - how to interact with Thread?]
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?).
I'm still curious what mechanism will be used to wakeup blocked threads
though.
I thought I've described the solution in my first post triggering this
thread, but I'm sorry if it's confusable. Basically the thread is waken
up by closing the I/O channel in another thread. Please see below for
details:
The AbstractInterruptibleChannel's begin()/end() is probably like:
public void begin(){
interruptActionSetter.execute(Thread.currentThread(), new
Object[]{new Runnable(){
public void run(){
AbstractInterruptibleChannel.this.close();
}
}});
}
public void end(boolean complete) throws Exception{
interruptActionSetter.execute(Thread.currentThread(), new
Object[]{null});
if(interrupted) blabla
else if(closed !completed) blabla
else blabla
}
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.
-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]
--
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: A GC module written in Java for DRLVM
Weldon, 2006/6/21, Weldon Washburn [EMAIL PROTECTED]: I looked at JIRA 622. It looks like there are 22 pages of new assembly code and about 26 pages of new java code. Perhaps you could give us a summary of what the assembly code does and why it can't be done in Java. Don't worry about the asms, they are only temporary for hacking purpose when proper JIT support was (is) unavailable in DRLVM. Since Java GC needs to access VM internal functionalities, which are exposed with C interfaces, we choose to use fast JNI to access them easily. Fast JNI in DRLVM requires asm stub for the transition from Java to C world for every C function, hence you see lots of asms in our code. They mostly can be eliminated once DRLVM JIT supports intrinsics of VM_Address, etc., just like the write barrier issue we discussed. Actually this fast JNI invocations are forming a layer of Java GC adapter to VM core, which hide the details of VM core implementation from Java GC, so that the Java GC we developed can plug into a Java VM core as well. Also, I would like to see the code you developed that JITs the GC. It might make sense to reuse this code for the MMTk port. In our work, we do not change JIT much. DRLVM can jit the Java GC like a normal Java application. The only change is, as explained above, that JIT needs to know the methods for fast JNI invocations. Please refer to function compile_do_compilation_jit(vm/vmcore/src/jit/compile.cpp). -- Thanks, Ming
