Re: [classlib] Layout of tests in crypto module
Mikhail Loenko wrote: 2006/5/24, Geir Magnusson Jr <[EMAIL PROTECTED]>: George Harley wrote: > Hi Mikhail, > > That is a very good point and your suggestion of supplementing the class > or package name sounds like a very straightforward way around the > problem. Because there will be a number of tests that must be in an > identical package name to the type under test then it seems that the > differentiating mark needs to be added to the test class name. Not > really sure what this could be. Given that we are all settled on the > convention that a test type has the "Test" suffix, how about just add > "Impl" to that suffix for implementation tests giving us an "ImplTest" > suffix. > e.g. > > class under test : java.lang.SomeClassTest > implementation-independent test class : > o.a.h.module.tests.java.lang.SomeClassTest > Harmony-specific test class : > o.a.h.module.tests.java.lang.SomeClassImplTest Or o.a.h..apitest.java.lang.FooTest o.a.h..impltest.java.lang.FooTest Of course, the implementation test didn't need to be on the bootclasspath, it would simply be java.lang.FooTest with no other garbage in the package name Hi Geir how to distinguish between bootclasspath implementation test java.lang.FooTest and bootclasspath api test java.lang.FooTest Is there such thing as an bootclasspath API test? geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DRLVM] build process improvement
Andrey Chernyshev wrote: On 5/23/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: Andrey Chernyshev wrote: > Returning back to the subject of this discussion, I guess it should be > relatively easy to modify the DRLVM building system such that it would > get the binary HDK from web and use it for compilation of a single > module. I don't understand this sentence. Do you mean a classlibrary module or a DRLVM module? It could be both actually, the building script produces complete JRE combined from a set of classlib modules and a set of VM modules. There is no much distinction between VM or classlib, all modules are built using the same set of rules. Though all modules are currently compiled, it should be possible to take some of them in a binary form from HDK snapshot. I find it hard to see why we'd want to couple them in the long run. The VM and the classlib will be parallel trees, for example... harmony/enhanced/classlib harmony/enhanced/ Thanks, Andrey. > And this approach would assume that the HDK snapshots include the > DRLVM as well (?) :) Assuming we accept DRLVM as our basis for our VM, yes. We can also include JCHEVM whenever it converts from GNU Classpath :) geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Moving forward with RMI and Math ( was Re: towards a new implementation of java.math)
Mark Hindess wrote: On 24 May 2006 at 12:50, "Mikhail Loenko" <[EMAIL PROTECTED]> wrote: As a first step I suggest taking it as a base - move rmi to rmi4 or whatever and move rmi3 to rmi. This is fine with me but, being slightly pedantic, I think that's the second step. The first step is to do the same restructure that I did with the itc 1.4 rmi when I moved it to modules/rmi. That is, make rmi3 build with: ant -Dhy.rmi.module=rmi3 -f make/build.xml That's not 'slightly' pedantic. :) Why not ensure that ant -Dhy.rmi.module=rmi -f make/build.xml works when done? geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [website] harmony-dev agreements and recommendations
Nice! Well done! Stepan Mishura wrote: Hi, It is hard to track decisions made on harmony-dev mailing list and I've tried to summarize them[1]. The mail archive is quite big and most probably I missed or misunderstand something. Feel free to send patches to improve web-page content. [1] http://incubator.apache.org/harmony/subcomponents/classlibrary/agreements.html Thanks, Stepan Mishura Intel Middleware Products Division -- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - 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] Layout of tests in crypto module
Yes there is. They can access protected fields (they are also package-visible). Or they can test something related to class loading. Example. Recently I committed modules\luni\src\test\java.injected\java\net\HttpURLConnectionAccessor.java that is not a test though but something that is used by API test and that must be in bootclasspath. (I could refactor and put the test itself to the bootclasspath) Thanks, Mikhail 2006/5/25, Geir Magnusson Jr <[EMAIL PROTECTED]>: Mikhail Loenko wrote: > 2006/5/24, Geir Magnusson Jr <[EMAIL PROTECTED]>: >> >> >> George Harley wrote: >> > Hi Mikhail, >> > >> > That is a very good point and your suggestion of supplementing the >> class >> > or package name sounds like a very straightforward way around the >> > problem. Because there will be a number of tests that must be in an >> > identical package name to the type under test then it seems that the >> > differentiating mark needs to be added to the test class name. Not >> > really sure what this could be. Given that we are all settled on the >> > convention that a test type has the "Test" suffix, how about just add >> > "Impl" to that suffix for implementation tests giving us an "ImplTest" >> > suffix. >> > e.g. >> > >> > class under test : java.lang.SomeClassTest >> > implementation-independent test class : >> > o.a.h.module.tests.java.lang.SomeClassTest >> > Harmony-specific test class : >> > o.a.h.module.tests.java.lang.SomeClassImplTest >> >> Or >> >> o.a.h..apitest.java.lang.FooTest >> o.a.h..impltest.java.lang.FooTest >> >> >> Of course, the implementation test didn't need to be on the >> bootclasspath, it would simply be >> >> java.lang.FooTest >> >> with no other garbage in the package name > > Hi Geir > > how to distinguish between bootclasspath implementation test > java.lang.FooTest > and bootclasspath api test > java.lang.FooTest Is there such thing as an bootclasspath API test? 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: Multi-tree HDK config - working directory ( was Re: Supporting working on a single module?)
Geir Magnusson Jr wrote: Some stuff that got lost (because I got consumed by J1 and I was the only one pushing on it) was the idea of ensuring that 1) the HDK could be anywhere - the was no hard-wired spot. That allowed having multiple simultaneous HDKs (ex different snapshot version) at the same time as a full build Perhaps the HDK would have a default location which could be overridden by passing a command line option to the build scripts - possibly in a similar way to Marks suggestion for selection of the rmi module location [1]. My modifications to build an HDK from the classlib code (HARMONY-469) use an Ant property hy.hdk to specify the root directory of the HDK. With the current patch, this property doesnt quite propagate all the way down to the native makefiles, but this shouldnt be too hard to extend. Once this was done, a developer could then override the default HDK location using a command line similar to: ant -Dhy.hdk=/my/hdk/location -f make/build.xml The default HDK location would probably depend on what area you are working on - in classlib the trunk/deploy directory is the default build location at the moment, and I think it makes sense to keep this as the default HDK directory. 2) the build should ensure that the materials of the HDK never get overwritten so that we can always tell a contributor w/ a question "first, before we debug this, do a ant hdk-copy.." or something to easily get them to a known good state. This to me sounds like we need some kind of working directory and a 'hdk-copy' target. The working model then allows freedom of choosing an hdk or a current full build as the 'base' to work with... I imagine that an HDK would come in a zip format, much like the current snapshots [2]. If this was the case, then once you have downloaded the HDK zip, you can unpack it into your working directory where it will be modified. However, you still have the original zip to fall back on if you need to. I'm not sure that we need an extra build target for this process - to get back to a known good state, you can just unpack the zip again into your working directory. Am I missing something? Regards, Oliver [1] http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200605.mbox/[EMAIL PROTECTED] [2] http://people.apache.org/dist/incubator/harmony/snapshots/ Does this make any sense to anyone else? geir Oliver Deakin wrote: Hi all, I have opened HARMONY-485, which proposes an additional doc for the website describing the HDK and its contents. The layout of the HDK described in the doc matches that produced by the build script alterations raised in HARMONY-469. I hope that eventually (once the natives are modularised and build scripts are altered to understand/use the HDK) the doc will expand into a more full description of how developers can use the HDK to rebuild Java/native code. Regards, Oliver - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Oliver Deakin IBM United Kingdom Limited - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] resource files for testing serialization - location and name?
Summary for this discussion : http://incubator.apache.org/harmony/subcomponents/classlibrary/ser_testing.html Thanks, Stepan. On 5/24/06, Stepan Mishura wrote: On 5/24/06, Geir Magnusson Jr wrote: > > Do you believe you came to a conclusion? Do you want to summarize? Yes, I'm going to put summary on web-site. Thanks, Stepan. geir > > Stepan Mishura wrote: > > Hi, > > > > During the last discussion no agreements were made - though it was > very > > useful for me. And I'd like to start new round for serialization > testing. I > > want to define rules for locating and naming resource files for > > serialization. There is only agreement that we put all files for > testing > > serialization to folder: > > modules//src/test/resources/ and I'd like to work out a > rules > > where to locate ser files for a test inside that folder and how to > name > > them. I want to propose the following rules: > > > > 1)Path to resource files MUST match a test's package > > I think it will be easier to find all test's resource files. > > > > 2)Resource file name MUST starts with a test's name > > IMHO, it should be clear from resource file name which test use it > > > > 3)Resource file name MUST contain keywords pointing out to > implementation > > Keyword is intended to signal on which implementation a resource file > was > > generated – so we can track Harmony backward compatibility and > > compatibility > > with RI. For example, for files generated on RI we may use 'golden' > keyword > > and for Harmony – 'harmony'. > > > > 4)Resource file name MUST contain some index. > > In general, a test may use a set of resource files > > > > To summarize: for test > org.apache.harmony.tests.java.lang.SomeClassTest we > > have the following structure > > modules/luni/src/test/resources > >org/apache/harmony/tests/java/lang > > SomeClassTest.golden.0.ser > >SomeClassTest.golden.1.ser > >SomeClassTest.golden.2.ser > >SomeClassTest.harmony.0.ser > >SomeClassTest.harmony.1.ser > > > > Thanks, > > Stepan Mishura > > Intel Middleware Products Division > > > > -- > > Terms of use : http://incubator.apache.org/harmony/mailing.html > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Thanks, Stepan Mishura Intel Middleware Products Division -- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Thanks, Stepan Mishura Intel Middleware Products Division -- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] please review my regression test and patch for HttpURLConnection
Mikhail,
Sorry to response so late, seems both IBM's smtp server and gmail is not
stable so that I have to send this mail several times from today before
yesterday (please pardon me if the mailing list get several duplicate mails
after hundreds of hours! ).
Basically, I'm afraid I cannot agree with you on this patch.
1. I have no strong objection on the patch for HttpURLConnection, but...If I
understand correctly, Harmony-482 is about the internal contract between
java.net.HttpURLConnection.setRequestMethod() and
o.a.h.l.internal.net.www.protocol.http.HttpURLConnection.getOutputStream(),
and the internal contract may be broken only if some of the codes refactored
(no chance for user application), say, modification for the
setRequestMethod() like this:
- this.method = methodTokens[i];
+this.method = method;
But this can be easily monitored by test codes below:
public void testGetOutputStream() throws Exception {
HttpURLConnection c = (HttpURLConnection) new
URL("http://127.0.0.1:";
Re: [classlib] please review my regression test and patch for HttpURLConnection
Hi Paulex,
2006/5/25, Yang Paulex <[EMAIL PROTECTED]>:
Mikhail,
Sorry to response so late, seems both IBM's smtp server and gmail is not
stable so that I have to send this mail several times from today before
yesterday (please pardon me if the mailing list get several duplicate mails
after hundreds of hours! ).
Basically, I'm afraid I cannot agree with you on this patch.
1. I have no strong objection on the patch for HttpURLConnection, but...If I
understand correctly, Harmony-482 is about the internal contract between
java.net.HttpURLConnection.setRequestMethod() and
o.a.h.l.internal.net.www.protocol.http.HttpURLConnection.getOutputStream(),
Not exactly. The second problem is that the code makes assumption that
two String constant-pool constants in two different classes will be the same
object. That is an assumption about VM that is met in J9 and RI.
Other VMs might not have this kind of optimization and the code will not work
on those VMs. I've fixed the code to not depend on that assumption.
Then I had to develop a test that would
1. passes on RI
2. fails on unfixed Harmony
3. passes on fixed Harmony
The code you suggested below passes on unfixed Harmony, so
it is not a good regression test.
and the internal contract may be broken only if some of the codes refactored
(no chance for user application), say, modification for the
setRequestMethod() like this:
- this.method = methodTokens[i];
+this.method = method;
But this can be easily monitored by test codes below:
public void testGetOutputStream() throws Exception {
HttpURLConnection c = (HttpURLConnection) new
URL("http://127.0.0.1:";
Re: Supporting working on a single module?
Geir Magnusson Jr wrote: On thing to think about (which I didn't realize until now) is that HDK should sit above /classlib in the tree right? the VMs will need it as well. I imagine : enhanced/ classlib/ drlvm/ jchevm/ bootvm/ So maybe add a enhanced/common directory in which the HDK sits by default? I'd like to avoid the structural balkanization of making classlib an island. I had imagined that HDKs would be packaged up as zips and made available in a similar way to snapshots, rather than having a tree of binaries checked into SVN. IMHO keeping it as a zip makes unpacking it where you want very simple, allows you to easily keep a "known good" HDK configuration locally (in the form of the original zip) and makes it very easy to get previous versions of the HDK (just download an earlier zip). I'd be interested to hear what general consensus on this matter is, and how mailing list members would prefer the HDK to be provided. We discussed [1] that having separate HDKs for each VM and for classlib makes sense - as long as we keep them in a uniform shape, then they can easily overlaid onto each other to allow a developer to work on the classlib and the VM of their choice. I don't see this separation of classlib and VMs as a bad thing. I think that having a VMI enabling us to develop the classlib and VMs as distinct units, and developing using potentially disparate methods and build systems that most suit that component, is one of the cool things about Harmony! Regards, Oliver [1] http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200605.mbox/[EMAIL PROTECTED] geir Oliver Deakin wrote: Hi all, I have opened HARMONY-485, which proposes an additional doc for the website describing the HDK and its contents. The layout of the HDK described in the doc matches that produced by the build script alterations raised in HARMONY-469. I hope that eventually (once the natives are modularised and build scripts are altered to understand/use the HDK) the doc will expand into a more full description of how developers can use the HDK to rebuild Java/native code. Regards, Oliver - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Oliver Deakin IBM United Kingdom Limited - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Multi-tree HDK config - working directory ( was Re: Supporting working on a single module?)
2006/5/25, Oliver Deakin <[EMAIL PROTECTED]>: I imagine that an HDK would come in a zip format, much like the current snapshots [2]. I also suggest to add build date into zip name and internal directory name. Something like HDK_20060525/deploy and so on... It will let us keep few copies of HDK in the same place for testing purposes. -- Alexey A. Petrenko Intel Middleware Products Division
Re: [classlib] please review my regression test and patch for HttpURLConnection
Hi, Mikhail,
2006/5/25, Mikhail Loenko <[EMAIL PROTECTED]>:
Hi Paulex,
2006/5/25, Yang Paulex <[EMAIL PROTECTED]>:
> Mikhail,
>
> Sorry to response so late, seems both IBM's smtp server and gmail is not
> stable so that I have to send this mail several times from today before
> yesterday (please pardon me if the mailing list get several duplicate
mails
> after hundreds of hours! ).
>
> Basically, I'm afraid I cannot agree with you on this patch.
>
> 1. I have no strong objection on the patch for HttpURLConnection,
but...If I
> understand correctly, Harmony-482 is about the internal contract between
> java.net.HttpURLConnection.setRequestMethod() and
> o.a.h.l.internal.net.www.protocol.http.HttpURLConnection.getOutputStream
(),
Not exactly. The second problem is that the code makes assumption that
two String constant-pool constants in two different classes will be the
same
object. That is an assumption about VM that is met in J9 and RI.
Other VMs might not have this kind of optimization and the code will not
work
on those VMs. I've fixed the code to not depend on that assumption.
I accepts this reason, it will be better if the original codes use
predefined constants instead of hard coded string.
Then I had to develop a test that would
1. passes on RI
2. fails on unfixed Harmony
3. passes on fixed Harmony
The code you suggested below passes on unfixed Harmony, so
it is not a good regression test.
The codes below is not regressiont test, it's just a test to enforce the
original internal contract between setRequestMethod() and
getOutputStream().
and the internal contract may be broken only if some of the codes
refactored
> (no chance for user application), say, modification for the
> setRequestMethod() like this:
>
> - this.method = methodTokens[i];
> +this.method = method;
>
> But this can be easily monitored by test codes below:
>
> public void testGetOutputStream() throws Exception {
> HttpURLConnection c = (HttpURLConnection) new
> URL("http://127.0.0.1:";
Re: bootJVM linux build...
Hi Sanket, welcome. Good to hear you are trying to build the boot VM. The expert on that code is Dan Lydick -- hopefully he will see your note and be able to help. If you don't hear from him soon I'll try my best Regards, Tim Sanket Sharma wrote: > Hey everyone.. > > I was trying to build the jvm on Linux. I´m using SUSE Linux and GCC 4. > I am facing a little problem with macro expansion and some help would be > greatly appreciated. > > While trying to build the jvm, I get the following error: > > class.c: In function ‘class_load_resolve_clinit’: > class.c:1631: error: invalid lvalue in assignment > > > which is a Macro > > PUSH_FRAME(thridx, pca->max_locals); > > When I do a gcc - E and save output to file, I can see the macro being > expanded to: > > (pjvm->thread[thridx].sp) += ((pca->max_locals)); > (pjvm->thread[thridx].sp) += (1); > pjvm->thread[thridx].stack[pjvm->thread[thridx].sp - 0] = (jint) > (((pca->max_locals))); > (pjvm->thread[thridx].sp) += (1); > (rvoid *) *(&(pjvm->thread[thridx].stack[((pjvm->thread[thridx].sp) - (1 > +1))])) = GC_STACK_NEW(thridx, (pca->max_locals)); > (pjvm->thread[thridx].sp) += (1); > pjvm->thread[thridx].stack[pjvm->thread[thridx].sp - 0] = (jint) > ((pjvm->thread[thridx].fp)); > pjvm->thread[thridx].fp = (((pjvm->thread[thridx].sp) - ((1 + 1 + 1; > (pjvm->thread[thridx].sp) += (1); > pjvm->thread[thridx].stack[pjvm->thread[thridx].sp - 0] = (jint) > ((pjvm->thread[thridx].pc.offset)); > (pjvm->thread[thridx].sp) += (1); > pjvm->thread[thridx].stack[pjvm->thread[thridx].sp - 0] = (jint) > ((pjvm->thread[thridx].pc.excpatridx)); > (pjvm->thread[thridx].sp) += (1); > pjvm->thread[thridx].stack[pjvm->thread[thridx].sp - 0] = (jint) > ((pjvm->thread[thridx].pc.codeatridx)); > (pjvm->thread[thridx].sp) += (1); > pjvm->thread[thridx].stack[pjvm->thread[thridx].sp - 0] = (jint) > ((pjvm->thread[thridx].pc.mthidx)); > (pjvm->thread[thridx].sp) += (1); > pjvm->thread[thridx].stack[pjvm->thread[thridx].sp - 0] = (jint) > ((pjvm->thread[thridx].pc.clsidx));;; > > I tried putting brackets in various macros but nothing helped. > > Any help would be greatly appreciated. > > Best Regards, > Sanket Sharma > > > This email may contain confidential or privileged information for the > intended recipient(s) and the views expressed in the same are not > necessarily the views of Zensar Technologies Ltd. If you are not the intended > recipient or have received this e-mail by error, its use is strictly > prohibited, please delete the e-mail and notify the sender. Zensar > Technologies Ltd. does not accept any liability for virus infected mails. > > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] Layout of tests in crypto module
Mikhail Loenko wrote: > Yes there is. > > They can access protected fields (they are also package-visible). Or they > can test something related to class loading. > > Example. Recently I committed > modules\luni\src\test\java.injected\java\net\HttpURLConnectionAccessor.java > > that is not a test though but something that is used by API test and > that must > be in bootclasspath. (I could refactor and put the test itself to the > bootclasspath) I like what you did there Mikhail. Where we can, I think it is simpler to have such 'helpers' injected into the bootclasspath, rather than running the test itself on the bootclasspath. 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]
[classlib] internationalization (was: Re: svn commit: r407780 - in /incubator/harmony/enhanced/classlib/trunk/modules/archive/src: main/java/java/util/jar/Attributes.java test/java/org/apache/harmony/
Mikhail Loenko wrote:
> We also agreed to put only internationalized messages and
> to have a single catalog by module.
Yep, that's a good task for somebody who is looking for a simple way to
contribute to Harmony's classlibs.
If anyone wants to volunteer then go for it -- I can help with guidance
if required.
> Is there any way to meet all the agreements without rewriting the
> internationalization framework?
I don't think we need to change the mechanism we use to get message
strings from resource catalogs, just split the single catalog up across
the modules.
Regards,
Tim
> 2006/5/19, Magnusson, Geir <[EMAIL PROTECTED]>:
>> And if we didn't, I think we just did :)
>>
>> --
>> Geir Magnusson Jr
>> SSG/MPD
>> [EMAIL PROTECTED]
>> +1 203 665 6437
>>
>> > -Original Message-
>> > From: Tim Ellison [mailto:[EMAIL PROTECTED]
>> > Sent: Friday, May 19, 2006 7:03 AM
>> > To: harmony-dev@incubator.apache.org
>> > Subject: Re: svn commit: r407780 - in
>> > /incubator/harmony/enhanced/classlib/trunk/modules/archive/src
>> > : main/java/java/util/jar/Attributes.java
>> > test/java/org/apache/harmony/archive/tests/java/util/jar/Attri
>> > butesTest.java
>> >
>> > [EMAIL PROTECTED] wrote:
>> >
>> > > public void putAll(Map attrib) {
>> > > +if( attrib == null ) {
>> > > +throw new ClassCastException();
>> > > +}
>> >
>> > Shouldn't this have a message? I thought we agreed that we'd
>> > add useful
>> > messages to exceptions.
>> >
>> > Regards,
>> > Tim
>> >
>> > --
>> >
>> > Tim Ellison ([EMAIL PROTECTED])
>> > IBM Java technology centre, UK.
>> >
>> > -
>> > Terms of use : http://incubator.apache.org/harmony/mailing.html
>> > To unsubscribe, e-mail: [EMAIL PROTECTED]
>> > For additional commands, e-mail: [EMAIL PROTECTED]
>> >
>>
>> -
>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>
> -
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
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] jetty based tests
Geir Magnusson Jr wrote:
> This thread was a long read :)
>
> First, I'm all for using Jetty as our test server (I think we talked
> about this a long time ago...). We could even use Tomcat, but my
> experience in the past was that Jetty was very easy to emebed. By
> default, there should be no external dependency to build, test and run
> Harmony (i.e. I can do it on a plane - that means that no external
> server is required.)
>
> Second, I think that we don't lose much in terms of flexibility, and
> gain an awful lot in functionality. Writing tests is very easy, and we
> probably can control anything we want to for custom stuff.
>
> Third, we get location transparency. Our isolated-system-default
> notwithstanding, we certainly want to test over a network (localhost
> doesn't cut it), so we should easily be able to run the ant target that
> runs the server on a remote machine so we can test things like real
> network failure and interruption (IOW, reach around and pull the network
> cable out...), setting a property or -ish for the address of the test
> target server (default is localhost)
>
> Given that the argument is long and winding, can people do a checkpoint
> summary about how they are feeling?
Does 'exhausted' count ;-)
FWIW I also agree that using Jetty embedded in the tests is a good idea,
with custom handlers etc. to force some test case scenarios. Where it
doesn't work we can do stubs.
I assume that we can have a test script config file to define the server
location. We can have the default mode be starting the Jetty server on
localhost (a.k.a. 'airplane mode' ), then if you want to run the
server remotely the tests config would have to be updated...
Regards,
Tim
> geir
>
> Stepan Mishura wrote:
>> On 5/23/06, Andrew Zhang <[EMAIL PROTECTED]> wrote:
>>
>>> Hi, Stepan,
>>>
>>> "No we shouldn't write a mock http server for each case (I mean that we
>>> need
>>> not implement http protocol each time)."
>>>
>>> Shall we implement http sometimes? If no, how can we verfiy
>>> HttpURLConnection function, for example, whether the request is in http
>>> format,
>>> or chuncked http request.
>>
>>
>> Yes we have implement http protocol in HttpURLConnection class. The
>> question
>> is how to verify its implementation. This can be done in two ways:
>> with or
>> without existing http server. Both ways are possible. Approach with using
>> existing http server for testing looks more confident but misuse of this
>> approach may result in hard-to-configure and slow-to-run test suite.
>> So my
>> position was that we can use both ways but separately. Tests that don't
>> depend on http server are included in 'normal test suite' and run
>> regularly.
>> And dependant tests are run separately.
>>
>> But if jetty is so good as George and Paulex described then I'll think
>> about
>> revising my position.
>>
>>
>>
>>> If there's a mock httpserver utility, which could assert whether
>>> receieved
>>> http request is correct, and could generate customized http output,
>>> it can
>>> be called "little jetty". If the utility httpserver could customize
>>> output
>>> more flexibility, could make some unspecial output which jetty couldn't,
>>> it
>>> could be called "enhanced jetty". Finally, the utility class will
>>> have to
>>> implement http protocol and become an HttpSrever or
>>> EnhanceedHttpServer(since it could do some extra work, e.g, produce
>>> broken
>>> http response, etc.).
>>>
>>> "So we have to develop mock server anyway. And the mock server can be
>>> used
>>> for other ('positive') tests. Right? Then why we have to use jetty?"
>>>
>>> If there's a mock server utility can be easily used for normal and
>>> abnormal
>>> http test, I've no objection to use it.
>>> At least, we have one in common: reduce external dependency. Right?
>>
>>
>> Yes
>>
>> Thanks,
>> Stepan.
>>
>>
>>
>>
>>
>>> Thanks.
>>>
>>>
>>> On 5/23/06, Stepan Mishura <[EMAIL PROTECTED]> wrote:
>>> >
>>> > On 5/23/06, Andrew Zhang wrote:
>>> > >
>>> > > Hi, Stepan,
>>> > >
>>> > > "With mock objects this can be done with no problems and HARMONY-164
>>> > > demonstrates the possible way."
>>> > >
>>> > > Shall we write a mock http server for each case? It takes lots of
>>> > > reduplicate efforts and results in many mock http server classes in
>>> the
>>> > > end.
>>> >
>>> >
>>> > No we shouldn't write a mock http server for each case (I mean that we
>>> > need
>>> > not implement http protocol each time). In "HARMONY-164 version" mock
>>> > server
>>> > is an instance of class that extends Thread class. The mock server is
>>> > started before running test and by default is just listens for
>>> incoming
>>> > connection. A test has access to server's instance and may
>>> configure it
>>> > response (I didn't implemented but it is also possible to save request
>>> to
>>> > be
>>> > verified). There is no http protocol implementation.
>>> >
>>> > In fact, for many regular tests, jetty works fine.
>>> > >
>>> > > And I also a
Re: [classlib] please review my regression test and patch for HttpURLConnection
2006/5/25, Yang Paulex <[EMAIL PROTECTED]>:
Hi, Mikhail,
2006/5/25, Mikhail Loenko <[EMAIL PROTECTED]>:
> Hi Paulex,
>
> 2006/5/25, Yang Paulex <[EMAIL PROTECTED]>:
> > Mikhail,
> >
> > Sorry to response so late, seems both IBM's smtp server and gmail is
> not
> > stable so that I have to send this mail several times from today
> before
> > yesterday (please pardon me if the mailing list get several duplicate
> mails
> > after hundreds of hours! ).
> >
> > Basically, I'm afraid I cannot agree with you on this patch.
> >
> > 1. I have no strong objection on the patch for HttpURLConnection,
> but...If I
> > understand correctly, Harmony-482 is about the internal contract
> between
> > java.net.HttpURLConnection.setRequestMethod () and
> >
> o.a.h.l.internal.net.www.protocol.http.HttpURLConnection.getOutputStream
> (),
>
> Not exactly. The second problem is that the code makes assumption that
> two String constant-pool constants in two different classes will be the
> same
> object. That is an assumption about VM that is met in J9 and RI.
>
> Other VMs might not have this kind of optimization and the code will not
> work
> on those VMs. I've fixed the code to not depend on that assumption.
I accepts this reason, it will be better if the original codes use
predefined constants instead of hard coded string.
I'm Sorry, I made a mistake here, the String's spec and Java Language Spec
has required the literal String as well as constant with String value must
be interned, please refer to String.intern()'s JavaDoc and JLS 3.10.5. So
the original code can work with any Java VM/Compiler.
Then I had to develop a test that would
> 1. passes on RI
> 2. fails on unfixed Harmony
> 3. passes on fixed Harmony
>
> The code you suggested below passes on unfixed Harmony, so
> it is not a good regression test.
The codes below is not regressiont test, it's just a test to enforce the
original internal contract between setRequestMethod() and
getOutputStream().
> and the internal contract may be broken only if some of the codes
> refactored
> > (no chance for user application), say, modification for the
> > setRequestMethod() like this:
> >
> > - this.method = methodTokens[i];
> > +this.method = method;
> >
> > But this can be easily monitored by test codes below:
> >
> > public void testGetOutputStream() throws Exception {
> > HttpURLConnection c = (HttpURLConnection) new
> > URL("http://127.0.0.1:";
Re: [classlib] please review my regression test and patch for HttpURLConnection
Mikhail Loenko wrote:
> Hi Paulex,
>
> 2006/5/25, Yang Paulex <[EMAIL PROTECTED]>:
>> Mikhail,
>>
>> Sorry to response so late, seems both IBM's smtp server and gmail is not
>> stable so that I have to send this mail several times from today before
>> yesterday (please pardon me if the mailing list get several duplicate
>> mails
>> after hundreds of hours! ).
>>
>> Basically, I'm afraid I cannot agree with you on this patch.
>>
>> 1. I have no strong objection on the patch for HttpURLConnection,
>> but...If I
>> understand correctly, Harmony-482 is about the internal contract between
>> java.net.HttpURLConnection.setRequestMethod() and
>> o.a.h.l.internal.net.www.protocol.http.HttpURLConnection.getOutputStream(),
>>
>
> Not exactly. The second problem is that the code makes assumption that
> two String constant-pool constants in two different classes will be the
> same
> object. That is an assumption about VM that is met in J9 and RI.
>
> Other VMs might not have this kind of optimization and the code will not
> work
> on those VMs. I've fixed the code to not depend on that assumption.
The JVM spec requires that String literals are interned using
String.intern, so you are safe to make that assumption.
> Then I had to develop a test that would
> 1. passes on RI
> 2. fails on unfixed Harmony
> 3. passes on fixed Harmony
>
> The code you suggested below passes on unfixed Harmony, so
> it is not a good regression test.
>
>> and the internal contract may be broken only if some of the codes
>> refactored
>> (no chance for user application), say, modification for the
>> setRequestMethod() like this:
>>
>> - this.method = methodTokens[i];
>> +this.method = method;
>>
>> But this can be easily monitored by test codes below:
>>
>> public void testGetOutputStream() throws Exception {
>> HttpURLConnection c = (HttpURLConnection) new
>> URL("http://127.0.0.1:";
Re: [classlib] jetty based tests
Good day, I assume that we can have a test script config file to define the server location. We can have the default mode be starting the Jetty server on localhost (a.k.a. 'airplane mode' ), then if you want to run the server remotely the tests config would have to be updated... It seems to me that remote server is not requires in HTTP tests. The only difference between local HTTP server and the remote one is that the first is reached via loopback and the latter - via "real" net. Testing of network connections is out of scope of HTTP functionality tests so local server shoud be enough. Remote server has obvious drawbacks: - if we compare in tests data fetched by via HTTP to some expected result, it's likely that contents of remote site (say, apache.org) will change and tests will fail - some companies and providers don't allow to connect from internal network to the Internet directly - 'telnet ... 80' will fail. The direct connection functionality cannot be tested in this environment. Remote server is not required even for proxy tests - Jetty can be configured to run as proxy server. The only problem with local server is choosing a local port to bind to - port 80 is often used by another daemon. Test should try to start Jetty on a free port and tell its number to the URLConnection test. My opinion is that remote server should not be used in tests - it's problematic and doesn't give any advantages. -- Regards, Anton Luht, Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] please review my regression test and patch for HttpURLConnection
2006/5/25, Yang Paulex <[EMAIL PROTECTED]>:
2006/5/25, Yang Paulex <[EMAIL PROTECTED]>:
>
> Hi, Mikhail,
>
> 2006/5/25, Mikhail Loenko <[EMAIL PROTECTED]>:
>
> > Hi Paulex,
> >
> > 2006/5/25, Yang Paulex <[EMAIL PROTECTED]>:
> > > Mikhail,
> > >
> > > Sorry to response so late, seems both IBM's smtp server and gmail is
> > not
> > > stable so that I have to send this mail several times from today
> > before
> > > yesterday (please pardon me if the mailing list get several duplicate
> > mails
> > > after hundreds of hours! ).
> > >
> > > Basically, I'm afraid I cannot agree with you on this patch.
> > >
> > > 1. I have no strong objection on the patch for HttpURLConnection,
> > but...If I
> > > understand correctly, Harmony-482 is about the internal contract
> > between
> > > java.net.HttpURLConnection.setRequestMethod () and
> > >
> > o.a.h.l.internal.net.www.protocol.http.HttpURLConnection.getOutputStream
> > (),
> >
> > Not exactly. The second problem is that the code makes assumption that
> > two String constant-pool constants in two different classes will be the
> > same
> > object. That is an assumption about VM that is met in J9 and RI.
> >
> > Other VMs might not have this kind of optimization and the code will not
> > work
> > on those VMs. I've fixed the code to not depend on that assumption.
>
>
> I accepts this reason, it will be better if the original codes use
> predefined constants instead of hard coded string.
>
I'm Sorry, I made a mistake here, the String's spec and Java Language Spec
has required the literal String as well as constant with String value must
be interned, please refer to String.intern()'s JavaDoc and JLS 3.10.5. So
the original code can work with any Java VM/Compiler.
Good catch! I'll simplify the test
Thanks,
Mikhail
Then I had to develop a test that would
> > 1. passes on RI
> > 2. fails on unfixed Harmony
> > 3. passes on fixed Harmony
> >
> > The code you suggested below passes on unfixed Harmony, so
> > it is not a good regression test.
>
>
> The codes below is not regressiont test, it's just a test to enforce the
> original internal contract between setRequestMethod() and
> getOutputStream().
>
> > and the internal contract may be broken only if some of the codes
> > refactored
> > > (no chance for user application), say, modification for the
> > > setRequestMethod() like this:
> > >
> > > - this.method = methodTokens[i];
> > > +this.method = method;
> > >
> > > But this can be easily monitored by test codes below:
> > >
> > > public void testGetOutputStream() throws Exception {
> > > HttpURLConnection c = (HttpURLConnection) new
> > > URL("http://127.0.0.1:";
Re: [jira] Updated: (HARMONY-308) java.nio.charset.Charset.encode(CharBuffer) returns bytes in a different order in Harmony and RI for the UTF-16 charset
Hi Richard, On 4/7/06, Richard Liang <[EMAIL PROTECTED]> wrote: You're Dmitry. :-) Now I agree with you that Harmony is not compliant with the specification. We will discuss with our Charset Provider - ICU to determine how to fix this issue. Thanks a lot. Is there any progress? Thanks. -- Dmitry M. Kononov Intel Managed Runtime 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] jetty based tests
+1 from me I also suggest we use Jetty as a singleton, so that we don't need to pay the overhead to find an available port and to start http server. The proposal is: 1. Some utility class in support project is responsible to lazily start Jetty when necessary on an available port in embedded mode, and to stop it when all test cases exit 2. every test class using Jetty is responsible to maintain its own context named as "//" and corresponding handler ideas and comments? 2006/5/25, Anton Luht <[EMAIL PROTECTED]>: Good day, > I assume that we can have a test script config file to define the server > location. We can have the default mode be starting the Jetty server on > localhost (a.k.a. 'airplane mode' ), then if you want to run the > server remotely the tests config would have to be updated... It seems to me that remote server is not requires in HTTP tests. The only difference between local HTTP server and the remote one is that the first is reached via loopback and the latter - via "real" net. Testing of network connections is out of scope of HTTP functionality tests so local server shoud be enough. Remote server has obvious drawbacks: - if we compare in tests data fetched by via HTTP to some expected result, it's likely that contents of remote site (say, apache.org) will change and tests will fail - some companies and providers don't allow to connect from internal network to the Internet directly - 'telnet ... 80' will fail. The direct connection functionality cannot be tested in this environment. Remote server is not required even for proxy tests - Jetty can be configured to run as proxy server. The only problem with local server is choosing a local port to bind to - port 80 is often used by another daemon. Test should try to start Jetty on a free port and tell its number to the URLConnection test. My opinion is that remote server should not be used in tests - it's problematic and doesn't give any advantages. -- 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] -- Paulex Yang China Software Development Labotary IBM
Re: [classlib] Layout of tests in crypto module
Mikhail Loenko wrote: Yes there is. They can access protected fields (they are also package-visible). Or they can test something related to class loading. Example. Recently I committed modules\luni\src\test\java.injected\java\net\HttpURLConnectionAccessor.java that is not a test though but something that is used by API test and that must be in bootclasspath. (I could refactor and put the test itself to the bootclasspath) We could always just partition in the filesystem and separate the test runs for bootclasspath API, and bootclasspath implementation? Thanks, Mikhail 2006/5/25, Geir Magnusson Jr <[EMAIL PROTECTED]>: Mikhail Loenko wrote: > 2006/5/24, Geir Magnusson Jr <[EMAIL PROTECTED]>: >> >> >> George Harley wrote: >> > Hi Mikhail, >> > >> > That is a very good point and your suggestion of supplementing the >> class >> > or package name sounds like a very straightforward way around the >> > problem. Because there will be a number of tests that must be in an >> > identical package name to the type under test then it seems that the >> > differentiating mark needs to be added to the test class name. Not >> > really sure what this could be. Given that we are all settled on the >> > convention that a test type has the "Test" suffix, how about just add >> > "Impl" to that suffix for implementation tests giving us an "ImplTest" >> > suffix. >> > e.g. >> > >> > class under test : java.lang.SomeClassTest >> > implementation-independent test class : >> > o.a.h.module.tests.java.lang.SomeClassTest >> > Harmony-specific test class : >> > o.a.h.module.tests.java.lang.SomeClassImplTest >> >> Or >> >> o.a.h..apitest.java.lang.FooTest >> o.a.h..impltest.java.lang.FooTest >> >> >> Of course, the implementation test didn't need to be on the >> bootclasspath, it would simply be >> >> java.lang.FooTest >> >> with no other garbage in the package name > > Hi Geir > > how to distinguish between bootclasspath implementation test > java.lang.FooTest > and bootclasspath api test > java.lang.FooTest Is there such thing as an bootclasspath API test? geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Multi-tree HDK config - working directory ( was Re: Supporting working on a single module?)
On 5/25/06, Oliver Deakin <[EMAIL PROTECTED]> wrote: Geir Magnusson Jr wrote: > Some stuff that got lost (because I got consumed by J1 and I was the > only one pushing on it) was the idea of ensuring that > > 1) the HDK could be anywhere - the was no hard-wired spot. That > allowed having multiple simultaneous HDKs (ex different snapshot > version) at the same time as a full build Perhaps the HDK would have a default location which could be overridden by passing a command line option to the build scripts - possibly in a similar way to Marks suggestion for selection of the rmi module location [1]. My modifications to build an HDK from the classlib code (HARMONY-469) use an Ant property hy.hdk to specify the root directory of the HDK. With the current patch, this property doesnt quite propagate all the way down to the native makefiles, but this shouldnt be too hard to extend. Once this was done, a developer could then override the default HDK location using a command line similar to: ant -Dhy.hdk=/my/hdk/location -f make/build.xml The default HDK location would probably depend on what area you are working on - in classlib the trunk/deploy directory is the default build location at the moment, and I think it makes sense to keep this as the default HDK directory. > > 2) the build should ensure that the materials of the HDK never get > overwritten so that we can always tell a contributor w/ a question > "first, before we debug this, do a ant hdk-copy.." or something to > easily get them to a known good state. > > This to me sounds like we need some kind of working directory and a > 'hdk-copy' target. > > The working model then allows freedom of choosing an hdk or a current > full build as the 'base' to work with... I imagine that an HDK would come in a zip format, much like the current snapshots [2]. If this was the case, then once you have downloaded the HDK zip, you can unpack it into your working directory where it will be modified. Oliver, whether does it mean the HDK will contain the sources (src.zip?) as well? Otherwise I don't understand what can be modified. Could you please clarify this? Thanks, Vladimir. However, you still have the original zip to fall back on if you need to. I'm not sure that we need an extra build target for this process - to get back to a known good state, you can just unpack the zip again into your working directory. Am I missing something? Regards, Oliver [1] http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200605.mbox/[EMAIL PROTECTED] [2] http://people.apache.org/dist/incubator/harmony/snapshots/ > > Does this make any sense to anyone else? > > geir > > > Oliver Deakin wrote: >> Hi all, >> >> I have opened HARMONY-485, which proposes an additional doc for the >> website describing the HDK and its contents. >> The layout of the HDK described in the doc matches that produced by >> the build script alterations raised in >> HARMONY-469. >> >> I hope that eventually (once the natives are modularised >> and build scripts are altered to understand/use the HDK) the doc will >> expand into a more full description of how developers can use the HDK >> to rebuild Java/native code. >> >> Regards, >> Oliver >> > > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Oliver Deakin IBM United Kingdom Limited - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DRLVM] proposal to port MMTK to drlvm
Excellent! Looks like GC is the favorite part of VM :) I also has an implementation of GC with better performance then GC_V4, which is currently used in DRLVM. With MMTk there will be a bunch of options to select. It is really interesting to have GC written in Java. I thought about it. Potentially, dynamicly compiled GC can give much more flexability and performance. I am looking forward to see the prototype. -- Ivan 2006/5/25, Xiao-Feng Li <[EMAIL PROTECTED]>: We have developed a GC prototype written in Java, which can work with DRLVM to run SPECJVM98. 1. The key idea of this work is not the GC itself (as a prototype), but the Java GC adapter. The idea is, we made the interface for C VM <-> Java GC interactions as an seperate adapter, so that hopefully different Java GCs can plugin to Harmony through this adapter. From Java GC side, it assumes all the interfaces it needs are written in Java; from the C VM side, it assumes all the interfaces to GC are written in C. So basically we need a Java class for the GC to VM invocation, and a C file to bridge the VM to GC invocation. 2. Another key idea of our approach is, it does not prebuild the Java GC as an image. Instead, we let the JVM itself to load the Java GC classes at runtime, and hook all the interfaces. This has a couple of implications: a) We need a JVM builtin primitive GC (I call it Root GC) to hold the preloaded Java objects and the Java GC objects. Root GC can be called as memory manager as well. b) With Root GC, we can enable the on-site debugging of Java GC with print support. The print support in Java GC requires Java string object to be generated. But theoretically collection is only happening when there is no heap to accomodate Java objects. Root GC can be used to hold the GC-time allocated objects. c) More GC adaptability can be achieved with Root GC, since the JVM can not only change the GC's configuration, but also replace the GC module at runtime. This is not necessarily a desirable feature to many users, but I think it doesn't hurt to have it if without any sacrifice. d) The pure runtime loading of a Java GC module means the JVM treats it partially as application code. It might be possible to debug the Java GC module as an application in Eclipse. Once this is achieved, it will largely ease the development of JVM modules in Java. Our prototype is very preliminary and based on the gc_mf bounded with DRLVM. It is still far from being complete regarding all the ideas above. If people think those are interesting, we'd like to contribute our work to Harmony after code cleanup. Thanks, xiaofeng == 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: Multi-tree HDK config - working directory ( was Re: Supporting working on a single module?)
Oliver Deakin wrote: Geir Magnusson Jr wrote: Some stuff that got lost (because I got consumed by J1 and I was the only one pushing on it) was the idea of ensuring that 1) the HDK could be anywhere - the was no hard-wired spot. That allowed having multiple simultaneous HDKs (ex different snapshot version) at the same time as a full build Perhaps the HDK would have a default location which could be overridden by passing a command line option to the build scripts - possibly in a similar way to Marks suggestion for selection of the rmi module location [1]. Yea, but the RMI thing is hopefully going to go away, right? :) My modifications to build an HDK from the classlib code (HARMONY-469) use an Ant property hy.hdk to specify the root directory of the HDK. With the current patch, this property doesnt quite propagate all the way down to the native makefiles, but this shouldnt be too hard to extend. Once this was done, a developer could then override the default HDK location using a command line similar to: ant -Dhy.hdk=/my/hdk/location -f make/build.xml The default HDK location would probably depend on what area you are working on - in classlib the trunk/deploy directory is the default build location at the moment, and I think it makes sense to keep this as the default HDK directory. That seems to work. 2) the build should ensure that the materials of the HDK never get overwritten so that we can always tell a contributor w/ a question "first, before we debug this, do a ant hdk-copy.." or something to easily get them to a known good state. This to me sounds like we need some kind of working directory and a 'hdk-copy' target. The working model then allows freedom of choosing an hdk or a current full build as the 'base' to work with... I imagine that an HDK would come in a zip format, much like the current snapshots [2]. If this was the case, then once you have downloaded the HDK zip, you can unpack it into your working directory where it will be modified. However, you still have the original zip to fall back on if you need to. I'm not sure that we need an extra build target for this process - to get back to a known good state, you can just unpack the zip again into your working directory. Am I missing something? Yah. Regards, Oliver [1] http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200605.mbox/[EMAIL PROTECTED] [2] http://people.apache.org/dist/incubator/harmony/snapshots/ Does this make any sense to anyone else? geir Oliver Deakin wrote: Hi all, I have opened HARMONY-485, which proposes an additional doc for the website describing the HDK and its contents. The layout of the HDK described in the doc matches that produced by the build script alterations raised in HARMONY-469. I hope that eventually (once the natives are modularised and build scripts are altered to understand/use the HDK) the doc will expand into a more full description of how developers can use the HDK to rebuild Java/native code. Regards, Oliver - 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] jetty based tests
I don't feel strongly about it -- I was simply responding to Geir's request that we have an option to test against a remote server. I think we can have that option if people want to. Regards, Tim Anton Luht wrote: > Good day, > >> I assume that we can have a test script config file to define the server >> location. We can have the default mode be starting the Jetty server on >> localhost (a.k.a. 'airplane mode' ), then if you want to run the >> server remotely the tests config would have to be updated... > > It seems to me that remote server is not requires in HTTP tests. The > only difference between local HTTP server and the remote one is that > the first is reached via loopback and the latter - via "real" net. > Testing of network connections is out of scope of HTTP functionality > tests so local server shoud be enough. > > Remote server has obvious drawbacks: > - if we compare in tests data fetched by via HTTP to some expected > result, it's likely that contents of remote site (say, apache.org) > will change and tests will fail > - some companies and providers don't allow to connect from internal > network to the Internet directly - 'telnet ... 80' will fail. The > direct connection functionality cannot be tested in this environment. > > Remote server is not required even for proxy tests - Jetty can be > configured to run as proxy server. > > The only problem with local server is choosing a local port to bind to > - port 80 is often used by another daemon. Test should try to start > Jetty on a free port and tell its number to the URLConnection test. > > My opinion is that remote server should not be used in tests - it's > problematic and doesn't give any advantages. > -- 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: Supporting working on a single module?
Oliver Deakin wrote: Geir Magnusson Jr wrote: On thing to think about (which I didn't realize until now) is that HDK should sit above /classlib in the tree right? the VMs will need it as well. I imagine : enhanced/ classlib/ drlvm/ jchevm/ bootvm/ So maybe add a enhanced/common directory in which the HDK sits by default? I'd like to avoid the structural balkanization of making classlib an island. I had imagined that HDKs would be packaged up as zips and made available in a similar way to snapshots, rather than having a tree of binaries checked into SVN. I think we all did. I don't know what about the above leads you to assume I would have wanted this in SVN. IMHO keeping it as a zip makes unpacking it where you want very simple, allows you to easily keep a "known good" HDK configuration locally (in the form of the original zip) and makes it very easy to get previous versions of the HDK (just download an earlier zip). I'd be interested to hear what general consensus on this matter is, and how mailing list members would prefer the HDK to be provided. Keeping zips around and all that is great, but is it that Eclipse would break having it up and above the root of the project tree? geir We discussed [1] that having separate HDKs for each VM and for classlib makes sense - as long as we keep them in a uniform shape, then they can easily overlaid onto each other to allow a developer to work on the classlib and the VM of their choice. I don't see this separation of classlib and VMs as a bad thing. I think that having a VMI enabling us to develop the classlib and VMs as distinct units, and developing using potentially disparate methods and build systems that most suit that component, is one of the cool things about Harmony! Regards, Oliver [1] http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200605.mbox/[EMAIL PROTECTED] geir Oliver Deakin wrote: Hi all, I have opened HARMONY-485, which proposes an additional doc for the website describing the HDK and its contents. The layout of the HDK described in the doc matches that produced by the build script alterations raised in HARMONY-469. I hope that eventually (once the natives are modularised and build scripts are altered to understand/use the HDK) the doc will expand into a more full description of how developers can use the HDK to rebuild Java/native code. Regards, Oliver - 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: Multi-tree HDK config - working directory ( was Re: Supporting working on a single module?)
Alexey Petrenko wrote: 2006/5/25, Oliver Deakin <[EMAIL PROTECTED]>: I imagine that an HDK would come in a zip format, much like the current snapshots [2]. I also suggest to add build date into zip name and internal directory name. Something like HDK_20060525/deploy and so on... Yes, I assumed we'd be stamping it that way, but it's good to state it so it can be discussed. It will let us keep few copies of HDK in the same place for testing purposes. That is what I've been driving at... it's a combination of either multiple version for testing a single codebase, one version for multiple development projects (Aka Mark), or a combination. Add in the variance w/ VMs... I think of this like the SDK. I have multiple different versions of the SDK on my machine (1.4, 5, ...) and when working in a project, I configure the environment to use the version I need. I don't keep them in zip files, and unzip the Java SDK into each project 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] jetty based tests
Tim Ellison wrote: Geir Magnusson Jr wrote: This thread was a long read :) Given that the argument is long and winding, can people do a checkpoint summary about how they are feeling? Does 'exhausted' count ;-) FWIW I also agree that using Jetty embedded in the tests is a good idea, with custom handlers etc. to force some test case scenarios. Where it doesn't work we can do stubs. I assume that we can have a test script config file to define the server location. We can have the default mode be starting the Jetty server on localhost (a.k.a. 'airplane mode' ), then if you want to run the server remotely the tests config would have to be updated... Exactly... I assumed that it was just a property in .properties file rather than a separate config, but we'll see what the impl comes up with, I suppose. 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] jetty based tests
Anton Luht wrote: Good day, I assume that we can have a test script config file to define the server location. We can have the default mode be starting the Jetty server on localhost (a.k.a. 'airplane mode' ), then if you want to run the server remotely the tests config would have to be updated... It seems to me that remote server is not requires in HTTP tests. The only difference between local HTTP server and the remote one is that the first is reached via loopback and the latter - via "real" net. Testing of network connections is out of scope of HTTP functionality tests so local server shoud be enough. How do you "pull the wire"? I think that having that option for testing things would be nice. Remote server has obvious drawbacks: - if we compare in tests data fetched by via HTTP to some expected result, it's likely that contents of remote site (say, apache.org) will change and tests will fail - some companies and providers don't allow to connect from internal network to the Internet directly - 'telnet ... 80' will fail. The direct connection functionality cannot be tested in this environment. Remote server is not required even for proxy tests - Jetty can be configured to run as proxy server. The only problem with local server is choosing a local port to bind to - port 80 is often used by another daemon. Test should try to start Jetty on a free port and tell its number to the URLConnection test. Autonomically? I don't think so - I think it should be a configuration parameter set by the tester so things are repeatable My opinion is that remote server should not be used in tests - it's problematic and doesn't give any advantages. It's a choice here. I agree it should not be *required*, and that by default, one should be able to run the test suite on an airplane when the airline isn't Lufthansa :) 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] jetty based tests
Yang Paulex wrote: +1 from me I also suggest we use Jetty as a singleton, so that we don't need to pay the overhead to find an available port and to start http server. Doesn't the above "don't need to pay the overhead to find an available port" conflict with the element #1 below, "lazily start Jetty when necessary on an available port" Sorry - I'm just confused. (I think that the port should be pre defined (well-known) have a default value, and be overridable in a properties/-ish file. geir The proposal is: 1. Some utility class in support project is responsible to lazily start Jetty when necessary on an available port in embedded mode, and to stop it when all test cases exit 2. every test class using Jetty is responsible to maintain its own context named as "//" and corresponding handler ideas and comments? 2006/5/25, Anton Luht <[EMAIL PROTECTED]>: Good day, > I assume that we can have a test script config file to define the server > location. We can have the default mode be starting the Jetty server on > localhost (a.k.a. 'airplane mode' ), then if you want to run the > server remotely the tests config would have to be updated... It seems to me that remote server is not requires in HTTP tests. The only difference between local HTTP server and the remote one is that the first is reached via loopback and the latter - via "real" net. Testing of network connections is out of scope of HTTP functionality tests so local server shoud be enough. Remote server has obvious drawbacks: - if we compare in tests data fetched by via HTTP to some expected result, it's likely that contents of remote site (say, apache.org) will change and tests will fail - some companies and providers don't allow to connect from internal network to the Internet directly - 'telnet ... 80' will fail. The direct connection functionality cannot be tested in this environment. Remote server is not required even for proxy tests - Jetty can be configured to run as proxy server. The only problem with local server is choosing a local port to bind to - port 80 is often used by another daemon. Test should try to start Jetty on a free port and tell its number to the URLConnection test. My opinion is that remote server should not be used in tests - it's problematic and doesn't give any advantages. -- Regards, Anton Luht, Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Created: (HARMONY-455) java.util.Formatter.format() is not implemented
Hi Richard, On 5/10/06, Richard Liang (JIRA) <[EMAIL PROTECTED]> wrote: java.util.Formatter.format() is not implemented. I will attach the patch soon. :-) Thanks a lot. Is there any progress? Thanks. -- Dmitry M. Kononov Intel Managed Runtime 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: Multi-tree HDK config - working directory ( was Re: Supporting working on a single module?)
Vladimir Gorr wrote: whether does it mean the HDK will contain the sources (src.zip?) as well? Otherwise I don't understand what can be modified. Could you please clarify this? I know you addressed to oliver, but let me take a wack at it to see if I grok everything One of the many motivations for the HDK idea was a refactoring of the natives into modules, which brought up the interdependency issue. To solve, the idea is top copy natives headers at build time into One Big Pile. So if you are in module foo, and working on something that modified foo.h, foo.h will be copied at build from module foo into One Big Pile, thereby overwriting the HDK's copy of foo.h, since the HDK and One Big Pile are conflated in the current model. I don't like this, because as I am a forgetful person, I may point another project/module at the HDK, and now will be tormented by strange things happening because the foo.h has been changed... That's why I've been suggesting a model (just for everyone's sanity, including people posting questions to the dev list), where the HDK is never modified, and there's a "working" area in the individual project tree where HDK + ThingsBeingWorkedOn are intermingled for the build process local to that individual project. geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[classlib] JAPI data to drive packages to completion
I was staring at the JAPI data last night. Can anyone think of a reason why we wouldn't suggest to people looking for something to do to use JAPI reports to help finish packages? 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] jetty based tests
On 5/25/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: Yang Paulex wrote: > +1 from me > > I also suggest we use Jetty as a singleton, so that we don't need to pay > the overhead to find an available port and to start http server. Doesn't the above "don't need to pay the overhead to find an available port" conflict with the element #1 below, "lazily start Jetty when necessary on an available port" I don't think "singleton" conflicts with "lazily start". Jetty server starts only once and starts up when there's some case needs it. :) Sorry - I'm just confused. (I think that the port should be pre defined (well-known) have a default value, and be overridable in a properties/-ish file. What's the problem if the port is selected automatically? If I understand correctly, it means Jetty selects a free port from system, and provides an API method (e.g. getJettyPort()) to get the selected port. In this way, listen port confliction issue could be completely avoided. geir > > The proposal is: > 1. Some utility class in support project is responsible to lazily start > Jetty when necessary on an available port in embedded mode, and to stop it > when all test cases exit > 2. every test class using Jetty is responsible to maintain its own context > named as "//" and corresponding handler > > ideas and comments? > > > 2006/5/25, Anton Luht <[EMAIL PROTECTED]>: >> >> Good day, >> >> > I assume that we can have a test script config file to define the >> server >> > location. We can have the default mode be starting the Jetty server on >> > localhost (a.k.a. 'airplane mode' ), then if you want to run the >> > server remotely the tests config would have to be updated... >> >> It seems to me that remote server is not requires in HTTP tests. The >> only difference between local HTTP server and the remote one is that >> the first is reached via loopback and the latter - via "real" net. >> Testing of network connections is out of scope of HTTP functionality >> tests so local server shoud be enough. >> >> Remote server has obvious drawbacks: >> - if we compare in tests data fetched by via HTTP to some expected >> result, it's likely that contents of remote site (say, apache.org) >> will change and tests will fail >> - some companies and providers don't allow to connect from internal >> network to the Internet directly - 'telnet ... 80' will fail. The >> direct connection functionality cannot be tested in this environment. >> >> Remote server is not required even for proxy tests - Jetty can be >> configured to run as proxy server. >> >> The only problem with local server is choosing a local port to bind to >> - port 80 is often used by another daemon. Test should try to start >> Jetty on a free port and tell its number to the URLConnection test. >> >> My opinion is that remote server should not be used in tests - it's >> problematic and doesn't give any advantages. >> >> -- >> Regards, >> Anton Luht, >> Intel Middleware Products Division >> >> - >> Terms of use : http://incubator.apache.org/harmony/mailing.html >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Andrew Zhang China Software Development Lab, IBM
RE: [classlib] jetty based tests
> -Original Message- > From: Andrew Zhang [mailto:[EMAIL PROTECTED] > Sent: Thursday, May 25, 2006 6:11 AM > To: harmony-dev@incubator.apache.org; [EMAIL PROTECTED] > Subject: Re: [classlib] jetty based tests > > On 5/25/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: > > > > > > > > Yang Paulex wrote: > > > +1 from me > > > > > > I also suggest we use Jetty as a singleton, so that we > don't need to > > pay > > > the overhead to find an available port and to start http server. > > > > Doesn't the above "don't need to pay the overhead to find > an available > > port" conflict with the element #1 below, "lazily start Jetty when > > necessary on an available port" > > > I don't think "singleton" conflicts with "lazily start". > Jetty server starts only once and starts up when there's some > case needs it. > :) Right - my confusion was about not wanting to find an available port due to some overhead that you discern. > > Sorry - I'm just confused. > > > > (I think that the port should be pre defined (well-known) > have a default > > value, and be overridable in a properties/-ish file. > > > What's the problem if the port is selected automatically? Repeatability. IMO, there should be no random elements in our testing. That leads to frustration, fear, despair, pathos, pain, agony, angst and much pulling of limited resources, like hair, in my case. > If I understand correctly, it means Jetty selects a free port > from system, > and provides an API method (e.g. getJettyPort()) to get the > selected port. > In this way, listen port confliction issue could be > completely avoided. Only once in my life have I seen a server randomly choose a port to listen on, and I quickly took that engineer off networking projects for a while :) 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: [website] harmony-dev agreements and recommendations
Guys, What do you think about the following recomendations? These are only 'recomendations' and not must have rules, but if these recomendations will become 'official' it will improve the quality of API in the long perspective. 1) Try avoid "magic number" nor "magic strings" in code ( the constant name by itself can be a good comment ) 2) Try to make all objects used for synchronization 'final' (we have a lot of non-final monitors in API, so we give a chance to bugs) 3) Never call to Boolean of Integer contructors (performance issue, there are a lot of such calls in our API) 4) Never do manual array copying (our crypto API does ) 5) Check if it's possible to make method static or private (performance issue, will help to devirtualizer a lot) On 5/25/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: Nice! Well done! -- Mikhail Fursov Intel Middleware Products Division
[tools] tools launching and javac
This is still work in progress, but thought it would be good to give a quick update on where I am at the moment: - I've tweaked the launcher to support running Java-based tools. There are still some limitations (see below), but the idea is that if the launcher is running as 'java' or 'javaw' it does "the usual thing", but if it is running as another name it will: (a) put tools.jar onto the classpath, (b) deal with the -J args properly, and (c) invoke a type called org.apache.harmony.tools..Main This means we can use the same launcher for all our Java-based tools. - I've implemented a wrapper to the Eclipse Compiler for Java(ECJ). The wrapper is called org.apache.harmony.tools.javac.Main, and I've put it into a 'tools' module. The wrapper simply loads ECJ and delegates the compile requests. If you want to try using our new javac tool: 1. do a normal Harmony build 2. compile the modules/tools code into tools.jar 3. grab the Eclipse compiler (ant -f make/depends.xml download) 4. put the tools.jar and ecj_3.2RC5.jar into jre/bin 5. copy jre/bin/java to jre/bin/javac Now you can run javac. Even better, if you want to help me complete it (or start work on another tool) here are the things left to do/limitations: - Since our launcher can switch VMs on the command line it assumes the VMs are directly accessible in subdirectories, so the launcher only works in jre/bin, not from a jdk-style bin directory. Fixing this requires a simple library load path tweak in the launcher code, and very possibly dealing with the harmony.properties messages. - For now, the o.a.h.tools.javac.Main wrapper looks for the compiler in a hard-coded JAR filename (ecj_3.2RC5.jar). Just wondering whether to embed that JAR in the tools.jar, or look for the compiler in *.jar, or ...? - Once I've flushed out any remaining bugs I need to hook the tools module into the build system so that tools.jar gets built along with everything else. - The launcher code needs some love, IMHO it could be cleaned up quite a bit. Just shout if you want to take on some of this stuff with me, you'd be warmly welcomed . 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: [website] harmony-dev agreements and recommendations
Mikhail Fursov wrote: Guys, What do you think about the following recomendations? These are only 'recomendations' and not must have rules, but if these recomendations will become 'official' it will improve the quality of API in the long perspective. 1) Try avoid "magic number" nor "magic strings" in code ( the constant name by itself can be a good comment ) That's a universal rule of programming, isn't it? :) 2) Try to make all objects used for synchronization 'final' (we have a lot of non-final monitors in API, so we give a chance to bugs) 3) Never call to Boolean of Integer contructors (performance issue, there are a lot of such calls in our API) 4) Never do manual array copying (our crypto API does ) 5) Check if it's possible to make method static or private (performance issue, will help to devirtualizer a lot) I'm happy if you note these, but explain why, and lets not call them "the law", as I'm sure that there will be situations where people will need to violate... geir On 5/25/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: Nice! Well done! - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tools] tools launching and javac
Tim Ellison wrote: This is still work in progress, but thought it would be good to give a quick update on where I am at the moment: - I've tweaked the launcher to support running Java-based tools. There are still some limitations (see below), but the idea is that if the launcher is running as 'java' or 'javaw' it does "the usual thing", but if it is running as another name it will: (a) put tools.jar onto the classpath, (b) deal with the -J args properly, and (c) invoke a type called org.apache.harmony.tools..Main This means we can use the same launcher for all our Java-based tools. - I've implemented a wrapper to the Eclipse Compiler for Java(ECJ). The wrapper is called org.apache.harmony.tools.javac.Main, and I've put it into a 'tools' module. The wrapper simply loads ECJ and delegates the compile requests. Cool If you want to try using our new javac tool: 1. do a normal Harmony build 2. compile the modules/tools code into tools.jar 3. grab the Eclipse compiler (ant -f make/depends.xml download) 4. put the tools.jar and ecj_3.2RC5.jar into jre/bin 5. copy jre/bin/java to jre/bin/javac Now you can run javac. Very cute! Do you intend module/tools to remain not part of the build? Even better, if you want to help me complete it (or start work on another tool) here are the things left to do/limitations: - Since our launcher can switch VMs on the command line it assumes the VMs are directly accessible in subdirectories, so the launcher only works in jre/bin, not from a jdk-style bin directory. Fixing this requires a simple library load path tweak in the launcher code, and very possibly dealing with the harmony.properties messages. - For now, the o.a.h.tools.javac.Main wrapper looks for the compiler in a hard-coded JAR filename (ecj_3.2RC5.jar). Just wondering whether to embed that JAR in the tools.jar, or look for the compiler in *.jar, or ...? Can we give it a 'known' pattern like "harmony_javac_ecj_3.2rc5.jar" or such so we can mechanically find it w/o a long search, yet also remember the version that we're using? - Once I've flushed out any remaining bugs I need to hook the tools module into the build system so that tools.jar gets built along with everything else. That answers the question above... :) - The launcher code needs some love, IMHO it could be cleaned up quite a bit. Just shout if you want to take on some of this stuff with me, you'd be warmly welcomed . Regards, Tim - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] jetty based tests
Magnusson, Geir wrote: -Original Message- From: Andrew Zhang [mailto:[EMAIL PROTECTED] Sent: Thursday, May 25, 2006 6:11 AM To: harmony-dev@incubator.apache.org; [EMAIL PROTECTED] Subject: Re: [classlib] jetty based tests If I understand correctly, it means Jetty selects a free port from system, and provides an API method (e.g. getJettyPort()) to get the selected port. In this way, listen port confliction issue could be completely avoided. Only once in my life have I seen a server randomly choose a port to listen on, and I quickly took that engineer off networking projects for a while :) I didn't mean this the way it sounds to me now :) Sorry. I can also see some uses for this. My example from my personal history was for high-performance production code, so you can see why I had a rather reflexive reaction... Still, I think there are a few problems with the above, such as having to have Jetty in the same process space, tying the test code to Jetty, and of course, the repeatability. I do see the utility of this though for convenience in some cases, and if we decide to do a runtime port selection, I'd have a helper do it and pass the selected port to both Jetty as well as the test code, so that the two things are decoupled. 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: [website] harmony-dev agreements and recommendations
On 5/25/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: > 1) Try avoid "magic number" nor "magic strings" in code ( the constant name > by itself can be a good comment ) That's a universal rule of programming, isn't it? :) Yes, and I listed it after reading our sources :), E.g. see JIRA482 problem or try to understand constants like java/util/jar/Attributes:87 ... I'm happy if you note these, but explain why, and lets not call them "the law", as I'm sure that there will be situations where people will need to violate... Yes, these ones can be only recomendations and can't be rules, because the most of them are performance related issues. E.g. nobody will file a bug like 'this method is protected but can be private" but if you have a thousands of such methods in API this will affect performance for a real percents.. -- Mikhail Fursov Intel Middleware Products Division
Re: [tools] tools launching and javac
Geir Magnusson Jr wrote: > Tim Ellison wrote: >> This is still work in progress, but thought it would be good to give a >> quick update on where I am at the moment: >> Now you can run javac. > > Very cute! Do you intend module/tools to remain not part of the build? It will become part of the build once it is as-good-as done. I'm trying to do a balancing act between /not/ dumping my junk into SVN as I go along, and developing in the open | collaboratively. Suggestions for re-balancing are more than welcome. >> - For now, the o.a.h.tools.javac.Main wrapper looks for the compiler in >> a hard-coded JAR filename (ecj_3.2RC5.jar). Just wondering whether to >> embed that JAR in the tools.jar, or look for the compiler in *.jar, or >> ...? > > Can we give it a 'known' pattern like "harmony_javac_ecj_3.2rc5.jar" or > such so we can mechanically find it w/o a long search, yet also remember > the version that we're using? The file ecj_3.2RC5.jar is the exact binary download from eclipse.org (renamed from their generic ecj.jar). Prefixing with harmony_ probably isn't appropriate, but I could pick-up the first ecj_*.jar that I find. 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: Supporting working on a single module?
Geir Magnusson Jr wrote: Oliver Deakin wrote: Geir Magnusson Jr wrote: On thing to think about (which I didn't realize until now) is that HDK should sit above /classlib in the tree right? the VMs will need it as well. I imagine : enhanced/ classlib/ drlvm/ jchevm/ bootvm/ So maybe add a enhanced/common directory in which the HDK sits by default? I'd like to avoid the structural balkanization of making classlib an island. I had imagined that HDKs would be packaged up as zips and made available in a similar way to snapshots, rather than having a tree of binaries checked into SVN. I think we all did. I don't know what about the above leads you to assume I would have wanted this in SVN. I think I'm just easily confused ;) So are you suggesting that the HDK should sit in a concrete location relative to whichever component (VM/classlib) we are working on, or that the HDK zips should be stored in SVN? (or something else...?) IMHO keeping it as a zip makes unpacking it where you want very simple, allows you to easily keep a "known good" HDK configuration locally (in the form of the original zip) and makes it very easy to get previous versions of the HDK (just download an earlier zip). I'd be interested to hear what general consensus on this matter is, and how mailing list members would prefer the HDK to be provided. Keeping zips around and all that is great, but is it that Eclipse would break having it up and above the root of the project tree? I dont see this as a problem. If you use the Ant scripts to build (which can be used within Eclipse), then an hy.hdk property (described in one of my other mails in this thread) that can be set to point at an HDK will enable you to use any location. If you wanted to work on Java code as a Java project under Eclipse, then you should only have to point Eclipse at the jre under your HDK and Eclipse will build against it. Regards, Oliver geir We discussed [1] that having separate HDKs for each VM and for classlib makes sense - as long as we keep them in a uniform shape, then they can easily overlaid onto each other to allow a developer to work on the classlib and the VM of their choice. I don't see this separation of classlib and VMs as a bad thing. I think that having a VMI enabling us to develop the classlib and VMs as distinct units, and developing using potentially disparate methods and build systems that most suit that component, is one of the cool things about Harmony! Regards, Oliver [1] http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200605.mbox/[EMAIL PROTECTED] geir Oliver Deakin wrote: Hi all, I have opened HARMONY-485, which proposes an additional doc for the website describing the HDK and its contents. The layout of the HDK described in the doc matches that produced by the build script alterations raised in HARMONY-469. I hope that eventually (once the natives are modularised and build scripts are altered to understand/use the HDK) the doc will expand into a more full description of how developers can use the HDK to rebuild Java/native code. Regards, Oliver - 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] -- 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] JAPI data to drive packages to completion
That's what I've been using, so I would say it's a fairly good place to start. The other technique I use in conjunction is generating the javadoc from the Harmony source. This allows for some noticing some of the larger holes when visually comparing it to the specification. The other piece that might be interesting is running one of those tools that scans for TODO and FIXME comments and reports the what and where. -Nathan > -Original Message- > From: Geir Magnusson Jr [mailto:[EMAIL PROTECTED] > Sent: Thursday, May 25, 2006 6:57 AM > To: harmony-dev@incubator.apache.org > Subject: [classlib] JAPI data to drive packages to completion > > I was staring at the JAPI data last night. Can anyone think of a reason > why we wouldn't suggest to people looking for something to do to use > JAPI reports to help finish packages? > > geir > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] jetty based tests
Good day, > The only problem with local server is choosing a local port to bind to > - port 80 is often used by another daemon. Test should try to start > Jetty on a free port and tell its number to the URLConnection test. Autonomically? I don't think so - I think it should be a configuration parameter set by the tester so things are repeatable I don't insist on auto-picking the port - I just wanted to draw attention to busy ports problem. Configuration parameter is fine, too. > My opinion is that remote server should not be used in tests - it's > problematic and doesn't give any advantages. > It's a choice here. I agree it should not be *required*, and that by default, one should be able to run the test suite on an airplane when the airline isn't Lufthansa :) Sure - if there's a test that connects to a remote server, it's better to put it as a bonus rather than to throw it away :) -- 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: [website] harmony-dev agreements and recommendations
2006/5/25, Mikhail Fursov <[EMAIL PROTECTED]>: On 5/25/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: > > > > > 1) Try avoid "magic number" nor "magic strings" in code ( the constant > name > > by itself can be a good comment ) > > That's a universal rule of programming, isn't it? :) Yes, and I listed it after reading our sources :), E.g. see JIRA482 problem or try to understand constants like java/util/jar/Attributes:87 >... > I'm happy if you note these, but explain why, and lets not call them > "the law", as I'm sure that there will be situations where people will > need to violate... Yes, these ones can be only recomendations and can't be rules, because the most of them are performance related issues. E.g. nobody will file a bug like 'this method is protected but can be private" Why not? Thanks, Mikhail but if you have a thousands of such methods in API this will affect performance for a real percents.. -- Mikhail Fursov 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: [website] harmony-dev agreements and recommendations
2006/5/25, Mikhail Fursov <[EMAIL PROTECTED]>: Guys, What do you think about the following recomendations? These are only 'recomendations' and not must have rules, but if these recomendations will become 'official' it will improve the quality of API in the long perspective. 1) Try avoid "magic number" nor "magic strings" in code ( the constant name by itself can be a good comment ) 2) Try to make all objects used for synchronization 'final' (we have a lot of non-final monitors in API, so we give a chance to bugs) Could you please explain with details and an example? 3) Never call to Boolean of Integer contructors (performance issue, there are a lot of such calls in our API) Again, an example would be useful. 4) Never do manual array copying (our crypto API does ) What do you mean by 'manual array copying'? How it should be done and why? Thanks, Mikhail 5) Check if it's possible to make method static or private (performance issue, will help to devirtualizer a lot) On 5/25/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: > > Nice! Well done! > > > -- Mikhail Fursov 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: [website] harmony-dev agreements and recommendations
Ok, I will "quote" you in future :) On 5/25/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote: 2006/5/25, Mikhail Fursov <[EMAIL PROTECTED]>: > Yes, these ones can be only recomendations and can't be rules, because the > most of them are performance related issues. E.g. nobody will file a bug > like 'this method is protected but can be private" Why not? Thanks, Mikhail -- Mikhail Fursov Intel Middleware Products Division
Re: jchevm status?
FYI, I have sent ACQ and ICLA to apache fax. -- Ivan 2006/5/23, Archie Cobbs <[EMAIL PROTECTED]>: Weldon Washburn wrote: > Please hold off the check-in for a few days. I would like to try > Ivan's mods on my machine to make certain they are complete. The > intention is to reduce the chance of secondary patch-up check-ins and > the related blizzard of emails. No problem.. I'll wait for both (a) your confirmation and (b) Apache contributor license thingie. -Archie - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tools] tools launching and javac
Tim Ellison wrote: Geir Magnusson Jr wrote: Tim Ellison wrote: This is still work in progress, but thought it would be good to give a quick update on where I am at the moment: Now you can run javac. Very cute! Do you intend module/tools to remain not part of the build? It will become part of the build once it is as-good-as done. I'm trying to do a balancing act between /not/ dumping my junk into SVN as I go along, and developing in the open | collaboratively. Suggestions for re-balancing are more than welcome. Only suggestion is to do a branches/tim/stuff1, work in there if you want people to comment (with the bonus of having it in SVN in case of problem). It's COW so the space usage won't be that bad, and you can just delete when done. - For now, the o.a.h.tools.javac.Main wrapper looks for the compiler in a hard-coded JAR filename (ecj_3.2RC5.jar). Just wondering whether to embed that JAR in the tools.jar, or look for the compiler in *.jar, or ...? Can we give it a 'known' pattern like "harmony_javac_ecj_3.2rc5.jar" or such so we can mechanically find it w/o a long search, yet also remember the version that we're using? The file ecj_3.2RC5.jar is the exact binary download from eclipse.org (renamed from their generic ecj.jar). Prefixing with harmony_ probably isn't appropriate, but I could pick-up the first ecj_*.jar that I find. I guess ecj_* works too... - 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] Layout of tests in crypto module
2006/5/25, Geir Magnusson Jr <[EMAIL PROTECTED]>: We could always just partition in the filesystem and separate the test runs for bootclasspath API, and bootclasspath implementation? The problem is that we have a single directory where we put results. So if we run all the tests including both impl and api at once then result of the second test being run will overwrite result of the first one Mikhail - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Supporting working on a single module?
Oliver Deakin wrote: Geir Magnusson Jr wrote: Oliver Deakin wrote: Geir Magnusson Jr wrote: On thing to think about (which I didn't realize until now) is that HDK should sit above /classlib in the tree right? the VMs will need it as well. I imagine : enhanced/ classlib/ drlvm/ jchevm/ bootvm/ So maybe add a enhanced/common directory in which the HDK sits by default? I'd like to avoid the structural balkanization of making classlib an island. I had imagined that HDKs would be packaged up as zips and made available in a similar way to snapshots, rather than having a tree of binaries checked into SVN. I think we all did. I don't know what about the above leads you to assume I would have wanted this in SVN. I think I'm just easily confused ;) So are you suggesting that the HDK should sit in a concrete location relative to whichever component (VM/classlib) we are working on, or that the HDK zips should be stored in SVN? (or something else...?) I think that the HDK should be a zip/tar that you download from our distro locations(s), and dropped into a) a well-known default location b) anywhere you want so you can set a pointer if you have more than one and no, they aren't stored in SVN. IMHO keeping it as a zip makes unpacking it where you want very simple, allows you to easily keep a "known good" HDK configuration locally (in the form of the original zip) and makes it very easy to get previous versions of the HDK (just download an earlier zip). I'd be interested to hear what general consensus on this matter is, and how mailing list members would prefer the HDK to be provided. Keeping zips around and all that is great, but is it that Eclipse would break having it up and above the root of the project tree? I dont see this as a problem. If you use the Ant scripts to build (which can be used within Eclipse), then an hy.hdk property (described in one of my other mails in this thread) that can be set to point at an HDK will enable you to use any location. If you wanted to work on Java code as a Java project under Eclipse, then you should only have to point Eclipse at the jre under your HDK and Eclipse will build against it. Cool Regards, Oliver geir We discussed [1] that having separate HDKs for each VM and for classlib makes sense - as long as we keep them in a uniform shape, then they can easily overlaid onto each other to allow a developer to work on the classlib and the VM of their choice. I don't see this separation of classlib and VMs as a bad thing. I think that having a VMI enabling us to develop the classlib and VMs as distinct units, and developing using potentially disparate methods and build systems that most suit that component, is one of the cool things about Harmony! Regards, Oliver [1] http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200605.mbox/[EMAIL PROTECTED] geir Oliver Deakin wrote: Hi all, I have opened HARMONY-485, which proposes an additional doc for the website describing the HDK and its contents. The layout of the HDK described in the doc matches that produced by the build script alterations raised in HARMONY-469. I hope that eventually (once the natives are modularised and build scripts are altered to understand/use the HDK) the doc will expand into a more full description of how developers can use the HDK to rebuild Java/native code. Regards, Oliver - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] JAPI data to drive packages to completion
Nathan Beyer wrote: That's what I've been using, so I would say it's a fairly good place to start. The other technique I use in conjunction is generating the javadoc from the Harmony source. This allows for some noticing some of the larger holes when visually comparing it to the specification. The other piece that might be interesting is running one of those tools that scans for TODO and FIXME comments and reports the what and where. I thought IDEA and Eclipse do this geir -Nathan -Original Message- From: Geir Magnusson Jr [mailto:[EMAIL PROTECTED] Sent: Thursday, May 25, 2006 6:57 AM To: harmony-dev@incubator.apache.org Subject: [classlib] JAPI data to drive packages to completion I was staring at the JAPI data last night. Can anyone think of a reason why we wouldn't suggest to people looking for something to do to use JAPI reports to help finish packages? geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Stress tests] generator: looking forward
Geir, I've tried to put this proposal to the site. Please see the patch at http://issues.apache.org/jira/browse/HARMONY-511 - hope I did it correctly. -- Regards, Anton Luht, Intel Middleware Products Division On 5/23/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: How about a patch for the website, including instructions on what to do? Fedotov, Alexei A wrote: > Alex, > >> Please, find the new version (0.2) and all previous versions here: >> http://issues.apache.org/jira/secure/ManageAttachments.jspa?id=12340105 > > Good. I like it (everyone likes when his suggestions are implemented > :-). So let me try to outline where we are in Harmony stress testing. > > === TEST DESIGN === > >* Stress tests are built from simple building blocks according to > configuration strings. > >* Tests have junit interface. >[Case study] Imagine someone puts tests into SVN which implements > different test interface. To reuse them we can add another generator to > convert these tests to junit interface. > >* Configuration string list is maintained manually. If we plan to use > junit runner to launch a sequent of the stress tests, then the most > straightforward model is to wrap configuration strings into junit test > cases and put documentation into javadoc for these test cases. > > === FURTHER STEPS === > >* You wrote, "stress test suite should generate relevant bugs". Since > usually stress behavior is unspecified, we need to introduce something > measurable instead of pass/fail result for the stress tests. See my > thoughts about a comparative approach below. > >* I will continue code reviews. > >* All should create tests and run them against Harmony VM and RI. > This would be a real-life testing for our approach. > > === COMPARATIVE APPROACH === > > The simplest example of comparative apporach is the following. > Tester: My test fails on Harmony VM and passes on RI. Please, > fix Harmony VM. > > This usually does not work for stress tests. > Developer: Who told you that OutOfMemoryError should be thrown > in your thread? My finalizer thread is just a normal java thread, like > yours, and it can fail as well. You have a bug in your test. > > There are multiple reasons why we always will have such bugs in the > tests. >* These bugs keep showing up. The time to fix all these bugs > regularly is too high. >* Stress testing reuses tests which are usually not designed for > stress execution, for example, multithread execution. >* These bugs are dependent on VM internal structure. Test authors do > not posess sufficient knowledge of the problem and the structure. >* Sometimes Java is not rich enough. > > How can we have a maintainable test product takung all this limitation > into account? We need to learn how to live with occasional failures of > the stress tests. This means, instead of fail, the test should better > report how good it is on Harmony VM compared to RI: >* Failures with the worst relative metric can be evaluated first. >* We can detect that a relative metric for a test worsened on the > recent build. > > Developers are better convinsed to fix "the worst issue" or > "dergadation" instead of "some issue". > > Now let me list here several metrics for each test. >* Pass rate: assuming the test is 100% reliable on RI we can > calculate a percentage of failures. >* Number of times the test can be executed sequentionally before a > fail. >* Memory consumption: a generator can preallocate more and more > memory before launching the test in a loop. >* Max threads supported: a generator can exponentially increase > number of threads launching the test in parallel. >* Here is your metric. >* Execution time: have you noticed that all this apparatus is quite > close to performance testing methodology? There is no need to compete > with them in their field though. :-) > > The thing I like most about this approach is it can be introduced on a > stress test generator level. > > With best regards, > Alexei Fedotov, > Intel Middleware Products Division > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [website] harmony-dev agreements and recommendations
Mikhail Fursov skrev den 25-05-2006 15:22: Guys, What do you think about the following recomendations? These are only 'recomendations' and not must have rules, but if these recomendations will become 'official' it will improve the quality of API in the long perspective. 1) Try avoid "magic number" nor "magic strings" in code ( the constant name by itself can be a good comment ) 2) Try to make all objects used for synchronization 'final' (we have a lot of non-final monitors in API, so we give a chance to bugs) 3) Never call to Boolean of Integer contructors (performance issue, there are a lot of such calls in our API) 4) Never do manual array copying (our crypto API does ) 5) Check if it's possible to make method static or private (performance issue, will help to devirtualizer a lot) Would it be possible to write these as CheckStyle rules? That would make them easy to spot and easy to check against. (or any other automated code style checker) -- Thorbjørn smime.p7s Description: S/MIME Cryptographic Signature
Re: Supporting working on a single module?
Geir Magnusson Jr wrote: Oliver Deakin wrote: Geir Magnusson Jr wrote: Oliver Deakin wrote: Geir Magnusson Jr wrote: On thing to think about (which I didn't realize until now) is that HDK should sit above /classlib in the tree right? the VMs will need it as well. I imagine : enhanced/ classlib/ drlvm/ jchevm/ bootvm/ So maybe add a enhanced/common directory in which the HDK sits by default? I'd like to avoid the structural balkanization of making classlib an island. I had imagined that HDKs would be packaged up as zips and made available in a similar way to snapshots, rather than having a tree of binaries checked into SVN. I think we all did. I don't know what about the above leads you to assume I would have wanted this in SVN. I think I'm just easily confused ;) So are you suggesting that the HDK should sit in a concrete location relative to whichever component (VM/classlib) we are working on, or that the HDK zips should be stored in SVN? (or something else...?) I think that the HDK should be a zip/tar that you download from our distro locations(s), and dropped into a) a well-known default location b) anywhere you want so you can set a pointer if you have more than one and no, they aren't stored in SVN. Sounds good! IMHO keeping it as a zip makes unpacking it where you want very simple, allows you to easily keep a "known good" HDK configuration locally (in the form of the original zip) and makes it very easy to get previous versions of the HDK (just download an earlier zip). I'd be interested to hear what general consensus on this matter is, and how mailing list members would prefer the HDK to be provided. Keeping zips around and all that is great, but is it that Eclipse would break having it up and above the root of the project tree? I dont see this as a problem. If you use the Ant scripts to build (which can be used within Eclipse), then an hy.hdk property (described in one of my other mails in this thread) that can be set to point at an HDK will enable you to use any location. If you wanted to work on Java code as a Java project under Eclipse, then you should only have to point Eclipse at the jre under your HDK and Eclipse will build against it. Cool Regards, Oliver geir We discussed [1] that having separate HDKs for each VM and for classlib makes sense - as long as we keep them in a uniform shape, then they can easily overlaid onto each other to allow a developer to work on the classlib and the VM of their choice. I don't see this separation of classlib and VMs as a bad thing. I think that having a VMI enabling us to develop the classlib and VMs as distinct units, and developing using potentially disparate methods and build systems that most suit that component, is one of the cool things about Harmony! Regards, Oliver [1] http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200605.mbox/[EMAIL PROTECTED] geir Oliver Deakin wrote: Hi all, I have opened HARMONY-485, which proposes an additional doc for the website describing the HDK and its contents. The layout of the HDK described in the doc matches that produced by the build script alterations raised in HARMONY-469. I hope that eventually (once the natives are modularised and build scripts are altered to understand/use the HDK) the doc will expand into a more full description of how developers can use the HDK to rebuild Java/native code. Regards, Oliver - 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] -- 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: [website] harmony-dev agreements and recommendations
On 5/25/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote: > 2) Try to make all objects used for synchronization 'final' (we have a lot > of non-final monitors in API, so we give a chance to bugs) Could you please explain with details and an example? This is not a bug (E.g. ExemptionMechanism:47, BeanContextSupport:149) but such code may lead (in theory or in future) to deadlock because it allows different threads to use different locks in the same object instance. Also when you analyse 'synchronized' pattern the 'final' modifier for a lock really helps in understanding code and locks logic. 3) Never call to Boolean of Integer contructors (performance issue, there > are a lot of such calls in our API) Again, an example would be useful. grep "new Boolean" or "new Integer" over the sources. You fill find > 100 samples. New object creation when it's possible to use static and cached instances is a bad practice from the performance point of view. 4) Never do manual array copying (our crypto API does ) What do you mean by 'manual array copying'? How it should be done and why? This is manual copying of arrays in loop instead of System.arraycopy() call (System.arraycopy() can be implemented as performance primitive in VM or JIT) Check this code as example: ExemptionMechanism:249, Statement:164 Thanks, Mikhail -- Mikhail Fursov Intel Middleware Products Division
Re: Multi-tree HDK config - working directory ( was Re: Supporting working on a single module?)
Vladimir Gorr wrote: On 5/25/06, Oliver Deakin <[EMAIL PROTECTED]> wrote: Geir Magnusson Jr wrote: > Some stuff that got lost (because I got consumed by J1 and I was the > only one pushing on it) was the idea of ensuring that > > 1) the HDK could be anywhere - the was no hard-wired spot. That > allowed having multiple simultaneous HDKs (ex different snapshot > version) at the same time as a full build Perhaps the HDK would have a default location which could be overridden by passing a command line option to the build scripts - possibly in a similar way to Marks suggestion for selection of the rmi module location [1]. My modifications to build an HDK from the classlib code (HARMONY-469) use an Ant property hy.hdk to specify the root directory of the HDK. With the current patch, this property doesnt quite propagate all the way down to the native makefiles, but this shouldnt be too hard to extend. Once this was done, a developer could then override the default HDK location using a command line similar to: ant -Dhy.hdk=/my/hdk/location -f make/build.xml The default HDK location would probably depend on what area you are working on - in classlib the trunk/deploy directory is the default build location at the moment, and I think it makes sense to keep this as the default HDK directory. > > 2) the build should ensure that the materials of the HDK never get > overwritten so that we can always tell a contributor w/ a question > "first, before we debug this, do a ant hdk-copy.." or something to > easily get them to a known good state. > > This to me sounds like we need some kind of working directory and a > 'hdk-copy' target. > > The working model then allows freedom of choosing an hdk or a current > full build as the 'base' to work with... I imagine that an HDK would come in a zip format, much like the current snapshots [2]. If this was the case, then once you have downloaded the HDK zip, you can unpack it into your working directory where it will be modified. Oliver, whether does it mean the HDK will contain the sources (src.zip?) as well? Otherwise I don't understand what can be modified. Could you please clarify this? Hi Vladimir, When you rebuild, the old versions of binaries (dll/so/jar etc.) would be overwritten with the new versions that are built from your altered code, and potentially altered header files will be replaced (e.g. jni.h). This is similar to the current system, where you can use a snapshot build to rebuild Java code against, and you can then drop your rebuilt jars over those of the snapshot to create an updated jre. The HDK will contain binaries to build against, and some necessary header files, but no complete src.zip. I have put up a proposed description of the HDK on the website [1], which summarises some of the ideas in this thread so far. I hope it helps clarify :) Regards, Oliver [1] http://incubator.apache.org/harmony/subcomponents/classlibrary/hdk.html Thanks, Vladimir. However, you still have the original zip to fall back on if you need to. I'm not sure that we need an extra build target for this process - to get back to a known good state, you can just unpack the zip again into your working directory. Am I missing something? Regards, Oliver [1] http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200605.mbox/[EMAIL PROTECTED] [2] http://people.apache.org/dist/incubator/harmony/snapshots/ > > Does this make any sense to anyone else? > > geir > > > Oliver Deakin wrote: >> Hi all, >> >> I have opened HARMONY-485, which proposes an additional doc for the >> website describing the HDK and its contents. >> The layout of the HDK described in the doc matches that produced by >> the build script alterations raised in >> HARMONY-469. >> >> I hope that eventually (once the natives are modularised >> and build scripts are altered to understand/use the HDK) the doc will >> expand into a more full description of how developers can use the HDK >> to rebuild Java/native code. >> >> Regards, >> Oliver >> > > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Oliver Deakin IBM United Kingdom Limited - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- 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: jchevm status?
Great! Thanks! geir Ivan Volosyuk wrote: FYI, I have sent ACQ and ICLA to apache fax. -- Ivan 2006/5/23, Archie Cobbs <[EMAIL PROTECTED]>: Weldon Washburn wrote: > Please hold off the check-in for a few days. I would like to try > Ivan's mods on my machine to make certain they are complete. The > intention is to reduce the chance of secondary patch-up check-ins and > the related blizzard of emails. No problem.. I'll wait for both (a) your confirmation and (b) Apache contributor license thingie. -Archie - 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: [website] harmony-dev agreements and recommendations
Hi Mikhail
2006/5/25, Mikhail Fursov <[EMAIL PROTECTED]>:
On 5/25/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote:
>
> > 2) Try to make all objects used for synchronization 'final' (we have a
> lot
> > of non-final monitors in API, so we give a chance to bugs)
>
> Could you please explain with details and an example?
This is not a bug (E.g. ExemptionMechanism:47, BeanContextSupport:149) but
such code may lead (in theory or in future) to deadlock because it allows
different threads to use different locks in the same object instance. Also
when you analyse 'synchronized' pattern the 'final' modifier for a lock
really helps in understanding code and locks logic.
Agreed that in some cases in theory it might lead to problems. So if it is
a recommendation rather than a strict law, then +1 from me.
> 3) Never call to Boolean of Integer contructors (performance issue, there
> > are a lot of such calls in our API)
>
> Again, an example would be useful.
grep "new Boolean" or "new Integer" over the sources. You fill find > 100
samples. New object creation when it's possible to use static and cached
instances is a bad practice from the performance point of view.
The first grep result is:
private PropertyChangeEvent createPropertyChangeEvent(
String propertyName, int oldValue, int newValue) {
return new PropertyChangeEvent(sourceBean, propertyName,
new Integer(oldValue), new Integer(newValue));
}
How do you suggest to make it better?
> 4) Never do manual array copying (our crypto API does )
>
> What do you mean by 'manual array copying'? How it should be done and why?
This is manual copying of arrays in loop instead of System.arraycopy() call
(System.arraycopy() can be implemented as performance primitive in VM or
JIT)
Check this code as example: ExemptionMechanism:249, Statement:164
Agreed here. BTW, if array has a lenght of 5 what is the best copying way?
Thanks,
Mikhail
Thanks,
> Mikhail
>
--
Mikhail Fursov
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] Layout of tests in crypto module
should we rethink this? Not just for this reason, but also for ease of data management as this thing grows... Mikhail Loenko wrote: 2006/5/25, Geir Magnusson Jr <[EMAIL PROTECTED]>: We could always just partition in the filesystem and separate the test runs for bootclasspath API, and bootclasspath implementation? The problem is that we have a single directory where we put results. So if we run all the tests including both impl and api at once then result of the second test being run will overwrite result of the first one Mikhail - 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: [website] harmony-dev agreements and recommendations
Mikhail Fursov wrote: On 5/25/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote: > 2) Try to make all objects used for synchronization 'final' (we have a lot > of non-final monitors in API, so we give a chance to bugs) Could you please explain with details and an example? This is not a bug (E.g. ExemptionMechanism:47, BeanContextSupport:149) but such code may lead (in theory or in future) to deadlock because it allows different threads to use different locks in the same object instance. Also when you analyse 'synchronized' pattern the 'final' modifier for a lock really helps in understanding code and locks logic. Time for me to learn something - I thought there was only one monitor per object how can different threads get different locks? 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: Multi-tree HDK config - working directory ( was Re: Supporting working on a single module?)
Geir Magnusson Jr wrote: Vladimir Gorr wrote: whether does it mean the HDK will contain the sources (src.zip?) as well? Otherwise I don't understand what can be modified. Could you please clarify this? I know you addressed to oliver, but let me take a wack at it to see if I grok everything One of the many motivations for the HDK idea was a refactoring of the natives into modules, which brought up the interdependency issue. To solve, the idea is top copy natives headers at build time into One Big Pile. From the work Im currently doing on attempting to move the native-src/*/include directory contents into their appropriate modules, using the modularised natives layout I described previously [1], the "One Big Pile" actually doesnt look that bad - for the classlib there are actually only 13 header files that need to be shared between modules, and we might be able to reduce these with extra work. So if you are in module foo, and working on something that modified foo.h, foo.h will be copied at build from module foo into One Big Pile, thereby overwriting the HDK's copy of foo.h, since the HDK and One Big Pile are conflated in the current model. foo.h will only be copied into the include area of the HDK if it is required by other modules. If it is only used by the natives in that module, it will stay where it is. I don't like this, because as I am a forgetful person, I may point another project/module at the HDK, and now will be tormented by strange things happening because the foo.h has been changed... That's why I've been suggesting a model (just for everyone's sanity, including people posting questions to the dev list), where the HDK is never modified, and there's a "working" area in the individual project tree where HDK + ThingsBeingWorkedOn are intermingled for the build process local to that individual project. Isnt that just overwriting a copy of the HDK instead of the original? What is the original HDK being used for then? Regards, Oliver [1] http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200605.mbox/[EMAIL PROTECTED] geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Oliver Deakin IBM United Kingdom Limited - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tools] tools launching and javac
On 25 May 2006 at 7:46, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: > > Tim Ellison wrote: > > Geir Magnusson Jr wrote: > >> Tim Ellison wrote: > >>> This is still work in progress, but thought it would be good to give a > >>> quick update on where I am at the moment: > > > >>> Now you can run javac. > >> Very cute! Do you intend module/tools to remain not part of the build? > > > > It will become part of the build once it is as-good-as done. > > > > I'm trying to do a balancing act between /not/ dumping my junk into SVN > > as I go along, and developing in the open | collaboratively. > > Suggestions for re-balancing are more than welcome. > > Only suggestion is to do a branches/tim/stuff1, work in there if you > want people to comment (with the bonus of having it in SVN in case of > problem). > > It's COW so the space usage won't be that bad, and you can just delete > when done. While that's true, I think that development on branches has other costs: * merging back into trunk * fewer people will pay attention - nothing personal but I might be less inclined to scan commits in branches/tim than trunk ;-) Personally, I think development is moving fast enough that it's not a problem having it in trunk. If it hadn't been in trunk, I might have been less inclined to test it ... and not had the incentive to fix the bugs (HARMONY-510) on my platform of choice. Obviously, we should avoid breaking things like this for too long but I think the occasional breakage is a fair price to pay for not having the other costs. Of course, I seem to be the only one who even noticed this problem. Regards, Mark. > > > > > >>> - For now, the o.a.h.tools.javac.Main wrapper looks for the compiler in > >>> a hard-coded JAR filename (ecj_3.2RC5.jar). Just wondering whether to > >>> embed that JAR in the tools.jar, or look for the compiler in *.jar, or > >>> ...? > >> Can we give it a 'known' pattern like "harmony_javac_ecj_3.2rc5.jar" or > >> such so we can mechanically find it w/o a long search, yet also remember > >> the version that we're using? > > > > The file ecj_3.2RC5.jar is the exact binary download from eclipse.org > > (renamed from their generic ecj.jar). Prefixing with harmony_ probably > > isn't appropriate, but I could pick-up the first ecj_*.jar that I find. > > I guess ecj_* works too... > > > > > - > 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: [website] harmony-dev agreements and recommendations
On 25. mai. 2006, at 17.42, Geir Magnusson Jr wrote:
Time for me to learn something - I thought there was only one
monitor per object how can different threads get different locks?
Hi, as I understand it, you use final on monitors to prevent the
following from happening:
Let's say you have a monitor:
private Object monitor;
Then you somewhere have:
public foo() {
monitor = new Object();
}
If by any chance foo() should be called twice you in effect have two
monitors around. One before foo was called the second time (and some
thread may hold a lock on it) and one after. The monitor should of
course not be made in such a method, but the idea is that by making all
monitors final you are sure you don't make this mistake.
So if anyone asked me, I'd say +1 to the final on monitors guideline.
geir
-- Erik Axel
-
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] Layout of tests in crypto module
Mikhail Loenko wrote: 2006/5/24, Geir Magnusson Jr <[EMAIL PROTECTED]>: George Harley wrote: > Hi Mikhail, > > That is a very good point and your suggestion of supplementing the class > or package name sounds like a very straightforward way around the > problem. Because there will be a number of tests that must be in an > identical package name to the type under test then it seems that the > differentiating mark needs to be added to the test class name. Not > really sure what this could be. Given that we are all settled on the > convention that a test type has the "Test" suffix, how about just add > "Impl" to that suffix for implementation tests giving us an "ImplTest" > suffix. > e.g. > > class under test : java.lang.SomeClassTest > implementation-independent test class : > o.a.h.module.tests.java.lang.SomeClassTest > Harmony-specific test class : > o.a.h.module.tests.java.lang.SomeClassImplTest Or o.a.h..apitest.java.lang.FooTest o.a.h..impltest.java.lang.FooTest Of course, the implementation test didn't need to be on the bootclasspath, it would simply be java.lang.FooTest with no other garbage in the package name Hi Geir how to distinguish between bootclasspath implementation test java.lang.FooTest and bootclasspath api test java.lang.FooTest ? Hello Mikhail, Could you please explain why we need bootclasspath api test? Thanks a lot. Best regards, Richard Thanks, Mikhail geir > > My 2 Euro cents... > George > > > > Mikhail Loenko wrote: >> That sounds very reasonable, but I have a problem: >> >> I tried to implement it and found that as far as we put all test results >> into a single directory and generate a single report, we can't have >> different tests with the same name. >> >> For example we can't have impl and api tests of >> o.a.h.module.tests.java.lang.SomeClassTest >> Looks like we should put some differentiating mark to a class or >> package name. >> >> Thanks, >> Mikhail >> >> 2006/5/18, George Harley <[EMAIL PROTECTED]>: >>> Mikhail Loenko wrote: >>> > Hi George, >>> > >>> > I use ant to build and run the tests, so I'm likely unaware of some >>> > Eclipse >>> > problems. >>> > >>> > If we put classpath test classes to >>> > impl/java and api/java >>> > and bootclasspath ones to something like >>> > impl/java.injected and api/java.injected >>> > will it solve the problem you describe? >>> > >>> > Thanks, >>> > Mikhail >>> > >>> > >>> >>> Hi Mikhail, >>> >>> Yes, I think that compiling to separate bin folders would do the trick ; >>> a bin for stuff that will go on the classpath and a bin for stuff that >>> will be loaded on the bootclasspath. In order to reach that goal the >>> test source itself will AFAIK need to be laid out in a similar manner. >>> That is, the directory tree will look something like the following (may >>> need to be viewed in wide-screen): >>> >>> >>> src/test/api/java <--- implementation-independent tests >>> intended to be loaded by system class loader, compiled to bin >>> >>> src/test/api/java.injected<--- implementation-independent tests >>> intended to be loaded by boot class loader, compiled to bin.injected >>> >>> src/test/impl/java <--- Harmony-specific tests intended to >>> be loaded by system class loader, compiled to bin >>> >>> src/test/impl/java.injected<--- Harmony-specific tests intended to >>> be loaded by boot class loader, compiled to bin.injected >>> >>> >>> >>> Does that sound reasonable ? >>> >>> >>> Best regards, >>> George >>> >>> >>> > 2006/5/17, George Harley <[EMAIL PROTECTED]>: >>> >> Mikhail Loenko wrote: >>> >> > 2006/5/16, George Harley <[EMAIL PROTECTED]>: >>> >> >> Mikhail Loenko wrote: >>> >> >> > Hi George, see below >>> >> >> > >>> >> >> > 2006/5/16, George Harley <[EMAIL PROTECTED]>: >>> >> >> >> Hi Mikhail, >>> >> >> >> >>> >> >> >> I have a couple of minor comments about your proposal for a >>> test >>> >> >> >> layouts. I should have responded sooner, I know, but I have >>> >> suffered >>> >> >> >> from a number of hardware problems in the past few weeks that >>> >> slowed >>> >> >> >> things down somewhat for me. Anyway, it's all great but it >>> would >>> >> >> be nice >>> >> >> >> to get answers to the following ... >>> >> >> >> >>> >> >> >> 1) The section on "Location of the tests in the directory tree" >>> >> >> >> proposes /src/tests/impl for Harmony specific tests >>> >> and >>> >> >> >> /src/tests/api for implementation-independent >>> tests. >>> >> >> Where >>> >> >> >> would tests go for Harmony API's that are not part of the J2SE >>> >> >> spec but >>> >> >> >> are still accessible ? Strictly speaking they are API as >>> well as >>> >> >> being >>> >> >> >> specific to Harmony. >>> >> >> > >>> >> >> > The main idea is to separate tests that must pass on any >>> conformant >>> >> >> > implementation from the tests passing on Harmony only. >>> >> >> > >>> >> >> > When these are separated we can e.g. easily validate >>> >> "implementation- >
Re: [website] harmony-dev agreements and recommendations
Yes, you are right: different threads can get different locks only on
different objects.
Lets see BenContextSupport code as example:
private void addChild(Object targetChild) {
// Add a new child using targetChild as a key and
// its BCSChild instance as an entry
synchronized(this.children) {
BCSChild ch = createBCSChild(targetChild, getBeanContextPeer());
this.children.put(targetChild, ch);
childJustAddedHook(targetChild, ch);
}
// Fire memebership event
fireChildrenAdded(getBCME(new Object[] { targetChild }));
}
'this.children' is not final and even not private -> so developer
allows to change this field in runtime. But if field can be changed the
methods in synchronized block can be called simultaneously by different
threads. Today everything is OK with this code. But in future this could be
a reason for a bug.
On 5/25/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote:
Time for me to learn something - I thought there was only one monitor
per object how can different threads get different locks?
geir
--
Mikhail Fursov
Intel Middleware Products Division
Re: [website] harmony-dev agreements and recommendations
On 5/25/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote:
The first grep result is:
private PropertyChangeEvent createPropertyChangeEvent(
String propertyName, int oldValue, int newValue) {
return new PropertyChangeEvent(sourceBean, propertyName,
new Integer(oldValue), new Integer(newValue));
}
How do you suggest to make it better?
Integer.valueOf, Boolean.valueOf. For Boolean new object is never created.
> > 4) Never do manual array copying (our crypto API does )
> >
> > What do you mean by 'manual array copying'? How it should be done and
why?
>
>
> This is manual copying of arrays in loop instead of System.arraycopy()
call
> (System.arraycopy() can be implemented as performance primitive in VM or
> JIT)
> Check this code as example: ExemptionMechanism:249, Statement:164
Agreed here. BTW, if array has a lenght of 5 what is the best copying way?
I do not know :) But in code with manual array copying of
arrays with dynamic number of iteration it's better to add a comment why
arraycopy method was not used.
--
Mikhail Fursov
Intel Middleware Products Division
Re: [website] harmony-dev agreements and recommendations
I think it will be very hard to implement and does not worth the efforts. Moreover these were recomendations only, and codebase can have a thousands of reasonable violations such tool will always report. On 5/25/06, Thorbjørn Ravn Andersen <[EMAIL PROTECTED]> wrote: Would it be possible to write these as CheckStyle rules? That would make them easy to spot and easy to check against. (or any other automated code style checker) -- Thorbjørn -- Mikhail Fursov Intel Middleware Products Division
Re: [classlib] Layout of tests in crypto module
I think this is because user classloader is not allowed to load classes from internal java packages (E.g. java.lang) But tests can be written not only for public interfaces but for package local too. On 5/24/06, Richard Liang <[EMAIL PROTECTED]> wrote: Could you please explain why we need bootclasspath api test? Thanks a lot. Best regards, Richard -- Mikhail Fursov Intel Middleware Products Division
Re: [classlib] JAPI data to drive packages to completion
I saw a report generated from JAPI output with percent of package implementation progress on gnu-classpath related site. We can use the same statistics in harmony... Like this: http://www.kaffe.org/~stuart/japi/htmlout/h-jdk14-classpath.html On 5/25/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: Nathan Beyer wrote: > That's what I've been using, so I would say it's a fairly good place to > start. The other technique I use in conjunction is generating the javadoc > from the Harmony source. This allows for some noticing some of the larger > holes when visually comparing it to the specification. > > The other piece that might be interesting is running one of those tools that > scans for TODO and FIXME comments and reports the what and where. I thought IDEA and Eclipse do this geir > > -Nathan > >> -Original Message- >> From: Geir Magnusson Jr [mailto:[EMAIL PROTECTED] >> Sent: Thursday, May 25, 2006 6:57 AM >> To: harmony-dev@incubator.apache.org >> Subject: [classlib] JAPI data to drive packages to completion >> >> I was staring at the JAPI data last night. Can anyone think of a reason >> why we wouldn't suggest to people looking for something to do to use >> JAPI reports to help finish packages? >> >> geir >> >> - >> Terms of use : http://incubator.apache.org/harmony/mailing.html >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] > > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Mikhail Fursov Intel Middleware Products Division
Re: [jira] Updated: (HARMONY-308) java.nio.charset.Charset.encode(CharBuffer) returns bytes in a different order in Harmony and RI for the UTF-16 charset
Dmitry M. Kononov wrote: Hi Richard, On 4/7/06, Richard Liang <[EMAIL PROTECTED]> wrote: You're right. :-) Now I agree with you that Harmony is not compliant with the specification. We will discuss with our Charset Provider - ICU to determine how to fix this issue. Thanks a lot. Is there any progress? Hello Dmitry, I reported bug for ICU[1], but unfortunately, I have not received any feedback :-( [1] http://bugs.icu-project.org/cgi-bin/icu-bugs?findid=5179&go=Go Thanks. -- 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] Layout of tests in crypto module
Mikhail Loenko wrote: Yes there is. They can access protected fields (they are also package-visible). Or they can test something related to class loading. Example. Recently I committed modules\luni\src\test\java.injected\java\net\HttpURLConnectionAccessor.java that is not a test though but something that is used by API test and that must be in bootclasspath. (I could refactor and put the test itself to the bootclasspath) Hello Mikhail, Instead of using HttpURLConnectionAccessor, we can access protected fields through a mock subclass of HttpURLConnection. Thanks, Mikhail 2006/5/25, Geir Magnusson Jr <[EMAIL PROTECTED]>: Mikhail Loenko wrote: > 2006/5/24, Geir Magnusson Jr <[EMAIL PROTECTED]>: >> >> >> George Harley wrote: >> > Hi Mikhail, >> > >> > That is a very good point and your suggestion of supplementing the >> class >> > or package name sounds like a very straightforward way around the >> > problem. Because there will be a number of tests that must be in an >> > identical package name to the type under test then it seems that the >> > differentiating mark needs to be added to the test class name. Not >> > really sure what this could be. Given that we are all settled on the >> > convention that a test type has the "Test" suffix, how about just add >> > "Impl" to that suffix for implementation tests giving us an "ImplTest" >> > suffix. >> > e.g. >> > >> > class under test : java.lang.SomeClassTest >> > implementation-independent test class : >> > o.a.h.module.tests.java.lang.SomeClassTest >> > Harmony-specific test class : >> > o.a.h.module.tests.java.lang.SomeClassImplTest >> >> Or >> >> o.a.h..apitest.java.lang.FooTest >> o.a.h..impltest.java.lang.FooTest >> >> >> Of course, the implementation test didn't need to be on the >> bootclasspath, it would simply be >> >> java.lang.FooTest >> >> with no other garbage in the package name > > Hi Geir > > how to distinguish between bootclasspath implementation test > java.lang.FooTest > and bootclasspath api test > java.lang.FooTest Is there such thing as an bootclasspath API test? geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Richard Liang China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Updated: (HARMONY-491) [classlib] Constructors of java.nio.charset.CharsetEncoder should not throw NPE if charset==null
Hi, Svetlana,
Welcome :)
Samoilenko, Svetlana V wrote:
Hi, Andrew,
I've prepared new patch with your fixes.
Thank you for your suggestion.
Regards,
Svetlana
-Original Message-
From: Andrew Zhang [mailto:[EMAIL PROTECTED]
Sent: Wednesday, May 24, 2006 8:34 AM
To: harmony-dev@incubator.apache.org
Subject: Re: [jira] Updated: (HARMONY-491) [classlib] Constructors of
java.nio.charset.CharsetEncoder should not throw NPE if charset==null
Hi, Svetlana
I took a quick view on your patch, I found your quick fix didn't resolve
the
problem thoroughly.
Try to comment following code in your test case, RI fails on the test
case
but Harmony with your patch passes.
public boolean isLegalReplacement(byte[] arg0) {
return true;
}
Here's my suggestion,
1. remove cs.newDecoder() in CharsetEnconder constructor.
2. add following code in isLegalReplacement method:
if(null == decoder){
decoder = cs.newDecoder();
}
The following code shows the change in patch format.
Would you please have a review?
Thanks!
Index: nio_char/src/main/java/java/nio/charset/CharsetEncoder.java
===
--- nio_char/src/main/java/java/nio/charset/CharsetEncoder.java
(revision
408852)
+++ nio_char/src/main/java/java/nio/charset/CharsetEncoder.java (working
copy)
@@ -133,7 +133,7 @@
// decoder instance for this encoder's charset, used for replacement
value
// checking
- private CharsetDecoder decoder;
+ private CharsetDecoder decoder = null;
/*
* --- Constructors
@@ -202,7 +202,6 @@
status = INIT;
malformAction = CodingErrorAction.REPORT;
unmapAction = CodingErrorAction.REPORT;
- decoder = cs.newDecoder();
replaceWith(replacement);
}
@@ -722,6 +721,9 @@
* replacement byte array.
*/
public boolean isLegalReplacement(byte[] repl) {
+ if(null == decoder){
+ decoder = cs.newDecoder();
+ }
CodingErrorAction malform = decoder.malformedInputAction();
CodingErrorAction unmap = decoder.unmappableCharacterAction();
decoder.onMalformedInput(CodingErrorAction.REPORT);
On 5/23/06, Svetlana Samoilenko (JIRA) <[EMAIL PROTECTED]> wrote:
[ http://issues.apache.org/jira/browse/HARMONY-491?page=all ]
Svetlana Samoilenko updated HARMONY-491:
Attachment: CharsetEncoder.txt
patch and unit test
[classlib] Constructors of java.nio.charset.CharsetEncoder should
not
throw NPE if charset==null
Key: HARMONY-491
URL: http://issues.apache.org/jira/browse/HARMONY-491
Project: Harmony
Type: Bug
Components: Classlib
Reporter: Svetlana Samoilenko
Priority: Minor
Attachments: CharsetEncoder.txt
The test listed below will pass on RI but fail on Harmony.
import java.nio.*;
import java.nio.charset.*;
public class test {
public static void main(String [] args) {
CharsetEncoder cen=new CharsetEncoderImpl(null, 1, 1);
if (cen.charset() == null) {
System.out.println("PASSED");
} else
System.out.println("FAILED");
}
}
class CharsetEncoderImpl extends CharsetEncoder {
public CharsetEncoderImpl(Charset arg0, float arg1, float arg2,
byte[] arg3) {
super(arg0, arg1, arg2, arg3);
}
public boolean isLegalReplacement(byte[] arg0) {
return true;
}
public CharsetEncoderImpl(Charset arg0, float arg1, float arg2)
{
super(arg0, arg1, arg2);
}
protected CoderResult encodeLoop(CharBuffer arg0, ByteBuffer
arg1) {
return null;
}
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the
administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] please review my regression test and patch for HttpURLConnection
Mikhail,
I'm afraid I cannot agree with you on this patch,
If I understand correctly, Harmony-482 is about the internal contract
between java.net.HttpURLConnection.setRequestMethod() and
o.a.h.l.internal.net.www.protocol.http.HttpURLConnection.getOutputStream(),
and the internal contract may be broken only if some of the codes
refactored (no chance for user application), say, modification for the
setRequestMethod() like this:
- this.method = methodTokens[i];
+this.method = method;
But this can be easily monitored by test codes below:
public void testGetOutputStream() throws Exception {
HttpURLConnection c = (HttpURLConnection) new
URL("http://127.0.0.1:";
+ port).openConnection();
c.setDoOutput(true);
c.setRequestMethod(new String("GET"));
c.getOutputStream();
...//other for POST/PUT
}
This test is enough to enforced the internal contract, it will shout if
some refactory breaks the internal contract. So IMHO, I think the patch
for HttpURLConnection is over-designed.
However, I even have no strong objection on it. What makes me more
confused is the introduction of injected
java.net.HttpURLConnectionAccessor, I suggest to avoid the injected
helper class as long as possible, because it introduces complexity to
understand/manage and is sometimes fragile because it may highly coupled
with implementation details, for this specific case, a mocked subclass
of o.a.hHttpURLConnection with overridden getRequestMethod can
catch the fragility of the internal contract.
Mikhail Loenko wrote:
I've created regression test and patch for
http://issues.apache.org/jira/browse/HARMONY-482
I had to make some changes in the luni's build.xml,
that are intended to be fixed once we all agree with
proposed test suite layout.
Please review the changes.
Thanks,
Mikhail
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
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] JAPI data to drive packages to completion
On 25 May 2006 at 9:01, "Nathan Beyer" <[EMAIL PROTECTED]> wrote: > > That's what I've been using, so I would say it's a fairly good place > to start. So I'd noticed! ;-) I've been keeping track of JAPI figures for just the bits of the API for which we have contributions. Currently (for the 1.5 api) the figures are: GoodBadMissing 93.98% 1.31% 4.7% Your efforts have been quite significant in improving these figures. (Watching these numbers is a bit more satisfying than watching the ones that include all the 0% rows. Although 20% is not at all bad and with swing and awt on the way...) At the current rate, it'll take 3 months to reach 100% for these packages. Pointing potential contributors at the JAPI pages would undoubtedly help us get there quicker - there is still a fair amount of "low hanging fruit". I can post these figures once a week if it gives people an incentive. For amusement, I also checked the JAPI figures for classpath (w/generics) for the same bits of the API. They are: GoodBadMissing 95.3% 0.00% 4.69% Regards, Mark. > > -Original Message- > > From: Geir Magnusson Jr [mailto:[EMAIL PROTECTED] > > Sent: Thursday, May 25, 2006 6:57 AM > > To: harmony-dev@incubator.apache.org > > Subject: [classlib] JAPI data to drive packages to completion > > > > I was staring at the JAPI data last night. Can anyone think of a reason > > why we wouldn't suggest to people looking for something to do to use > > JAPI reports to help finish packages? > > > > geir > > > > - > > Terms of use : http://incubator.apache.org/harmony/mailing.html > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] JAPI data to drive packages to completion
On 26 May 2006 at 2:05, "Mikhail Fursov" <[EMAIL PROTECTED]> wrote: > > I saw a report generated from JAPI output with percent of package > implementation progress on gnu-classpath related site. We can use the same > statistics in harmony... > > Like this: http://www.kaffe.org/~stuart/japi/htmlout/h-jdk14-classpath.html ;-) You mean these: http://www.kaffe.org/~stuart/japi/htmlout/h-jdk14-harmony.html http://www.kaffe.org/~stuart/japi/htmlout/h-jdk15-harmony.html 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: [tools] tools launching and javac
Mark Hindess wrote: On 25 May 2006 at 7:46, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: Tim Ellison wrote: Geir Magnusson Jr wrote: Tim Ellison wrote: This is still work in progress, but thought it would be good to give a quick update on where I am at the moment: Now you can run javac. Very cute! Do you intend module/tools to remain not part of the build? It will become part of the build once it is as-good-as done. I'm trying to do a balancing act between /not/ dumping my junk into SVN as I go along, and developing in the open | collaboratively. Suggestions for re-balancing are more than welcome. Only suggestion is to do a branches/tim/stuff1, work in there if you want people to comment (with the bonus of having it in SVN in case of problem). It's COW so the space usage won't be that bad, and you can just delete when done. While that's true, I think that development on branches has other costs: * merging back into trunk * fewer people will pay attention - nothing personal but I might be less inclined to scan commits in branches/tim than trunk ;-) Right, but right now he's not putting anything in trunk. So you have no hope of seeing anything. And it doesn't matter. If you aren't interested in what he's doing, don't look at it. if you are, you are engaged anyway. Personally, I think development is moving fast enough that it's not a problem having it in trunk. If it hadn't been in trunk, I might have been less inclined to test it ... and not had the incentive to fix the bugs (HARMONY-510) on my platform of choice. Are we talking about two different things? Tim was saying that he wanted to avoid dumping 'junk' into SVN, yet wants to work more in the open. Working in a branch is a great way to do it. Obviously, we should avoid breaking things like this for too long but I think the occasional breakage is a fair price to pay for not having the other costs. Of course, I seem to be the only one who even noticed this problem. Which problem? It's going to be the case that people will want to go off into a 'corner' and try something. it's nice that they can do it so others can watch, help, participate, and still it is out of the mainstream codebase until that person or people want to bring it in (or propose to bring it in). The merging would be their problem, just as it would be if they were just working at home or in the office on a private copy. The benefits seem obvious. geir Regards, Mark. - For now, the o.a.h.tools.javac.Main wrapper looks for the compiler in a hard-coded JAR filename (ecj_3.2RC5.jar). Just wondering whether to embed that JAR in the tools.jar, or look for the compiler in *.jar, or ...? Can we give it a 'known' pattern like "harmony_javac_ecj_3.2rc5.jar" or such so we can mechanically find it w/o a long search, yet also remember the version that we're using? The file ecj_3.2RC5.jar is the exact binary download from eclipse.org (renamed from their generic ecj.jar). Prefixing with harmony_ probably isn't appropriate, but I could pick-up the first ecj_*.jar that I find. I guess ecj_* works too... - 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: [website] harmony-dev agreements and recommendations
Erik Axel Nielsen wrote:
On 25. mai. 2006, at 17.42, Geir Magnusson Jr wrote:
Time for me to learn something - I thought there was only one monitor
per object how can different threads get different locks?
Hi, as I understand it, you use final on monitors to prevent the
following from happening:
Let's say you have a monitor:
private Object monitor;
Then you somewhere have:
public foo() {
monitor = new Object();
}
If by any chance foo() should be called twice you in effect have two
monitors around.
Got it. Thanks. I thought it was something more subtle.
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] JAPI data to drive packages to completion
Mikhail Fursov wrote: I saw a report generated from JAPI output with percent of package implementation progress on gnu-classpath related site. We can use the same statistics in harmony... Like this: http://www.kaffe.org/~stuart/japi/htmlout/h-jdk14-classpath.html LOL. Yes, that is what I was referring to. We get the report once a day from Stuart :) geir On 5/25/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: Nathan Beyer wrote: > That's what I've been using, so I would say it's a fairly good place to > start. The other technique I use in conjunction is generating the javadoc > from the Harmony source. This allows for some noticing some of the larger > holes when visually comparing it to the specification. > > The other piece that might be interesting is running one of those tools that > scans for TODO and FIXME comments and reports the what and where. I thought IDEA and Eclipse do this geir > > -Nathan > >> -Original Message- >> From: Geir Magnusson Jr [mailto:[EMAIL PROTECTED] >> Sent: Thursday, May 25, 2006 6:57 AM >> To: harmony-dev@incubator.apache.org >> Subject: [classlib] JAPI data to drive packages to completion >> >> I was staring at the JAPI data last night. Can anyone think of a reason >> why we wouldn't suggest to people looking for something to do to use >> JAPI reports to help finish packages? >> >> geir >> >> - >> Terms of use : http://incubator.apache.org/harmony/mailing.html >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] > > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Intention to work on Pack200 uncompressor/compressor
Hi everyone, I'd like to start work on an implementation of the pack200 decompression algorithm, from the specification which is available at http://www.jcp.org/aboutJava/communityprocess/first/jsr200/ The actual java class/interface is relatively simple, but the implementation behind the unpack() and pack() methods decidedly isn't :-) My goal will be to provide the unpacking algorithm first, and then work on a packer subsequently. I'll probably try to write it in an o.a.h module first, and then hook it into the java.util.jar classes/packages later. The only problem is that I'm building this on a Mac (primarily) and so I don't have the ability to download the IBM VM for bootstrapping the VM process (though a later task is to see if I can help with the migration of the VM to Mac OS X). Can I develop it against the Java 1.4 on my machine for the o.a.h module first, and then contribute it in stages? The other problem is that the API is pretty sparse; the packer either unpacks, or it doesn't :-) So from a contribution point of view, there may not be much to publically show, but I'd like (if possible) to have some of the implementation work made available as I go, in case anyone else wants to help out :-) I'd also like to try and design the implementation such that it could be downloaded and used by other OSGi implementations (e.g. Eclipse). If someone can give me some advice as to a suitable package name I can make an initial start on an implementation, and then in stages can post it to Jira. Thanks, Alex.
Re: [tools] tools launching and javac
On 25 May 2006 at 13:30, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: > > > Mark Hindess wrote: > > On 25 May 2006 at 7:46, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: > >> Tim Ellison wrote: > >>> Geir Magnusson Jr wrote: > Tim Ellison wrote: > > This is still work in progress, but thought it would be good to give a > > quick update on where I am at the moment: > >>> > > Now you can run javac. > Very cute! Do you intend module/tools to remain not part of the build? > >>> It will become part of the build once it is as-good-as done. > >>> > >>> I'm trying to do a balancing act between /not/ dumping my junk into SVN > >>> as I go along, and developing in the open | collaboratively. > >>> Suggestions for re-balancing are more than welcome. > >> Only suggestion is to do a branches/tim/stuff1, work in there if you > >> want people to comment (with the bonus of having it in SVN in case of > >> problem). > >> > >> It's COW so the space usage won't be that bad, and you can just delete > >> when done. > > > > While that's true, I think that development on branches has other costs: > > > > * merging back into trunk > > > > * fewer people will pay attention - nothing personal but I might be > >less inclined to scan commits in branches/tim than trunk ;-) > > Right, but right now he's not putting anything in trunk. So you have no > hope of seeing anything. > > And it doesn't matter. If you aren't interested in what he's doing, > don't look at it. if you are, you are engaged anyway. > > > Personally, I think development is moving fast enough that it's not a > > problem having it in trunk. If it hadn't been in trunk, I might have > > been less inclined to test it ... and not had the incentive to fix the > > bugs (HARMONY-510) on my platform of choice. > > Are we talking about two different things? Tim was saying that he > wanted to avoid dumping 'junk' into SVN, yet wants to work more in the open. > > Working in a branch is a great way to do it. > > > > > Obviously, we should avoid breaking things like this for too long but I > > think the occasional breakage is a fair price to pay for not having the > > other costs. > > > > Of course, I seem to be the only one who even noticed this problem. > > Which problem? HARMONY-510 is causing every java invocation to exit with a glibc memory corruption crash. Which causes all the IBM vme/harmony hosted bits of our builds to break - they "work" but ant sees the bad return code. > It's going to be the case that people will want to go off into a > 'corner' and try something. it's nice that they can do it so others can > watch, help, participate, and still it is out of the mainstream > codebase until that person or people want to bring it in (or propose to > bring it in). > > The merging would be their problem, just as it would be if they were > just working at home or in the office on a private copy. > > The benefits seem obvious. Sure, yes. I missed the point. You are absolutely right. I thought Tim was concerned because he'd already dumped "junk" into svn. ;-) I was pointing out that I didn't think it was a big deal - and anyway it's really cool "junk" that I like to see. -Mark. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
classlib build problem?
I am experimenting with eclipse compiler from org/apache/harmony/tools/javac/Main. The point is that I don't have java5 at home computer, but I figured out that eclipse compiler in ecj_3.2RC5.jar can be good substitution. I have tweaked the tools javac wrapper and managed to start ant with that compiler. There are number of errors in eclipse compiler complaining about wrong usage of @Override and @Deprecated keywords. I simply removed all of them to get through. The problem which stopped me is: [javac] 1009. ERROR in /home/ivan/experiments/harmony/trunk/modules/rmi/src/main/java/java/rmi/server/RMIClassLoader.java [javac] (at line 22) [javac] import java.util.Scanner; [javac]^ [javac] The import java.util.Scanner cannot be resolved Does there problem result from my experiments or the classlib build is broken now? -- Ivan - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Intention to work on Pack200 uncompressor/compressor
Would you mind if I ask why? geir Alex Blewitt wrote: Hi everyone, I'd like to start work on an implementation of the pack200 decompression algorithm, from the specification which is available at http://www.jcp.org/aboutJava/communityprocess/first/jsr200/ The actual java class/interface is relatively simple, but the implementation behind the unpack() and pack() methods decidedly isn't :-) My goal will be to provide the unpacking algorithm first, and then work on a packer subsequently. I'll probably try to write it in an o.a.h module first, and then hook it into the java.util.jar classes/packages later. The only problem is that I'm building this on a Mac (primarily) and so I don't have the ability to download the IBM VM for bootstrapping the VM process (though a later task is to see if I can help with the migration of the VM to Mac OS X). Can I develop it against the Java 1.4 on my machine for the o.a.h module first, and then contribute it in stages? The other problem is that the API is pretty sparse; the packer either unpacks, or it doesn't :-) So from a contribution point of view, there may not be much to publically show, but I'd like (if possible) to have some of the implementation work made available as I go, in case anyone else wants to help out :-) I'd also like to try and design the implementation such that it could be downloaded and used by other OSGi implementations (e.g. Eclipse). If someone can give me some advice as to a suitable package name I can make an initial start on an implementation, and then in stages can post it to Jira. Thanks, 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: [tools] tools launching and javac
Mark Hindess wrote: \> I thought Tim was concerned because he'd already dumped "junk" into svn. ;-) I was pointing out that I didn't think it was a big deal - and anyway it's really cool "junk" that I like to see. Yes - doing 'junk' in plain sight is good for all, especially if you can inspire someone to take over and finish for you :) We could also use a sandbox in /classpath or just /enhanced/trunk for these kinds of experiements by committers. 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: Intention to work on Pack200 uncompressor/compressor
Please don't answer. Someone politely pointed out privately that I'm a moron. I understand now. Geir -- Geir Magnusson Jr SSG/MPD [EMAIL PROTECTED] +1 203 665 6437 > -Original Message- > From: Geir Magnusson Jr [mailto:[EMAIL PROTECTED] > Sent: Thursday, May 25, 2006 5:23 PM > To: harmony-dev@incubator.apache.org > Subject: Re: Intention to work on Pack200 uncompressor/compressor > > Would you mind if I ask why? > > geir > > > Alex Blewitt wrote: > > Hi everyone, > > > > I'd like to start work on an implementation of the pack200 > > decompression algorithm, from the specification which is > available at > > http://www.jcp.org/aboutJava/communityprocess/first/jsr200/ > > > > The actual java class/interface is relatively simple, but the > > implementation behind the unpack() and pack() methods > decidedly isn't > > :-) My goal will be to provide the unpacking algorithm > first, and then > > work on a packer subsequently. I'll probably try to write it in an > > o.a.h module first, and then hook it into the java.util.jar > > classes/packages later. > > > > The only problem is that I'm building this on a Mac > (primarily) and so > > I don't have the ability to download the IBM VM for > bootstrapping the > > VM process (though a later task is to see if I can help with the > > migration of the VM to Mac OS X). Can I develop it against the Java > > 1.4 on my machine for the o.a.h module first, and then contribute it > > in stages? > > > > The other problem is that the API is pretty sparse; the > packer either > > unpacks, or it doesn't :-) So from a contribution point of > view, there > > may not be much to publically show, but I'd like (if > possible) to have > > some of the implementation work made available as I go, in > case anyone > > else wants to help out :-) > > > > I'd also like to try and design the implementation such > that it could > > be downloaded and used by other OSGi implementations (e.g. Eclipse). > > > > If someone can give me some advice as to a suitable package > name I can > > make an initial start on an implementation, and then in stages can > > post it to Jira. > > > > Thanks, > > > > Alex. > > > > > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] jetty based tests
> Geir Magnusson Jr wrote:
This thread was a long read :)
First, I'm all for using Jetty as our test server (I think we talked
about this a long time ago...). We could even use Tomcat, but my
experience in the past was that Jetty was very easy to emebed. By
default, there should be no external dependency to build, test and run
Harmony (i.e. I can do it on a plane - that means that no external
server is required.)
+1. There are so many net-related tests laying in the exclude-list,
Jetty really helps.
Second, I think that we don't lose much in terms of flexibility, and
gain an awful lot in functionality. Writing tests is very easy, and we
probably can control anything we want to for custom stuff.
Third, we get location transparency. Our isolated-system-default
notwithstanding, we certainly want to test over a network (localhost
doesn't cut it), so we should easily be able to run the ant target that
runs the server on a remote machine so we can test things like real
network failure and interruption (IOW, reach around and pull the network
cable out...), setting a property or -ish for the address of the test
target server (default is localhost)
Given that the argument is long and winding, can people do a checkpoint
summary about how they are feeling?
geir
Stepan Mishura wrote:
On 5/23/06, Andrew Zhang <[EMAIL PROTECTED]> wrote:
Hi, Stepan,
"No we shouldn't write a mock http server for each case (I mean that we
need
not implement http protocol each time)."
Shall we implement http sometimes? If no, how can we verfiy
HttpURLConnection function, for example, whether the request is in http
format,
or chuncked http request.
Yes we have implement http protocol in HttpURLConnection class. The
question
is how to verify its implementation. This can be done in two ways:
with or
without existing http server. Both ways are possible. Approach with using
existing http server for testing looks more confident but misuse of this
approach may result in hard-to-configure and slow-to-run test suite.
So my
position was that we can use both ways but separately. Tests that don't
depend on http server are included in 'normal test suite' and run
regularly.
And dependant tests are run separately.
But if jetty is so good as George and Paulex described then I'll think
about
revising my position.
If there's a mock httpserver utility, which could assert whether
receieved
http request is correct, and could generate customized http output,
it can
be called "little jetty". If the utility httpserver could customize
output
more flexibility, could make some unspecial output which jetty couldn't,
it
could be called "enhanced jetty". Finally, the utility class will
have to
implement http protocol and become an HttpSrever or
EnhanceedHttpServer(since it could do some extra work, e.g, produce
broken
http response, etc.).
"So we have to develop mock server anyway. And the mock server can be
used
for other ('positive') tests. Right? Then why we have to use jetty?"
If there's a mock server utility can be easily used for normal and
abnormal
http test, I've no objection to use it.
At least, we have one in common: reduce external dependency. Right?
Yes
Thanks,
Stepan.
Thanks.
On 5/23/06, Stepan Mishura <[EMAIL PROTECTED]> wrote:
>
> On 5/23/06, Andrew Zhang wrote:
> >
> > Hi, Stepan,
> >
> > "With mock objects this can be done with no problems and HARMONY-164
> > demonstrates the possible way."
> >
> > Shall we write a mock http server for each case? It takes lots of
> > reduplicate efforts and results in many mock http server classes in
the
> > end.
>
>
> No we shouldn't write a mock http server for each case (I mean that we
> need
> not implement http protocol each time). In "HARMONY-164 version" mock
> server
> is an instance of class that extends Thread class. The mock server is
> started before running test and by default is just listens for
incoming
> connection. A test has access to server's instance and may
configure it
> response (I didn't implemented but it is also possible to save request
to
> be
> verified). There is no http protocol implementation.
>
> In fact, for many regular tests, jetty works fine.
> >
> > And I also agree that for negative tests and some other special
tests
> > which
> > jetty could not satisfy , we should use mock http server instead.
>
>
> So we have to develop mock server anyway. And the mock server can be
used
> for other ('positive') tests. Right? Then why we have to use jetty?
>
> Thanks,
> Stepan.
>
> What's your opnion?
> >
> > Thanks.
> >
> >
> > On 5/23/06, Stepan Mishura <[EMAIL PROTECTED]> wrote:
> > >
> > > Hi George, Tim
> > >
> > > I'd like to clarify the following questions:
> > > 1) Configuring
> > > As I understood we say that the server is 'embedded' when we can
> > > start/stop
> > > it within Ant without additional configuration steps. And all we
need
> to
> > > do
> > > is just download required jars. Right?
> > >
RE: Intention to work on Pack200 uncompressor/compressor
That said, if not required by the spec, we'll need the tck I'll get started on that. Geir -Original Message- From: Magnusson, Geir [mailto:[EMAIL PROTECTED] Sent: Thu May 25 17:45:05 2006 To: harmony-dev@incubator.apache.org; [EMAIL PROTECTED] Subject:RE: Intention to work on Pack200 uncompressor/compressor Please don't answer. Someone politely pointed out privately that I'm a moron. I understand now. Geir -- Geir Magnusson Jr SSG/MPD [EMAIL PROTECTED] +1 203 665 6437 > -Original Message- > From: Geir Magnusson Jr [mailto:[EMAIL PROTECTED] > Sent: Thursday, May 25, 2006 5:23 PM > To: harmony-dev@incubator.apache.org > Subject: Re: Intention to work on Pack200 uncompressor/compressor > > Would you mind if I ask why? > > geir > > > Alex Blewitt wrote: > > Hi everyone, > > > > I'd like to start work on an implementation of the pack200 > > decompression algorithm, from the specification which is > available at > > http://www.jcp.org/aboutJava/communityprocess/first/jsr200/ > > > > The actual java class/interface is relatively simple, but the > > implementation behind the unpack() and pack() methods > decidedly isn't > > :-) My goal will be to provide the unpacking algorithm > first, and then > > work on a packer subsequently. I'll probably try to write it in an > > o.a.h module first, and then hook it into the java.util.jar > > classes/packages later. > > > > The only problem is that I'm building this on a Mac > (primarily) and so > > I don't have the ability to download the IBM VM for > bootstrapping the > > VM process (though a later task is to see if I can help with the > > migration of the VM to Mac OS X). Can I develop it against the Java > > 1.4 on my machine for the o.a.h module first, and then contribute it > > in stages? > > > > The other problem is that the API is pretty sparse; the > packer either > > unpacks, or it doesn't :-) So from a contribution point of > view, there > > may not be much to publically show, but I'd like (if > possible) to have > > some of the implementation work made available as I go, in > case anyone > > else wants to help out :-) > > > > I'd also like to try and design the implementation such > that it could > > be downloaded and used by other OSGi implementations (e.g. Eclipse). > > > > If someone can give me some advice as to a suitable package > name I can > > make an initial start on an implementation, and then in stages can > > post it to Jira. > > > > Thanks, > > > > Alex. > > > > > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: bootJVM linux build...
Tim, Thanks for you offer of assistance to Sanket. I've given him some suggestions on how do diagnose the issue inside of this macro and we'll see what he comes up with. I think that the Harmony crowd will be an inspiration and support to him in this Summer of Code as he is getting his career started. Best regards, Dan Lydick > [Original Message] > From: Tim Ellison <[EMAIL PROTECTED]> > To: > Date: 5/25/06 5:24:17 AM > Subject: Re: bootJVM linux build... > > Hi Sanket, welcome. > > Good to hear you are trying to build the boot VM. The expert on that > code is Dan Lydick -- hopefully he will see your note and be able to help. > > If you don't hear from him soon I'll try my best > > Regards, > Tim > > Sanket Sharma wrote: > > Hey everyone.. > > > > I was trying to build the jvm on Linux. I´m using SUSE Linux and GCC 4. > > I am facing a little problem with macro expansion and some help would be greatly appreciated. > > > > While trying to build the jvm, I get the following error: > > > > class.c: In function âclass_load_resolve_clinitâ: > > class.c:1631: error: invalid lvalue in assignment > > > > > > which is a Macro > > > > PUSH_FRAME(thridx, pca->max_locals); > > > > When I do a gcc - E and save output to file, I can see the macro being expanded to: > > > > (pjvm->thread[thridx].sp) += ((pca->max_locals)); > > (pjvm->thread[thridx].sp) += (1); > > pjvm->thread[thridx].stack[pjvm->thread[thridx].sp - 0] = (jint) (((pca->max_locals))); > > (pjvm->thread[thridx].sp) += (1); > > (rvoid *) *(&(pjvm->thread[thridx].stack[((pjvm->thread[thridx].sp) - (1 +1))])) = GC_STACK_NEW(thridx, (pca->max_locals)); > > (pjvm->thread[thridx].sp) += (1); > > pjvm->thread[thridx].stack[pjvm->thread[thridx].sp - 0] = (jint) ((pjvm->thread[thridx].fp)); > > pjvm->thread[thridx].fp = (((pjvm->thread[thridx].sp) - ((1 + 1 + 1; > > (pjvm->thread[thridx].sp) += (1); > > pjvm->thread[thridx].stack[pjvm->thread[thridx].sp - 0] = (jint) ((pjvm->thread[thridx].pc.offset)); > > (pjvm->thread[thridx].sp) += (1); > > pjvm->thread[thridx].stack[pjvm->thread[thridx].sp - 0] = (jint) ((pjvm->thread[thridx].pc.excpatridx)); > > (pjvm->thread[thridx].sp) += (1); > > pjvm->thread[thridx].stack[pjvm->thread[thridx].sp - 0] = (jint) ((pjvm->thread[thridx].pc.codeatridx)); > > (pjvm->thread[thridx].sp) += (1); > > pjvm->thread[thridx].stack[pjvm->thread[thridx].sp - 0] = (jint) ((pjvm->thread[thridx].pc.mthidx)); > > (pjvm->thread[thridx].sp) += (1); > > pjvm->thread[thridx].stack[pjvm->thread[thridx].sp - 0] = (jint) ((pjvm->thread[thridx].pc.clsidx));;; > > > > I tried putting brackets in various macros but nothing helped. > > > > Any help would be greatly appreciated. > > > > Best Regards, > > Sanket Sharma > > > > > > This email may contain confidential or privileged information for the > > intended recipient(s) and the views expressed in the same are not > > necessarily the views of Zensar Technologies Ltd. If you are not the intended > > recipient or have received this e-mail by error, its use is strictly > > prohibited, please delete the e-mail and notify the sender. Zensar > > Technologies Ltd. does not accept any liability for virus infected mails. > > > > > > - > > 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] > - 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] JAPI data to drive packages to completion
> -Original Message- > From: Geir Magnusson Jr [mailto:[EMAIL PROTECTED] > Sent: Thursday, May 25, 2006 9:49 AM > To: harmony-dev@incubator.apache.org > Subject: Re: [classlib] JAPI data to drive packages to completion > > The other piece that might be interesting is running one of those tools > that > > scans for TODO and FIXME comments and reports the what and where. > > I thought IDEA and Eclipse do this > > geir They do, but an automated report might show some interesting items in code that people don't normally check out or import into their IDE. Personally, I check out all of the code and run the builds, but I generally only import one module at a time. -Nathan > > > > -Nathan > > > >> -Original Message- > >> From: Geir Magnusson Jr [mailto:[EMAIL PROTECTED] > >> Sent: Thursday, May 25, 2006 6:57 AM > >> To: harmony-dev@incubator.apache.org > >> Subject: [classlib] JAPI data to drive packages to completion > >> > >> I was staring at the JAPI data last night. Can anyone think of a > reason > >> why we wouldn't suggest to people looking for something to do to use > >> JAPI reports to help finish packages? > >> > >> geir > >> > >> - > >> Terms of use : http://incubator.apache.org/harmony/mailing.html > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > - > > Terms of use : http://incubator.apache.org/harmony/mailing.html > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] jetty based tests
On 5/25/06, Magnusson, Geir <[EMAIL PROTECTED]> wrote: > -Original Message- > From: Andrew Zhang [mailto:[EMAIL PROTECTED] > Sent: Thursday, May 25, 2006 6:11 AM > To: harmony-dev@incubator.apache.org; [EMAIL PROTECTED] > Subject: Re: [classlib] jetty based tests > > On 5/25/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: > > > > > > > > Yang Paulex wrote: > > > +1 from me > > > > > > I also suggest we use Jetty as a singleton, so that we > don't need to > > pay > > > the overhead to find an available port and to start http server. > > > > Doesn't the above "don't need to pay the overhead to find > an available > > port" conflict with the element #1 below, "lazily start Jetty when > > necessary on an available port" > > > I don't think "singleton" conflicts with "lazily start". > Jetty server starts only once and starts up when there's some > case needs it. > :) Right - my confusion was about not wanting to find an available port due to some overhead that you discern. > > Sorry - I'm just confused. > > > > (I think that the port should be pre defined (well-known) > have a default > > value, and be overridable in a properties/-ish file. > > > What's the problem if the port is selected automatically? Repeatability. IMO, there should be no random elements in our testing. That leads to frustration, fear, despair, pathos, pain, agony, angst and much pulling of limited resources, like hair, in my case. > If I understand correctly, it means Jetty selects a free port > from system, > and provides an API method (e.g. getJettyPort()) to get the > selected port. > In this way, listen port confliction issue could be > completely avoided. Only once in my life have I seen a server randomly choose a port to listen on, and I quickly took that engineer off networking projects for a while :) Cases are different. If it's a real network server, who'll know your randomly listen port? But here is test case, just like temp files. We start the server only for tests, and stop it when finished. Shall we have to create a temp file named "tempfile01.tmp"? or just create a not conflict file and delete it after used ? Of course, configuring a listen port in property is certainly OK for me. But IMO more and more configuration may lead to fear. Geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Andrew Zhang China Software Development Lab, IBM
Re: Intention to work on Pack200 uncompressor/compressor
Alex Blewitt wrote: Hi everyone, I'd like to start work on an implementation of the pack200 decompression algorithm, from the specification which is available at http://www.jcp.org/aboutJava/communityprocess/first/jsr200/ I shall give you a warm welcome for implementation of Pach200! :) But as I know few about the legality, I wonder it is legal for us(Harmony developers) to read such algorithm directly from jcp.org? Can anyone give an answer? Let's go ahead if there's no obstacle. The actual java class/interface is relatively simple, but the implementation behind the unpack() and pack() methods decidedly isn't :-) My goal will be to provide the unpacking algorithm first, and then work on a packer subsequently. I'll probably try to write it in an o.a.h module first, and then hook it into the java.util.jar classes/packages later. Yes, we have a Pack200.java in java.util.jar, and can write its implementation in a internal pachage. According to Tim's guidance: http://incubator.apache.org/harmony/subcomponents/classlibrary/pkgnaming.html a naming of "org.apache.harmony.util.jar .internal " maybe appropriate. And there's a package private factory class PackFactory, for hooking the implementation class. You may read them for more information for how to initialation. The only problem is that I'm building this on a Mac (primarily) and so I don't have the ability to download the IBM VM for bootstrapping the VM process (though a later task is to see if I can help with the migration of the VM to Mac OS X). Can I develop it against the Java 1.4 on my machine for the o.a.h module first, and then contribute it in stages? I know little about Mac, though I love its appearance :) I wonder if you would write the implementation by pure java or native code. IMHO, write them in native may be a help in performance, and maybe easy to merge (And we see, RI create a excuteable pack200.exe in its jre). The code can be put in native-src\(win.IA32/share/Linux.IA32/Mac?) \archive, naming pack200.c or so. BTW, I don't know if Harmony can be run on Mac currently. However, that is an aim :) The other problem is that the API is pretty sparse; the packer either unpacks, or it doesn't :-) So from a contribution point of view, there may not be much to publically show, but I'd like (if possible) to have some of the implementation work made available as I go, in case anyone else wants to help out :-) You may document the interpret of the algorithm, and offer some testcases :) I'd also like to try and design the implementation such that it could be downloaded and used by other OSGi implementations (e.g. Eclipse). If someone can give me some advice as to a suitable package name I can make an initial start on an implementation, and then in stages can post it to Jira. As far as I understand the algorithm, it was a little complex and may take a period of time to implement. So good luck, and let's discuss on mailing-list if there's something hard. :) Thanks, Alex. -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] Layout of tests in crypto module
Hi Richard Do you mean a mock subclass of j.n.HttpURLConnection or a mock subclass of o.a.h.luni.internalHttpURLConnection ? If it is a subclass for o.a.h... then it won't pass on RI - it would be an impl test, if it is a subclass for j.n.HUC then it won't catch a problem in o.a.hHIC Thanks, Mikhail 2006/5/25, Richard Liang <[EMAIL PROTECTED]>: Mikhail Loenko wrote: > Yes there is. > > They can access protected fields (they are also package-visible). Or they > can test something related to class loading. > > Example. Recently I committed > modules\luni\src\test\java.injected\java\net\HttpURLConnectionAccessor.java > > that is not a test though but something that is used by API test and > that must > be in bootclasspath. (I could refactor and put the test itself to the > bootclasspath) > Hello Mikhail, Instead of using HttpURLConnectionAccessor, we can access protected fields through a mock subclass of HttpURLConnection. > Thanks, > Mikhail > > 2006/5/25, Geir Magnusson Jr <[EMAIL PROTECTED]>: >> >> >> Mikhail Loenko wrote: >> > 2006/5/24, Geir Magnusson Jr <[EMAIL PROTECTED]>: >> >> >> >> >> >> George Harley wrote: >> >> > Hi Mikhail, >> >> > >> >> > That is a very good point and your suggestion of supplementing the >> >> class >> >> > or package name sounds like a very straightforward way around the >> >> > problem. Because there will be a number of tests that must be in an >> >> > identical package name to the type under test then it seems that >> the >> >> > differentiating mark needs to be added to the test class name. Not >> >> > really sure what this could be. Given that we are all settled on >> the >> >> > convention that a test type has the "Test" suffix, how about >> just add >> >> > "Impl" to that suffix for implementation tests giving us an >> "ImplTest" >> >> > suffix. >> >> > e.g. >> >> > >> >> > class under test : java.lang.SomeClassTest >> >> > implementation-independent test class : >> >> > o.a.h.module.tests.java.lang.SomeClassTest >> >> > Harmony-specific test class : >> >> > o.a.h.module.tests.java.lang.SomeClassImplTest >> >> >> >> Or >> >> >> >> o.a.h..apitest.java.lang.FooTest >> >> o.a.h..impltest.java.lang.FooTest >> >> >> >> >> >> Of course, the implementation test didn't need to be on the >> >> bootclasspath, it would simply be >> >> >> >> java.lang.FooTest >> >> >> >> with no other garbage in the package name >> > >> > Hi Geir >> > >> > how to distinguish between bootclasspath implementation test >> > java.lang.FooTest >> > and bootclasspath api test >> > java.lang.FooTest >> >> Is there such thing as an bootclasspath API test? >> >> geir >> >> - >> Terms of use : http://incubator.apache.org/harmony/mailing.html >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > - > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Richard Liang China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] jetty based tests
Geir Magnusson Jr wrote: Magnusson, Geir wrote: -Original Message- From: Andrew Zhang [mailto:[EMAIL PROTECTED] Sent: Thursday, May 25, 2006 6:11 AM To: harmony-dev@incubator.apache.org; [EMAIL PROTECTED] Subject: Re: [classlib] jetty based tests If I understand correctly, it means Jetty selects a free port from system, and provides an API method (e.g. getJettyPort()) to get the selected port. In this way, listen port confliction issue could be completely avoided. Only once in my life have I seen a server randomly choose a port to listen on, and I quickly took that engineer off networking projects for a while :) I didn't mean this the way it sounds to me now :) Sorry. I can also see some uses for this. My example from my personal history was for high-performance production code, so you can see why I had a rather reflexive reaction... That's OK, I'm in the java.util project now:). Of course, the utility methods can be designed deliberately to avoid depending on singleton and automatic port selection, how test case knows if the getServerPort() return a random port or fixed one? Still, I think there are a few problems with the above, such as having to have Jetty in the same process space, tying the test code to Jetty, and of course, the repeatability. IMO there is many advantages to have Jetty in the same process, for example, it makes the random port feasible only by providing a API like getServerPort(), and again, if we need a remote one or some thing in separated process, just switch to another Jetty startup configuration(strategy pattern?) with same API. And we don't need to tying test to Jetty, the utility can encapsulate the http server provider, and the interface can has another implementation adapting to something else with similar capability, say, Jigsaw maybe, or even Mustang's embedded com.sun.*** http server(of course I don't really mean that;)). Anyway, because the Jetty has the potential as http/https/ftp/proxy/socket test server, the provided utility should be very flexible to adapt as many cases as possible. I do see the utility of this though for convenience in some cases, and if we decide to do a runtime port selection, I'd have a helper do it and pass the selected port to both Jetty as well as the test code, so that the two things are decoupled. geir - 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] Layout of tests in crypto module
Hi Geir 2006/5/25, Geir Magnusson Jr <[EMAIL PROTECTED]>: should we rethink this? Not just for this reason, but also for ease of data management as this thing grows... it is a good question. I've played around this. We can put .xml test results to different dirs and then create a single report, which will contain tests of the same name but of different nature. Does it look good? Thanks, Mikhail Mikhail Loenko wrote: > 2006/5/25, Geir Magnusson Jr <[EMAIL PROTECTED]>: >> We could always just partition in the filesystem and separate the test >> runs for bootclasspath API, and bootclasspath implementation? > > The problem is that we have a single directory where we put results. So > if we > run all the tests including both impl and api at once then result of the > second > test being run will overwrite result of the first one > > Mikhail > > - > 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: bootJVM linux build...
Where did you give him the suggestions? Here? bootjvm wrote: Tim, Thanks for you offer of assistance to Sanket. I've given him some suggestions on how do diagnose the issue inside of this macro and we'll see what he comes up with. I think that the Harmony crowd will be an inspiration and support to him in this Summer of Code as he is getting his career started. Best regards, Dan Lydick [Original Message] From: Tim Ellison <[EMAIL PROTECTED]> To: Date: 5/25/06 5:24:17 AM Subject: Re: bootJVM linux build... Hi Sanket, welcome. Good to hear you are trying to build the boot VM. The expert on that code is Dan Lydick -- hopefully he will see your note and be able to help. If you don't hear from him soon I'll try my best Regards, Tim Sanket Sharma wrote: Hey everyone.. I was trying to build the jvm on Linux. I´m using SUSE Linux and GCC 4. I am facing a little problem with macro expansion and some help would be greatly appreciated. While trying to build the jvm, I get the following error: class.c: In function ‘class_load_resolve_clinit’: class.c:1631: error: invalid lvalue in assignment which is a Macro PUSH_FRAME(thridx, pca->max_locals); When I do a gcc - E and save output to file, I can see the macro being expanded to: (pjvm->thread[thridx].sp) += ((pca->max_locals)); (pjvm->thread[thridx].sp) += (1); pjvm->thread[thridx].stack[pjvm->thread[thridx].sp - 0] = (jint) (((pca->max_locals))); (pjvm->thread[thridx].sp) += (1); (rvoid *) *(&(pjvm->thread[thridx].stack[((pjvm->thread[thridx].sp) - (1 +1))])) = GC_STACK_NEW(thridx, (pca->max_locals)); (pjvm->thread[thridx].sp) += (1); pjvm->thread[thridx].stack[pjvm->thread[thridx].sp - 0] = (jint) ((pjvm->thread[thridx].fp)); pjvm->thread[thridx].fp = (((pjvm->thread[thridx].sp) - ((1 + 1 + 1; (pjvm->thread[thridx].sp) += (1); pjvm->thread[thridx].stack[pjvm->thread[thridx].sp - 0] = (jint) ((pjvm->thread[thridx].pc.offset)); (pjvm->thread[thridx].sp) += (1); pjvm->thread[thridx].stack[pjvm->thread[thridx].sp - 0] = (jint) ((pjvm->thread[thridx].pc.excpatridx)); (pjvm->thread[thridx].sp) += (1); pjvm->thread[thridx].stack[pjvm->thread[thridx].sp - 0] = (jint) ((pjvm->thread[thridx].pc.codeatridx)); (pjvm->thread[thridx].sp) += (1); pjvm->thread[thridx].stack[pjvm->thread[thridx].sp - 0] = (jint) ((pjvm->thread[thridx].pc.mthidx)); (pjvm->thread[thridx].sp) += (1); pjvm->thread[thridx].stack[pjvm->thread[thridx].sp - 0] = (jint) ((pjvm->thread[thridx].pc.clsidx));;; I tried putting brackets in various macros but nothing helped. Any help would be greatly appreciated. Best Regards, Sanket Sharma This email may contain confidential or privileged information for the intended recipient(s) and the views expressed in the same are not necessarily the views of Zensar Technologies Ltd. If you are not the intended recipient or have received this e-mail by error, its use is strictly prohibited, please delete the e-mail and notify the sender. Zensar Technologies Ltd. does not accept any liability for virus infected mails. - 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] - 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: Intention to work on Pack200 uncompressor/compressor
Jimmy, Jing Lv wrote: Alex Blewitt wrote: Hi everyone, I'd like to start work on an implementation of the pack200 decompression algorithm, from the specification which is available at http://www.jcp.org/aboutJava/communityprocess/first/jsr200/ I shall give you a warm welcome for implementation of Pach200! :) But as I know few about the legality, I wonder it is legal for us(Harmony developers) to read such algorithm directly from jcp.org? Can anyone give an answer? Let's go ahead if there's no obstacle. What? If we implement a spec from the JCP, we get the TCK and pass it. That's it. [SNIP] I know little about Mac, though I love its appearance :) I wonder if you would write the implementation by pure java or native code. IMHO, write them in native may be a help in performance, and maybe easy to merge (And we see, RI create a excuteable pack200.exe in its jre). The code can be put in native-src\(win.IA32/share/Linux.IA32/Mac?) \archive, naming pack200.c or so. BTW, I don't know if Harmony can be run on Mac currently. However, that is an aim :) Why not just write it in Java? 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] jetty based tests
Paulex Yang wrote: Geir Magnusson Jr wrote: Magnusson, Geir wrote: -Original Message- From: Andrew Zhang [mailto:[EMAIL PROTECTED] Sent: Thursday, May 25, 2006 6:11 AM To: harmony-dev@incubator.apache.org; [EMAIL PROTECTED] Subject: Re: [classlib] jetty based tests If I understand correctly, it means Jetty selects a free port from system, and provides an API method (e.g. getJettyPort()) to get the selected port. In this way, listen port confliction issue could be completely avoided. Only once in my life have I seen a server randomly choose a port to listen on, and I quickly took that engineer off networking projects for a while :) I didn't mean this the way it sounds to me now :) Sorry. I can also see some uses for this. My example from my personal history was for high-performance production code, so you can see why I had a rather reflexive reaction... That's OK, I'm in the java.util project now:). Of course, the utility methods can be designed deliberately to avoid depending on singleton and automatic port selection, how test case knows if the getServerPort() return a random port or fixed one? First, why would it care? Second, I'm -1 for making test cases know about Jetty.getServerPort()... Just inject the port into the CTOR or a property on setup. Still, I think there are a few problems with the above, such as having to have Jetty in the same process space, tying the test code to Jetty, and of course, the repeatability. IMO there is many advantages to have Jetty in the same process, for example, it makes the random port feasible only by providing a API like getServerPort(), and again, if we need a remote one or some thing in separated process, just switch to another Jetty startup configuration(strategy pattern?) with same API. And we don't need to tying test to Jetty, the utility can encapsulate the http server provider, and the interface can has another implementation adapting to something else with similar capability, say, Jigsaw maybe, or even Mustang's embedded com.sun.*** http server(of course I don't really mean that;)). Anyway, because the Jetty has the potential as http/https/ftp/proxy/socket test server, the provided utility should be very flexible to adapt as many cases as possible. So why not just inject the port number into the testcase? geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
