Re: [drlvm] build fails on Windows os

[Marina Goldburt]

On 6/27/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote:


Odd.  It was broken for me too.  What changed?

I applied the patch - thanks.

geir



I think, the problem is in the log4cxx revision -
the old log4cxx didn't use the aprutil xml API.

Marina


Marina Goldburt wrote:

> Hi,
>
> I've caught the following error when tried to build the drlvm today on
> Windows OS:
>
>
>
>   [cc] 0 total files to be compiled.
>
>   [cc] Starting link
>
>   [cc]Creating library vmcore.lib and object vmcore.exp
>
>   [cc] aprutil-1.lib(apr_xml.obj) : error LNK2019: unresolved
external
> symb
>
> ol _XML_SetCharacterDataHandler referenced in function
> [EMAIL PROTECTED]
>
>   [cc] aprutil-1.lib(apr_xml.obj) : error LNK2019: unresolved
external
> symb
>
> ol _XML_SetElementHandler referenced in function
[EMAIL PROTECTED]
>
>   [cc] aprutil-1.lib(apr_xml.obj) : error LNK2019: unresolved
external
> symb
>
> ol _XML_SetUserData referenced in function [EMAIL PROTECTED]
>
>   [cc] aprutil-1.lib(apr_xml.obj) : error LNK2019: unresolved
external
> symb
>
> ol _XML_ParserCreate referenced in function [EMAIL PROTECTED]
>
>   [cc] aprutil-1.lib(apr_xml.obj) : error LNK2019: unresolved
external
> symb
>
> ol _XML_ParserFree referenced in function _cleanup_parser
>
>   [cc] aprutil-1.lib(apr_xml.obj) : error LNK2019: unresolved
external
> symb
>
> ol _XML_GetErrorCode referenced in function _do_parse
>
>   [cc] aprutil-1.lib(apr_xml.obj) : error LNK2019: unresolved
external
> symb
>
> ol _XML_Parse referenced in function _do_parse
>
>   [cc] aprutil-1.lib(apr_xml.obj) : error LNK2019: unresolved
external
> symb
>
> ol _XML_ErrorString referenced in function [EMAIL PROTECTED]
>
>   [cc] vmcore.dll : fatal error LNK1120: 8 unresolved externals
>
>
>
> Adding compilation of xml/expat/lib/xmlparse.c xmlrole.c xmltok.c to
> aprutil.lib fixed the problem.
>
> Jira issue with the suggested fix :
> http://issues.apache.org/jira/browse/HARMONY-669
>
>
>
> Marina
>

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [drlvm] build fails on Windows os

[Rana Dasgupta]

Hi Weldon,
These headers live in classlib\deploy\include.
Could it be that your external.dep.CLASSLIB property in make/build.xml is
not set correctly?
Also CLASSLIB_HOME in make/win.properties needs setting.

Thanks,
Rana


On 6/26/06, Weldon Washburn <[EMAIL PROTECTED]> wrote:


On 6/26/06, Marina Goldburt <[EMAIL PROTECTED] > wrote:
>
> Jira issue with the suggested fix :
> http://issues.apache.org/jira/browse/HARMONY-669
>
>
> Marina

I applied the 669 patch and it fixed the ...xml linking problems.
Thanks this helps a bunch!

Now  build.native.cpp is failing when I enter the command, "build
-DBUILD_CFG=debug -DCXX=msvc".  My local build tree is at revision
417327.  See the error messages below.  I looked everywhere for
hyvmls.h and zipsup.h but can't find them.  Any suggestions?

build.native.cpp:
  [cc] 2 total files to be compiled.
  [cc] cl : Command line warning D4025 : overriding '/Ox' with '/Od'
  [cc] j9vmls.cpp
  [cc] C:\temp4\drlvm\trunk\vm\vmi\src\j9vmls.cpp(20) : fatal error
C1083:
Cannot open include file: 'hyvmls.h': No such file or directory
  [cc] vmi.cpp
  [cc] C:\temp4\drlvm\trunk\vm\vmi\src\vmi.cpp(25) : fatal error
C1083: Can
not open include file: 'zipsup.h': No such file or directory
  [cc] Generating Code...

BUILD FAILED

Weldon Washburn
Intel Middleware Products Division

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [classlib][testing] excluding the failed tests

[Richard Liang]

Hello Vladimir,

+1 to option 3) . We shall comment the failed test cases out and add 
FIXME to remind us to diagnose the problems later. ;-)


Vladimir Ivanov wrote:

I see your point.
But I feel that we can miss regression in non-tested code if we exclude
TestCases.
Now, for example we miss testing of java.lang.Class/Process/Thread/String
and some other classes.

While we have failing tests and don't want to pay attention to these
failures we can:
1) Leave things as is – do not run TestCases with failing tests.
2) Split passing/failing TestCase into separate "failing TestCase" and
"passing TestCase" and exclude "failing TestCases". When test or
implementation is fixed we move tests from failing TestCase to passing
TestCase.
3) Comment failing tests in TestCases. It is better to run 58 tests 
instead

of 0 for String.
4) Run all TestCases, then, compare test run results with the 'list of 
known

failures' and see whether new failures appeared. This, I think, is better
then 1, 2 and 3, but, overhead is that we support 2 lists - list of known
failing tests and exclude list where we put crashing tests.

Thanks, Vladimir
On 6/26/06, Tim Ellison <[EMAIL PROTECTED]> wrote:


Mikhail Loenko wrote:
> Hi Vladimir,
>
> IMHO the tests are to verify that an update does not introduce any
> regression. So there are two options: remember which exactly tests may
fail
> and remember that all tests must pass. I believe the latter one is 
a bit

> easier and safer.

+1

Tim

> Thanks,
> Mikhail
>
> 2006/6/26, Vladimir Ivanov <[EMAIL PROTECTED]>:
>> Hi,
>> Working with tests I noticed that we are excluding some tests just
>> because
>> several tests from single TestCase fail.
>>
>> For example, the TestCase 'tests.api.java.lang.StringTest' has 60
>> tests and
>> only 2 of them fails. But the build excludes the whole TestCase 
and we

>> just
>> miss testing of java.lang.String implementation.
>>
>> Do we really need to exclude TestCases in 'ant test' target?
>>
>> My suggestion is: do not exclude any tests until it crashes VM.
>> If somebody needs a list of tests that always passed a separated
>> target can
>> be added to build.
>>
>> Do you think we should add target 'test-all' to the build?
>>  Thanks, Vladimir
>>
>>
>
> -
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

--

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]






--
Richard Liang
China Software Development Lab, IBM 




-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [drlvm] build fails on Windows os

[Rana Dasgupta]

On 6/26/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote:


>Odd.  It was broken for me too.  What changed?

>I applied the patch - thanks.



To determine this, one would have to roll back the last commit and retry
the build + smoke tests. And  traverse back till we identify what broke it.
We could also consider requesting the patches that came after this to be
resubmitted. At least.
It may help to start putting in some submission citeria for patches eg., a
successful log from the existing drlvm smoke tests etc. Patches, though not
big, are coming in quite rapidly and it can't be easy for committers to
verify everything on two target platforms.
Also, the existing few smoke tests will not catch all bugs. At some point,
new tests should accompany non trivial submissions. We don't want to get
into a situation where we have a serious breakage.
 It will be good to know how we are doing the corresponding stuff in the
classlibs.

Re: [continuum] BUILD FAILURE: Classlib/win.ia32 Build/Test

[Andrew Zhang]

Hi Tim,

Please do not appy this patch. The test hangs sometimes after applying this
patch.

I'll take a deep look at the test, and suggest exclude the test at first.

Thanks!


On 6/27/06, Andrew Zhang <[EMAIL PROTECTED]> wrote:


 Hi Tim,

I took a look at the test, and found there are some problems in the test.

The test looks like:
while(true){
count = read();
if(count <= 0){ // Error! For nonblocking read, returns 0 means non data
available currently
break;
}
}

For nonblocking read, I think "count <= 0" is not the rigth condition to
break out. "count < 0" should be used instead. What's your opnion? I'm not
very sure whether my patch could fix the problem thoroughly because my
netwrok is so good that the test never fails even with "count <= 0".
Thanks!
Here's the patch for this problem: (or shall I raise a separated JIRA ? )

Index:
src/test/java/org/apache/harmony/tests/java/nio/channels/SocketChannelTest.java
===
---
src/test/java/org/apache/harmony/tests/java/nio/channels/SocketChannelTest.java 
(revision
417326)
+++
src/test/java/org/apache/harmony/tests/java/nio/channels/SocketChannelTest.java 
(working
copy)
@@ -2490,7 +2490,7 @@
 int total = 0;
 while (total < CAPACITY_64KB) {
 count = this.channel1.read(buf);
-if (count <= 0){
+if (count < 0){
 break;
 }
 total = total + count;
@@ -2509,13 +2509,13 @@
 count = in.read(serverRBuf);
 while (total < CAPACITY_64KB + 1) {
 count = this.channel1.read(buf);
-if (count <= 0){
+if (count < 0){
 break;
 }
 total = total + count;
 }
 if (total > 0) {
-assertEquals(total, CAPACITY_64KB);
+assertEquals(CAPACITY_64KB, total);
 for (int i = 0; i < count; i++) {
 assertEquals((byte) i, serverRBuf[i]);
 }


 On 6/27/06, Tim Ellison <[EMAIL PROTECTED]> wrote:
>
> Apache Harmony Build wrote:
> > Online report :
> 
http://ibmonly.hursley.ibm.com/continuum/win.ia32/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/6/buildId/1435
> > Build statistics:
> >   State: Failed
> >   Previous State: Ok
> >   Started at: Mon, 26 Jun 2006 16:09:03 +0100
> >   Finished at: Mon, 26 Jun 2006 16:22:52 +0100
> >   Total time: 13m 48s
> >   Build Trigger: Schedule
> >   Exit code: 1
> >   Building machine hostname: hy1
> >   Operating system : Windows XP(Service Pack 2)
> >   Java version : 1.5.0_06(Sun Microsystems Inc.)
>
> 
>
> >  [exec] [junit] T2 not closed
> >  [exec] [junit] T1 not closed
> >  [exec] [junit] Read fail in capacity64KB,
> testReadByteBuffer_NonBlocking_ReadWriteRealTooLargeData not finish.
> >  [exec] [junit] Tests run: 80, Failures: 1, Errors: 0, Time
> elapsed: 15.491 sec
> >  [exec] [junit] TEST
> org.apache.harmony.tests.java.nio.channels.SocketChannelTest FAILED
> >  [exec] [junit] Tests run: 14, Failures: 0, Errors: 0, Time
> elapsed: 0.313 sec
> >  [exec] [junit] Tests run: 3, Failures: 0, Errors: 0, Time
> elapsed: 0 sec
> >  [exec] [junit] Tests run: 9, Failures: 0, Errors: 0, Time
> elapsed: 0.126 sec
> >  [exec] [junit] Tests run: 2, Failures: 0, Errors: 0, Time
> elapsed: 0.016 sec
> >  [exec] [junit] Tests run: 6, Failures: 0, Errors: 0, Time
> elapsed: 0.094 sec
> >  [exec] [junit] Tests run: 2, Failures: 0, Errors: 0, Time
> elapsed: 0.016 sec
> >  [exec] [junit] Tests FAILED
>
>
> This test seems to be frequently, if intermittently, failing.
>
> expected:<7300> but was:<65536>
>
> junit.framework.AssertionFailedError: expected:<7300> but was:<65536> at
>
> 
org.apache.harmony.tests.java.nio.channels.SocketChannelTest.testReadByteBuffer_NonBlocking_ReadWriteRealTooLargeData(
> SocketChannelTest.java:2518)
> at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:205)
>
>
>
> 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]
>
>


--
Andrew Zhang
China Software Development Lab, IBM





--
Andrew Zhang
China Software Development Lab, IBM

Re: [classlib][testing] excluding the failed tests

[Vladimir Ivanov]

I see your point.
But I feel that we can miss regression in non-tested code if we exclude
TestCases.
Now, for example we miss testing of java.lang.Class/Process/Thread/String
and some other classes.

While we have failing tests and don't want to pay attention to these
failures we can:
1) Leave things as is – do not run TestCases with failing tests.
2) Split passing/failing TestCase into separate "failing TestCase" and
"passing TestCase" and exclude "failing TestCases". When test or
implementation is fixed we move tests from failing TestCase to passing
TestCase.
3) Comment failing tests in TestCases. It is better to run 58 tests instead
of 0 for String.
4) Run all TestCases, then, compare test run results with the 'list of known
failures' and see whether new failures appeared. This, I think, is better
then 1, 2 and 3, but, overhead is that we support 2 lists - list of known
failing tests and exclude list where we put crashing tests.

Thanks, Vladimir
On 6/26/06, Tim Ellison <[EMAIL PROTECTED]> wrote:


Mikhail Loenko wrote:
> Hi Vladimir,
>
> IMHO the tests are to verify that an update does not introduce any
> regression. So there are two options: remember which exactly tests may
fail
> and remember that all tests must pass. I believe the latter one is a bit
> easier and safer.

+1

Tim

> Thanks,
> Mikhail
>
> 2006/6/26, Vladimir Ivanov <[EMAIL PROTECTED]>:
>> Hi,
>> Working with tests I noticed that we are excluding some tests just
>> because
>> several tests from single TestCase fail.
>>
>> For example, the TestCase 'tests.api.java.lang.StringTest' has 60
>> tests and
>> only 2 of them fails. But the build excludes the whole TestCase and we
>> just
>> miss testing of java.lang.String implementation.
>>
>> Do we really need to exclude TestCases in 'ant test' target?
>>
>> My suggestion is: do not exclude any tests until it crashes VM.
>> If somebody needs a list of tests that always passed a separated
>> target can
>> be added to build.
>>
>> Do you think we should add target 'test-all' to the build?
>>  Thanks, Vladimir
>>
>>
>
> -
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

--

Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [drlvm] Doing the minimum to support Java 5 classfiles

[Alexey Varlamov]

Folks,
I'm back to work, glad to hear all of you :).

Looks like planning and technical directions already settled, I'm
right in time to go coding ;)
Seriously, Pavel Pervov made good observation: very basic v49 support
only includes accepting the version number + groking new LDC
semantics. For the DRLVM, these are several-line-patches for verifier,
interpreter and Jitrino.Jet (well, rather a helper function in VM, as
was pointed by Evgueni).

Recognizing new attributes will be needed no sooner than kernel
classes can exploit them.

-
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 fails on Windows os

[Weldon Washburn]

On 6/26/06, Marina Goldburt <[EMAIL PROTECTED]> wrote:


Jira issue with the suggested fix :
http://issues.apache.org/jira/browse/HARMONY-669


Marina


I applied the 669 patch and it fixed the ...xml linking problems.
Thanks this helps a bunch!

Now  build.native.cpp is failing when I enter the command, "build
-DBUILD_CFG=debug -DCXX=msvc".  My local build tree is at revision
417327.  See the error messages below.  I looked everywhere for
hyvmls.h and zipsup.h but can't find them.  Any suggestions?

build.native.cpp:
  [cc] 2 total files to be compiled.
  [cc] cl : Command line warning D4025 : overriding '/Ox' with '/Od'
  [cc] j9vmls.cpp
  [cc] C:\temp4\drlvm\trunk\vm\vmi\src\j9vmls.cpp(20) : fatal error C1083:
Cannot open include file: 'hyvmls.h': No such file or directory
  [cc] vmi.cpp
  [cc] C:\temp4\drlvm\trunk\vm\vmi\src\vmi.cpp(25) : fatal error C1083: Can
not open include file: 'zipsup.h': No such file or directory
  [cc] Generating Code...

BUILD FAILED

Weldon Washburn
Intel Middleware Products Division

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [classlib] moving to 1.5 for real - discuss

[Alexey Varlamov]

Tim, all,

I was offline for 2 weeks, now catching up with Harmony pace... I've
seen more specific thread started, "[drlvm] Doing the minimum to
support Java 5 classfiles",
so just a quick affirmative to round off this thread:
Yes, I'm going to patch this in the nearest time.

2006/6/16, Tim Ellison <[EMAIL PROTECTED]>:

Geir Magnusson Jr wrote:
> I'd like to suggest that we get at least one of the project VMs to
> support this before we switch.

Yep, Alexey said that there were "some (minor) changes" required to
DRLVM, and Archie said that JCHEVM should already handle the new
classfile format.  Hopefully we will all align at the same time.

Alexey: I know that you indicated support to change the compiler target,
but is the DRLVM support something you can patch quite soon?

Just to be clear, at this point we are referring to supporting the new
classfile format, not fully-fledged support for new 1.5 features like
annotations, reflection, etc.

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]

Re: [classlib] ant test fail

[Richard Liang]

Mark Hindess wrote:

On 26 June 2006 at 22:51, Richard Liang <[EMAIL PROTECTED]> wrote:
  

--090101060803000509020200
Thanks a lot, Geir.

I do copy junit.jar to my ant/lib, but notice there is no ant-junit.jar 
in the directory. Just wondering why my Ubuntu does not install a 
full-version of ant. ;-)



Debian has an "ant-optional" package.  (IIRC, it is split from the ant
package to reduce the interdependencies when the building packages.  The
"ant-optional" package is in the "Recommends" list for "ant" so install
tools like aptitude should [offer to] install it when you install ant.)

  

Thanks a lot, Mark.

-Mark.

  

Geir Magnusson Jr wrote:


is junit.jar in your ant/lib directory?

geir


Richard Liang wrote:
  
  

Hello,

When I try to run all tests of the classlib, the following errors occur.
It's about junit, I think I should not be required for additional
configuration, or do I miss something? ;-)

[EMAIL PROTECTED]:~/harmony/trunk$ ant test
Buildfile: build.xml

test:
[echo]
[echo] 
[echo] Testing class libraries...
[echo] 

clean:
  [delete] Deleting directory /home/liangyx/harmony/trunk/build/test_repor


t


copy-test-resources:

check-support-jars:

check:
[echo] Checking for depends/jars/xalan-j_2.7.0/xalan.jar
[echo] Checking for depends/jars/xerces_2.8.0/resolver.jar
[echo] Checking for depends/jars/xerces_2.8.0/xercesImpl.jar
[echo] Checking for depends/jars/xerces_2.8.0/xml-apis.jar
[echo] Checking for depends/jars/junit_3.8.2/junit.jar
[echo] Checking for depends/jars/bcprov-jdk14-133/signed.bcprov.jar
[echo] Checking for depends/jars/icu4j_3.4.4/icu4j_3_4_4.jar
[echo] Checking for depends/jars/mx4j_3.0.1/mx4j.jar
[echo] Checking for depends/jars/mx4j_3.0.1/mx4j-remote.jar
[echo] Checking for depends/jars/ecj_3.2MAINT/ecj_3.2MAINT.jar

create-unsigned-bcprov-jar:

check-win:

compile-support:

test-modules:

call-modules-all:

compile.java:
[echo] Compiling ACCESSIBILITY classes

build.jar:

build:

compile.tests:
[echo] Compiling ACCESSIBILITY tests

run.tests:
   [mkdir] Created dir: /home/liangyx/harmony/trunk/build/test_report

BUILD FAILED
/home/liangyx/harmony/trunk/build.xml:105: The following error occurred
while executing this line:
/home/liangyx/harmony/trunk/make/build-test.xml:48: The following error
occurred while executing this line:
/home/liangyx/harmony/trunk/make/properties.xml:176: The following error
occurred while executing this line:
/home/liangyx/harmony/trunk/make/properties.xml:186: The following error
occurred while executing this line:
/home/liangyx/harmony/trunk/modules/accessibility/build.xml:110: Could
not create task or type of type: junit.




-
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 



--090101060803000509020200--







-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


  


--
Richard Liang
China Software Development Lab, IBM 

Re: [continuum] BUILD FAILURE: Classlib/win.ia32 Build/Test

[Andrew Zhang]

Hi Tim,

I took a look at the test, and found there are some problems in the test.

The test looks like:
while(true){
count = read();
if(count <= 0){ // Error! For nonblocking read, returns 0 means non data
available currently
break;
}
}

For nonblocking read, I think "count <= 0" is not the rigth condition to
break out. "count < 0" should be used instead. What's your opnion? I'm not
very sure whether my patch could fix the problem thoroughly because my
netwrok is so good that the test never fails even with "count <= 0".
Thanks!
Here's the patch for this problem: (or shall I raise a separated JIRA ? )

Index:
src/test/java/org/apache/harmony/tests/java/nio/channels/SocketChannelTest.java
===
---
src/test/java/org/apache/harmony/tests/java/nio/channels/SocketChannelTest.java
(revision
417326)
+++
src/test/java/org/apache/harmony/tests/java/nio/channels/SocketChannelTest.java
(working
copy)
@@ -2490,7 +2490,7 @@
int total = 0;
while (total < CAPACITY_64KB) {
count = this.channel1.read(buf);
-if (count <= 0){
+if (count < 0){
break;
}
total = total + count;
@@ -2509,13 +2509,13 @@
count = in.read(serverRBuf);
while (total < CAPACITY_64KB + 1) {
count = this.channel1.read(buf);
-if (count <= 0){
+if (count < 0){
break;
}
total = total + count;
}
if (total > 0) {
-assertEquals(total, CAPACITY_64KB);
+assertEquals(CAPACITY_64KB, total);
for (int i = 0; i < count; i++) {
assertEquals((byte) i, serverRBuf[i]);
}


On 6/27/06, Tim Ellison <[EMAIL PROTECTED]> wrote:


Apache Harmony Build wrote:
> Online report :
http://ibmonly.hursley.ibm.com/continuum/win.ia32/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/6/buildId/1435
> Build statistics:
>   State: Failed
>   Previous State: Ok
>   Started at: Mon, 26 Jun 2006 16:09:03 +0100
>   Finished at: Mon, 26 Jun 2006 16:22:52 +0100
>   Total time: 13m 48s
>   Build Trigger: Schedule
>   Exit code: 1
>   Building machine hostname: hy1
>   Operating system : Windows XP(Service Pack 2)
>   Java version : 1.5.0_06(Sun Microsystems Inc.)



>  [exec] [junit] T2 not closed
>  [exec] [junit] T1 not closed
>  [exec] [junit] Read fail in capacity64KB,
testReadByteBuffer_NonBlocking_ReadWriteRealTooLargeData not finish.
>  [exec] [junit] Tests run: 80, Failures: 1, Errors: 0, Time
elapsed: 15.491 sec
>  [exec] [junit] TEST
org.apache.harmony.tests.java.nio.channels.SocketChannelTest FAILED
>  [exec] [junit] Tests run: 14, Failures: 0, Errors: 0, Time
elapsed: 0.313 sec
>  [exec] [junit] Tests run: 3, Failures: 0, Errors: 0, Time
elapsed: 0 sec
>  [exec] [junit] Tests run: 9, Failures: 0, Errors: 0, Time
elapsed: 0.126 sec
>  [exec] [junit] Tests run: 2, Failures: 0, Errors: 0, Time
elapsed: 0.016 sec
>  [exec] [junit] Tests run: 6, Failures: 0, Errors: 0, Time
elapsed: 0.094 sec
>  [exec] [junit] Tests run: 2, Failures: 0, Errors: 0, Time
elapsed: 0.016 sec
>  [exec] [junit] Tests FAILED


This test seems to be frequently, if intermittently, failing.

expected:<7300> but was:<65536>

junit.framework.AssertionFailedError: expected:<7300> but was:<65536> at

org.apache.harmony.tests.java.nio.channels.SocketChannelTest.testReadByteBuffer_NonBlocking_ReadWriteRealTooLargeData
(SocketChannelTest.java:2518)
at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:205)



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]





--
Andrew Zhang
China Software Development Lab, IBM

Re: [drlvm] build fails on Windows os

[Geir Magnusson Jr]

Odd.  It was broken for me too.  What changed?

I applied the patch - thanks.

geir


Marina Goldburt wrote:
> Hi,
> 
> I've caught the following error when tried to build the drlvm today on
> Windows OS:
> 
> 
> 
>   [cc] 0 total files to be compiled.
> 
>   [cc] Starting link
> 
>   [cc]Creating library vmcore.lib and object vmcore.exp
> 
>   [cc] aprutil-1.lib(apr_xml.obj) : error LNK2019: unresolved external
> symb
> 
> ol _XML_SetCharacterDataHandler referenced in function
> [EMAIL PROTECTED]
> 
>   [cc] aprutil-1.lib(apr_xml.obj) : error LNK2019: unresolved external
> symb
> 
> ol _XML_SetElementHandler referenced in function [EMAIL PROTECTED]
> 
>   [cc] aprutil-1.lib(apr_xml.obj) : error LNK2019: unresolved external
> symb
> 
> ol _XML_SetUserData referenced in function [EMAIL PROTECTED]
> 
>   [cc] aprutil-1.lib(apr_xml.obj) : error LNK2019: unresolved external
> symb
> 
> ol _XML_ParserCreate referenced in function [EMAIL PROTECTED]
> 
>   [cc] aprutil-1.lib(apr_xml.obj) : error LNK2019: unresolved external
> symb
> 
> ol _XML_ParserFree referenced in function _cleanup_parser
> 
>   [cc] aprutil-1.lib(apr_xml.obj) : error LNK2019: unresolved external
> symb
> 
> ol _XML_GetErrorCode referenced in function _do_parse
> 
>   [cc] aprutil-1.lib(apr_xml.obj) : error LNK2019: unresolved external
> symb
> 
> ol _XML_Parse referenced in function _do_parse
> 
>   [cc] aprutil-1.lib(apr_xml.obj) : error LNK2019: unresolved external
> symb
> 
> ol _XML_ErrorString referenced in function [EMAIL PROTECTED]
> 
>   [cc] vmcore.dll : fatal error LNK1120: 8 unresolved externals
> 
> 
> 
> Adding compilation of xml/expat/lib/xmlparse.c xmlrole.c xmltok.c to
> aprutil.lib fixed the problem.
> 
> Jira issue with the suggested fix :
> http://issues.apache.org/jira/browse/HARMONY-669
> 
> 
> 
> Marina
> 

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [classlib] Merging frameworks for testing serialization - first step

[Geir Magnusson Jr]

One minor thing - if you do an ant rebuild and then go into a module to
test something specific, it won't work because the support stuff doesn't
get build.

I don't know the right solution.  Maybe the module build.xml triggers
building the support test, or just a note somewhere to remind people?

geir


Stepan Mishura wrote:
> On 6/26/06, Tim Ellison wrote:
>>
>> Stepan Mishura wrote:
>> > On 6/26/06, Tim Ellison wrote:
>> >>
>> >> Stepan Mishura wrote:
>> >> > Hi,
>> >> >
>> >> > I've updated framework for testing serialization page[1] - I added
>> >> > guidelines
>> >> > for developing serialization tests. Also I've removed confusing
>> >> 'TestCase'
>> >> > parameter in SerializationTest.verifySelf() methods.
>> >> >
>> >> > If there are no objections I'm going in next two days to move
>> >> > SerializationTest.java from 'security' module to support folder. So
>> new
>> >> > location will be:
>> >> > support/src/test/java/org/apache/harmony/testframework/serialization
>> >> > folder.
>> >> > Class name won't change.
>> >> >
>> >> > Thoughts?
>> >>
>> >> Looks good, just a couple of minor comments:
>> >>
>> >> - You might as well move them (or duplicate them) to an
>> >> org.apache.harmony. package while you are moving things around, since
>> we
>> >> want to get rid of tests.util as a package name.
>> >
>> > 'Them' means tests, right?
>>
>> Sorry, I actually meant the testing framework itself.  The doc says
>>
>>"The testing framework provides support class
>> tests.util.SerializationTest  for serialization testing."
>>
>> I figured it would be easier to put them in the right place.
> 
> 
> Ops..., sorry. I thought about replacing SerializationTester and
> accidentally put its package name. It should say:
> " The testing framework provides support class
> org.apache.harmony.testframework.serialization.SerializationTest for
> serialization testing."
> 
> I fixed the doc in r417196. Looks better now? :-)
> 
>> - Please will you ensure that the Manifests are updated accordingly so
>> >> that the world is not broken.
>> >
>> >
>> > Sure, I will try.
>> >
>> > - Not sure about the word 'golden' to mean 'reference' data, when we
>> >> could just use reference, but whatever.
>> >
>> > In the method names or resource file name? Or both?
>>
>> Ideally both, it just seems like jargon -- but I realize that such
>> renaming doesn't really 'advance the cause', so whatever you think.
> 
> 
> I'm OK with 'reference' and currently 'golden' can be easily replaced with
> it. Otherwise after we rename everything it will be not so simple.
> 
> Thanks,
> Stepan.
> 
> Regards,
>> Tim
>>
>> >> >
>> >> > [1]
>> >> >
>> >>
>> http://incubator.apache.org/harmony/subcomponents/classlibrary/ser_testing.html
>>
>> >>
>> >> >
>> >> >
>> >> > On 6/20/06, Stepan Mishura  wrote:
>> >> >>
>> >> >>  Hi,
>> >> >>
>> >> >> I'm going to start merging existing frameworks for testing
>> >> serialization.
>> >> >>
>> >> >> As first step I've updated 'security' framework. The updated
>> framework
>> >> >> searches and loads resource files according [1] and eliminates
>> >> >> requirement
>> >> >> to extend SerializationTest. Also to provide smooth frameworks
>> merging
>> >> >> I've
>> >> >> put stub to let the framework search resources in the 'old' way (
>> i.e.
>> >> >> via
>> >> >> "RESOURCE_DIR" system property). The stub will be removed after
>> >> >> completing
>> >> >> the merge.
>> >> >>
>> >> >> The updated framework suggests the following way for testing
>> >> >> serialization:
>> >> >>
>> >> >> a) Compatibility – 4 new static methods are introduced.
>> >> >> verifyGolden(TestCase, Object)
>> >> >> verifyGolden(TestCase, Object, SerializableAssert)
>> >> >> verifyGolden(TestCase, Object[])
>> >> >> verifyGolden(TestCase, Object[], SerializableAssert)
>> >> >>
>> >> >> A test should invoke one of above methods, for example,
>> >> >> public void testCompatibility() throws Exception {
>> >> >> SerializationTest.verifyGolden(this, new SomeSerializableClass
>> >> ());
>> >> >> }
>> >> >>
>> >> >> b) Self-testing: the same as for compatibility – there are 4 new
>> >> static
>> >> >> methods that should be invoked from a test:
>> >> >> verifySelf(TestCase, Object)
>> >> >> verifySelf(Object, SerializableAssert)
>> >> >> verifySelf(TestCase, Object[])
>> >> >> verifySelf(Object[], SerializableAssert)
>> >> >>
>> >> >> For example,
>> >> >> public void testSelf() throws Exception {
>> >> >> SerializationTest.verifySelf(new SomeSerializableClass(), new
>> >> >> MyComparator());
>> >> >> }
>> >> >>
>> >> >> To complete frameworks merging I'd like to suggest the next steps:
>> >> >> 2) Reviewing the update and the suggested way for testing
>> >> >> serialization by
>> >> >> the community. Please let me know if it is acceptable and what can
>> be
>> >> >> improved.
>> >> >> 3) Replace SerializationTester class with SerializationTest. I'm
>> going
>> >> to
>> >> >> add more stubs to let existing test

Re: svn commit: r417148 - in /incubator/harmony/enhanced/classlib/trunk/modules/luni/src: main/java/java/util/Formatter.java test/java/tests/api/java/util/FormatterTest.java

[Geir Magnusson Jr]

Nathan Beyer wrote:
> Sure, no problem.
> 
> While talking about this issue, I did want to bring up that the
> FormatterTest as it stands, even before this small addendum, doesn't pass
> against the RI (Sun 5.0_7). 

Would you mind if I'm lazy and ask why?

geir

This particular test isn't in the 'api' test
> folder as defined by our suggested best practice, so this may not be
> important, but is this expected/known?
> 
> -Nathan
> 
>> -Original Message-
>> From: Tim Ellison [mailto:[EMAIL PROTECTED]
>> Sent: Monday, June 26, 2006 4:46 AM
>> To: harmony-dev@incubator.apache.org
>> Subject: Re: svn commit: r417148 - in
>> /incubator/harmony/enhanced/classlib/trunk/modules/luni/src:
>> main/java/java/util/Formatter.java
>> test/java/tests/api/java/util/FormatterTest.java
>>
>> Soory for being petty, but could you please include the JIRA title as
>> well as the JIRA number in the log message, so I can read the reason
>> without having to endure the joys of the JIRA webpages?
>>
>> Thanks
>> Tim
>>
>> [EMAIL PROTECTED] wrote:
>>> Author: ndbeyer
>>> Date: Mon Jun 26 02:06:44 2006
>>> New Revision: 417148
>>>
>>> URL: http://svn.apache.org/viewvc?rev=417148&view=rev
>>> Log:
>>> Apply patch for HARMONY-653.
>>>
>>> Modified:
>>>
>> incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java/
>> util/Formatter.java
>> incubator/harmony/enhanced/classlib/trunk/modules/luni/src/test/java/tests
>> /api/java/util/FormatterTest.java
>>
>> --
>>
>> 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: Using Visual Studio C++ Express to compile classlib - fails.

[Rana Dasgupta]

On 6/26/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote:


>I used to build classlib successfully on WinXP with completely free
>environment, that is MS VS.NET  2005 Express, MS Platform
SDK Server 2003 R2
>and NASM from Cygwin (there is no free MASM with license which allows OSS
>development, it can be found for local experiments on quite many sites).



Gregory,
   Not sure what you mean by "no free masm with license which allows OSS
development"...Version 8.0, compatible with VC++ 2005 Express is
downloadable for free from the Microsoft Download site...


http://www.microsoft.com/downloads/details.aspx?familyid=7A1C9DA0-0510-44A2-B042-7EF370530C64&displaylang=en

  The clck-thru license does say something about not using it for
developing software to be commercially distributed, does that violate ?

   I also read your interesting experiments on the other linked
thread. Microsoft appears to have a new tool mt.exe to embed these
manifests:
   mt.exe -manifest someapp.exe.manifest -outputresource:someapp.exe;1
   ( 1 for .exe and 2 for .dll )

   Could be added as a post-build step.

Rana



-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [classlib] [beans] xml resource files in tests

[Geir Magnusson Jr]

I thought I said it in public as well.  Sorry.

Alexei Zakharov wrote:
> Since this code is located in unit test IMHO it makes some sense to
> compare the output line by line with the desired content.  Of course
> it also can be (should be) read into DOM but I will need to refactor
> the tests to apply it.
> 
> BTW, Geir has said (in private) it is ok to simply remove the license
> from test data. So I'm going to do as he suggested.
> 
> Of course
> 
> 2006/6/26, Tim Ellison <[EMAIL PROTECTED]>:
>> Should the tests be doing a line-by line comparison anyway?  i.e. I can
>> reformat the XML file and it still means the same thing, I would not
>> expect the test to fail.
>>
>> Can't you read the golden data into a DOM and check it is the same
>> (maybe Node.isEqualNode(Node) or thereabouts)?
>>
>> Regards,
>> Tim
>>
>> Alexei Zakharov wrote:
>> > Well, the real question I'd like to get an answer for was: is it
>> > really impossible to remove the license from these files?
>> >
>> > 2006/6/22, Alexei Zakharov <[EMAIL PROTECTED]>:
>> >> Ilya, yes, it is technically possible. But IMHO is not very elegant at
>> >> the same time.
>> >>
>> >> 2006/6/22, Ilya Neverov <[EMAIL PROTECTED]>:
>> >> > Hi,
>> >> >
>> >> > Is it easier to preprocess golden files data before the string
>> >> > comparison? Removing first XML comment with the text
>> >> > "Copyright*Apache" seems to be an action which can not modify
>> content
>> >> > used in the comparison.
>> >> >
>> >> > Thank you.
>> >> > Ilya Neverov,
>> >> > Intel Middleware Products Division
>> >> >
>> >> > On 6/22/06, Alexei Zakharov <[EMAIL PROTECTED]> wrote:
>> >> > > Hi people,
>> >> > >
>> >> > > While working on java.beans tests I've faced a funny problem.
>> There
>> >> > > are tests for XMLEncoder that perform line by line comparison
>> of the
>> >> > > encoder's output with static xml files from /test/resources folder
>> >> > > (string compare). And it seems that at some point of time someone
>> >> > > simply prepend Apache license to all static xmls and all tests
>> fail
>> >> > > since then. :)
>> >> > > Since there is no easy way to force XMLEncoder to generate Apache
>> >> > > license, I see two possible resolutions:
>> >> > > 1. Remove the license from xmls. I am not sure we can do that.
>> >> > > 2. Replace string compare with xml compare, by means of sax parser
>> >> for
>> >> > > example. Comments will be thrown away in this case.
>> >> > > Personally I like (2) more. However, it will take additional
>> efforts.
>> >> > > Suggestions?
>> >> > >
>> >> > > --
>> >> > > Alexei Zakharov,
>> >> > > Intel Middleware Product Division
>> >
>>
>> -- 
>>
>> 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] mem

[Geir Magnusson Jr]

Tim Ellison wrote:
> Geir Magnusson Jr wrote:
>> Tim Ellison wrote:
>>> Geir Magnusson Jr wrote:
 Except...

 1) They aren't as Jimmy suggests, at least the one's I'm looking at.

 2) the implementation in hymem.c just calls malloc()

 I'm confused.
>>> Hopefully you are no longer confused after Oliver's explanation.
>> Yes, although I am still confused why you would want to do this.
> 
> (I hope I see what you are confused about, but correct me if I'm wrong)
> 
>> We have an implementation in hymem.c :
>>
>>   hymem_alloc_memory( HyPortLib *, int )
> 
> That is the actual function that allocates memory, and in this case it
> is platform specific, eventually calling HeapAlloc on Windows and malloc
> on Linux.
> 
> This function is (deliberately) not exported from the hyprt.dll so you
> cannot call it directly.  You have to call it via the function pointer
> table ...

That's the missing element - it's not exported.

[snip obvious stuff]

> 
> Of course, you can reference that member directly if you so choose, and
> as written elsewhere if you are dealing with multiple tables the
> syntactic sugar doesn't help and you must reference it in full.
> 

When would you have multiple tables?

[snip]

> 
> I guess that the confusion is caused by the HyPortLib struct containing
> a member called 'mem_allocate_memory' that has the address of a function
> called 'hymem_allocate_memory'?
> 

really it was having a macro and a function named the same, differing
only by a number of arguments where the macro expanded out to what has
the potential of being something very different than the function
because of the function table.  It wasn't obvious that the function
wasn't exported (of course).

thanks

geir




-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [general] milestones and roadmap

[Geir Magnusson Jr]

There was another. :)  I'll summarize tomorrow.

geir

Tim Ellison wrote:
> Looks like the ideas dried up.  Are you going to track and organize?  Do
> you want help?
> 
> Regards,
> Tim
> 
> Geir Magnusson Jr wrote:
>> I'd like to start assembling a high-level roadmap of the milestones we'd
>> like to achieve in the next 12 months.
>>
>> I volunteer to track and organize, but this clearly is a community
>> activity so lets start by just tossing out ideas.
>>
>> 1) By ApcheCon EU - a combined snapshot that is a pure open source VM +
>> classlib.  Issues - I assume we'll use DRLVM.
>>
>> 2) Integration of Doug Lea's java.util.concurrency package.  Issues -
>> right now, Nathan is looking at it, and we'll need support from the
>> various VMs.
>>
>> 3) Build framework - I'm hoping Mark/IBM is able to get us booted on
>> this via a contribution to /testing that makes it easy for people to do
>> the same CI runs that he's doing
>>
>> 4) Incorporate the Java SE TCK into build framework.  This requires a
>> few things, first the build framework and people interested in working
>> on that, and second, the Java SE TCK.  I'm working on the latter in my
>> role as the ASFs JCP rep, and I'm guessing this will take a while.
>>
>> 5) Switch to Java 5 - in both classlib and our VMs
>>
>> 6) CORBA - start looking at Yoko to see what we can reuse for Harmony,
>> and start integrating that.
>>
>> 7) Test coverage - should we think about targets for test coverage ?
>>
>> 8) Package completion roadmap
>>
>> 9) JMX - right now, I believe mark has finished integrating MX4J, but we
>> need to start enhancing that with Java 5 features.
>>
>> What else? :)
>>
>> geir
>>
>>
>> -
>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
> 

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [general] milestones and roadmap

[Ivan Volosyuk]

19. Performance improvement. Optimize class libraries and VM. There
was some tips how to do better java code. Performance critical places
can be revised and reimplemented more efficiently.

--
Ivan

On 6/27/06, Tim Ellison <[EMAIL PROTECTED]> wrote:

Looks like the ideas dried up.  Are you going to track and organize?  Do
you want help?

Regards,
Tim

Geir Magnusson Jr wrote:
> I'd like to start assembling a high-level roadmap of the milestones we'd
> like to achieve in the next 12 months.
>
> I volunteer to track and organize, but this clearly is a community
> activity so lets start by just tossing out ideas.
>
> 1) By ApcheCon EU - a combined snapshot that is a pure open source VM +
> classlib.  Issues - I assume we'll use DRLVM.
>
> 2) Integration of Doug Lea's java.util.concurrency package.  Issues -
> right now, Nathan is looking at it, and we'll need support from the
> various VMs.
>
> 3) Build framework - I'm hoping Mark/IBM is able to get us booted on
> this via a contribution to /testing that makes it easy for people to do
> the same CI runs that he's doing
>
> 4) Incorporate the Java SE TCK into build framework.  This requires a
> few things, first the build framework and people interested in working
> on that, and second, the Java SE TCK.  I'm working on the latter in my
> role as the ASFs JCP rep, and I'm guessing this will take a while.
>
> 5) Switch to Java 5 - in both classlib and our VMs
>
> 6) CORBA - start looking at Yoko to see what we can reuse for Harmony,
> and start integrating that.
>
> 7) Test coverage - should we think about targets for test coverage ?
>
> 8) Package completion roadmap
>
> 9) JMX - right now, I believe mark has finished integrating MX4J, but we
> need to start enhancing that with Java 5 features.
>
> What else? :)


-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [drlvm] what's next?

[Ivan Volosyuk]

If somebody interested, I can share my GC which was made to replace GC
v4. It addresses performance issues I've noticed on GC v4:
  - too many atomic ops
  - too many bit shifts
  - too many passes (touches of objects data)

New GC (which has code name gc_yuk) is combination of copying and
compacting collector with adaptive switching. It can switch from
copying to compacting during one GC, so evacuation area can be quite
small and dynamically predicted. Copying collector has very simple
code pass with one advanced idea and it is extremely fast. Sliding
compacting algorithm is used when performance equation suggests it or
when evacuation area overflows.

About performance, on SpecJBB2005 (modified to be used on jre1.4) on
Dual HT Xeon 3.2GHz gc_yuk versus gc_v4 gives:
  - 27% score gain
  - 7 times less average GC pauses
  - 5 times less time spent in stop-the-world state

I think the idea of all advanced algorithms is to give high
performance, IMHO this code would be good starting point in
performance race.

I am going to continue improving and experimenting with this code
base. The code is quite small ~170kb of sources with 1/3 of it in
copyright headers. And quite clean and easy for experimenting. I have
tried a few parallelization attempts, but it didn't give me
performance improvement on the mentioned above server. Looks like the
limiting factor of performance is memory speed - little CPU work
needed, but all live objects need to be scanned. Next step would be to
make a concurrent GC algorithm, it can be a solution for further
performance improvement.
--
Ivan
Intel Middleware Products Division

On 6/20/06, Weldon Washburn <[EMAIL PROTECTED]> wrote:

On 6/20/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote:
> Build and dependency issues aside, what are the next functional
> enhancements / features for DRLVM?
>
> I think #1 is to get it to function with Java 5 classfiles, so we can
> make the switch throughout the project.
>
> Thoughts? What else?
I agree with java 5 being #1.  Some additional thoughts.  GCV4 needs
replacing for a variety of reasons.  The port of MMTk should pick up a
bunch of the great GC work being done in the Jikes/MMTk community.  It
would also  be nice to have a simple C generational collector.  I am
real busy with MMTk port.  Otherwise I would volunteer to look into
porting SableVM's generational collector.  I think it was written by
Carl Lebsack.  Porting both MMTk and SableVM GC would give DRLVM a
much better basis for generic VM/GC interfaces.

Another thing that needs to happen in DRLVM is a well designed
VM-JIT-GC synchronization protocol.   Clear, understandable
system-wide synch protocol will be very nice to have when we get to
the point of advanced threading module.   This really does not exist
today.  If there is interest, I could start a harmony-dev email thread
on this topic.


-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Using Visual Studio C++ Express to compile classlib - fails.

[Gregory Shimansky]

On Tuesday 27 June 2006 00:29 Thorbjørn Ravn Andersen wrote:
> Mark Hindess skrev  den 26-06-2006 21:57:
> > What would a feasible path be from here?
> >
> >
> > Looks like one of the variables set in one of those "empty" included
> > makefiles should be CC set to cl ?
>
> I forgot to state that I somewhat arbitrarily tried doing exactly that,
> but without any success in locating the right one.   I therefore hoped
> to hear from a person who knows more about this build system.
>
> BTW Do you know if there is any particular reason that files are copied
> over to the deploy directory instead of being read directly from their
> original location and the compiled output written to deploy?

I used to build classlib successfully on WinXP with completely free 
environment, that is MS VS.NET 2005 Express, MS Platform SDK Server 2003 R2 
and NASM from Cygwin (there is no free MASM with license which allows OSS 
development, it can be found for local experiments on quite many sites).

Overall the impression is that neither classlib nor drlvm are really ready to 
be built with VS.NET 2005. It has too much new stuff incompatible with older 
versions.

You can try to use my instructions in [1]. The NASM port of assembly can be 
found in [2]. To set initial MS development environment I changed c:
\cygwin\cygwin.bat like this:

@echo off
rem call "C:\Program Files\Microsoft Visual Studio 8\VC\vcvarsall.bat" x86
call "c:\Program Files\Microsoft Platform SDK for Windows Server 2003 
R2\SetEnv.Cmd" /XP32
C:
chdir C:\cygwin\bin
bash --login -i

[1] 
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200606.mbox/[EMAIL
 PROTECTED]

[2] http://issues.apache.org/jira/browse/HARMONY-566

-- 
Gregory Shimansky, Intel Middleware Products Division

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Using Visual Studio C++ Express to compile classlib - fails.

[Rana Dasgupta]

On 6/26/06, Thorbjørn Ravn Andersen <[EMAIL PROTECTED]> wrote:


>I have now tried fiddling with Visual Studio C++ Express (free download
f>or the time being from Microsoft, which would enable me to participate)
>to see if I could build classlib with it under Windows XP, but have
>failed so far.

>I made some progress however.  Nmake initially complains that it cannot
>find an ntwin32.mak which I then put in native-src/win.IA32 as an empty
>file.  Then win32.mak was missing - throwing liberal amount of empty
>win32.mak files all over made nmake happy, but then the actual compiler
>invocation fails:



You can try downloading and installing the Microsft Platform SDK( free
) which has the NTWin32.Mak and win32.mak files. You could use nmake.exe out
of that distribution too, though it is also included in the compiler
package. This may help
http://msdn.microsoft.com/vstudio/express/visualc/usingpsdk/

You also need to run the initialization scripts( if you haven't already
) like vcvars32.bat out of your compiler's bin directory and setenv.cmd in
the Platform SDK installation. This should set the necessary variables.



   [exec] '-Ogityb1' is not recognized as an internal or external command,
>[exec] operable program or batch file.
>[exec] NMAKE : fatal error U1077: '-Ogityb1' : return code '0x1'
>[exec] Stop.
>[exec] NMAKE : fatal error U1077: '"C:\Program Files\Microsoft
>Visual Studio 8\VC\bin\nmake.exe"' : return code '0x2'
 >   [exec] Stop.





Thanks,

  Rana

Re: [general] milestones and roadmap

[Tim Ellison]

Looks like the ideas dried up.  Are you going to track and organize?  Do
you want help?

Regards,
Tim

Geir Magnusson Jr wrote:
> I'd like to start assembling a high-level roadmap of the milestones we'd
> like to achieve in the next 12 months.
> 
> I volunteer to track and organize, but this clearly is a community
> activity so lets start by just tossing out ideas.
> 
> 1) By ApcheCon EU - a combined snapshot that is a pure open source VM +
> classlib.  Issues - I assume we'll use DRLVM.
> 
> 2) Integration of Doug Lea's java.util.concurrency package.  Issues -
> right now, Nathan is looking at it, and we'll need support from the
> various VMs.
> 
> 3) Build framework - I'm hoping Mark/IBM is able to get us booted on
> this via a contribution to /testing that makes it easy for people to do
> the same CI runs that he's doing
> 
> 4) Incorporate the Java SE TCK into build framework.  This requires a
> few things, first the build framework and people interested in working
> on that, and second, the Java SE TCK.  I'm working on the latter in my
> role as the ASFs JCP rep, and I'm guessing this will take a while.
> 
> 5) Switch to Java 5 - in both classlib and our VMs
> 
> 6) CORBA - start looking at Yoko to see what we can reuse for Harmony,
> and start integrating that.
> 
> 7) Test coverage - should we think about targets for test coverage ?
> 
> 8) Package completion roadmap
> 
> 9) JMX - right now, I believe mark has finished integrating MX4J, but we
> need to start enhancing that with Java 5 features.
> 
> What else? :)
> 
> geir
> 
> 
> -
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 

-- 

Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [classlib] mem

[Tim Ellison]

Geir Magnusson Jr wrote:
> Tim Ellison wrote:
>> Geir Magnusson Jr wrote:
>>> Except...
>>>
>>> 1) They aren't as Jimmy suggests, at least the one's I'm looking at.
>>>
>>> 2) the implementation in hymem.c just calls malloc()
>>>
>>> I'm confused.
>> Hopefully you are no longer confused after Oliver's explanation.
> 
> Yes, although I am still confused why you would want to do this.

(I hope I see what you are confused about, but correct me if I'm wrong)

> We have an implementation in hymem.c :
> 
>   hymem_alloc_memory( HyPortLib *, int )

That is the actual function that allocates memory, and in this case it
is platform specific, eventually calling HeapAlloc on Windows and malloc
on Linux.

This function is (deliberately) not exported from the hyprt.dll so you
cannot call it directly.  You have to call it via the function pointer
table ...

There is also a similar function called
  hymem_allocate_memory_callSite that has an extra
  param to help debug the memory allocation calling
  site)

> which looks just like
> 
>   hymem_alloc_memory(int)
> 
> (if you use the right header)

This is a macro defined in portlib.h that adds syntactic sugar so you
can write hymem_alloc_memory(int) and the compiler will expand it into
the function table look-up for you.

...
#define hymem_allocate_memory(param1)
privatePortLibrary->mem_allocate_memory(privatePortLibrary,param1)
...

where 'privatePortLibrary' was obtained most likely from a JNIEnv struct
or a JavaVM struct etc. and 'mem_allocate_memory' is the member in the
function table (as defined in hyport.h) that contains the address of the
function 'hymem_allocate_memory()' described above.

See the definition, in portpriv.h, for
static HyPortLibrary MasterPortLibraryTable = ...

Of course, you can reference that member directly if you so choose, and
as written elsewhere if you are dealing with multiple tables the
syntactic sugar doesn't help and you must reference it in full.

  Just noticed that the hyport.h contains this directive
#undef hymem_allocate_memory
#define hymem_allocate_memory(param1) \
  privatePortLibrary-> \
mem_allocate_memory_callSite(privatePortLibrary,param1, \
 HY_GET_CALLSITE())
so we are actually using the _callSite slot each time.

> and it calls what might be two radically different things.

You lost me here ...

The macro always expands out to a reference like this:

privatePortLibrary   (local var, defined by PORTLIB... macro)
 -> mem_allocate_memory  (address of function hymem_allocate_memory)
 (privatePortLibrary,param1) (invocation)

I guess that the confusion is caused by the HyPortLib struct containing
a member called 'mem_allocate_memory' that has the address of a function
called 'hymem_allocate_memory'?

> Why do we have himem.c?  Should we rename?   Toss?

(assuming himem.c == hymem.c)

Do you mean rename the file / function / struct member / macro or all of
the above ;-) ?

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: Using Visual Studio C++ Express to compile classlib - fails.

[Thorbjørn Ravn Andersen]

Mark Hindess skrev  den 26-06-2006 21:57:

  What would a feasible path be from here?
  
  
Looks like one of the variables set in one of those "empty" included 
makefiles should be CC set to cl ?
  

I forgot to state that I somewhat arbitrarily tried doing exactly that,
but without any success in locating the right one.   I therefore hoped
to hear from a person who knows more about this build system.

BTW Do you know if there is any particular reason that files are copied
over to the deploy directory instead of being read directly from their
original location and the compiled output written to deploy? 

-- 
  Thorbjørn





smime.p7s
Description: S/MIME Cryptographic Signature

Re: svn commit: r417248 - in /incubator/harmony/enhanced/classlib/trunk: depends/build/ modules/luni/ modules/luni/src/main/native/launcher/ modules/luni/src/main/native/launcher/linux/ modules/luni/s

[Gregory Shimansky]

Cool. Thanks a lot Mark. You've fixed it better than I suggested.

On Monday 26 June 2006 22:58 Mark Hindess wrote:
> Fixed in r417277.
>
> -Mark.
>
> On 26 June 2006 at 22:45, Gregory Shimansky <[EMAIL PROTECTED]> wrote:
> > Hello Tim
> >
> > I've got another classlib build problem on linux. In the file below I had
> > to add $(DLLPATH)libhysig.so to MDLLIBFILES list or I get this error from
> > linker:
> >
> >
> > Execute:Java13CommandLauncher: Executing 'make' with
> >  [exec] cc  \
> > [exec] ../shared/main.o ../shared/cmain.o ../shared/launcher_copyright.o
> > ../s hared/strbuf.o ../shared/libhlp.o
> > \
> > [exec] -g -Xlinker --start-group
> > /home/gregory/work/Harmony/harmony/enhanced/
> > classlib/trunk/deploy/jdk/jre/bin/libhyprt.so
> > /home/gregory/work/Harmony/harm
> > ony/enhanced/classlib/trunk/deploy/jdk/jre/bin/libhythr.so -Xlinker
> > --end-gro up
> > \
> >  [exec] -o ../java -lm -lpthread -lc -ldl \
> >  [exec] -Xlinker -z -Xlinker origin \
> >  [exec] -Xlinker -rpath -Xlinker \$ORIGIN/ \
> >  [exec] -Xlinker -rpath-link -Xlinker ..
> > [exec]
> > /usr/lib/gcc/i686-pc-linux-gnu/3.4.6/../../../../i686-pc-linux-gnu/bin
> > /ld:
> > warning: libhysig.so, needed
> > by
> > /home/gregory/work/Harmony/harmony/enhanced/classlib/trunk/deploy/jdk/jre
> >/ bin/libhyprt.so,
> > not found (try using -rpath or -rpath-link)
> >
> > [exec]
> > /home/gregory/work/Harmony/harmony/enhanced/classlib/trunk/deploy/jdk/
> > jre/bin/libhyprt.so:
> > undefined reference to [EMAIL PROTECTED]'
> >
> > [exec]
> > /home/gregory/work/Harmony/harmony/enhanced/classlib/trunk/deploy/jdk/
> > jre/bin/libhyprt.so:
> > undefined reference to [EMAIL PROTECTED]'
> >
> > [exec]
> > /home/gregory/work/Harmony/harmony/enhanced/classlib/trunk/deploy/jdk/
> > jre/bin/libhyprt.so:
> > undefined reference to [EMAIL PROTECTED]'
> >
> > [exec]
> > /home/gregory/work/Harmony/harmony/enhanced/classlib/trunk/deploy/jdk/
> > jre/bin/libhyprt.so:
> > undefined reference to [EMAIL PROTECTED]'
> >  [exec] collect2: ld returned 1 exit status
> >  [exec] make: *** [../java] Ошибка 1
> >
> > On Monday 26 June 2006 21:36 [EMAIL PROTECTED] wrote:
> > > Author: tellison
> > > Date: Mon Jun 26 10:35:59 2006
> > > New Revision: 417248
> > >
> > > URL: http://svn.apache.org/viewvc?rev=417248&view=rev
> > > Log:
> > > Apply patch HARMONY-668 (Move vmls and launcher natives to luni module)
> >
> > 
> >
> > > ===
> > > === ---
> > > incubator/harmony/enhanced/classlib/trunk/native-src/linux.IA32/launche
> > >r/ma kefile (original) +++
> > > incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/native/
> > >laun cher/linux/makefile Mon Jun 26 10:35:59 2006 @@ -18,10 +18,11 @@
> > >
> > >  include $(HY_HDK)/build/make/makefile.include
> > >
> > > +SHAREDSUB=../shared/
> > >  BUILDFILES = $(SHAREDSUB)main.o $(SHAREDSUB)cmain.o \
> > >   $(SHAREDSUB)launcher_copyright.o $(SHAREDSUB)strbuf.o \
> > >   $(SHAREDSUB)libhlp.o
> > > -MDLLIBFILES = ../libhyprt.so ../libhythr.so
> > > +MDLLIBFILES = $(DLLPATH)libhyprt.so $(DLLPATH)libhythr.so
> > >  EXENAME = $(EXEPATH)java
> > >
> > >  include $(HY_HDK)/build/make/rules.mk
> >
> > 

-- 
Gregory Shimansky, Intel Middleware Products Division

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Using Visual Studio C++ Express to compile classlib - fails.

[Mark Hindess]

On 26 June 2006 at 21:40, =?ISO-8859-1?Q?Thorbj=F8rn_Ravn_Andersen?= <[EMAIL 
PROTECTED]> wrote:
>
> I have now tried fiddling with Visual Studio C++ Express (free download
> for the time being from Microsoft, which would enable me to participate)
> to see if I could build classlib with it under Windows XP, but have
> failed so far.
> 
> I made some progress however.  Nmake initially complains that it cannot
> find an ntwin32.mak which I then put in native-src/win.IA32 as an empty
> file.  Then win32.mak was missing - throwing liberal amount of empty
> win32.mak files all over made nmake happy, but then the actual compiler
> invocation fails:
> 
>   [exec] Microsoft (R) Program Maintenance Utility Version 8.00.50727.42
>  [exec] Copyright (C) Microsoft Corporation.  All rights reserved.
>  [exec] cd sig
>  [exec] "C:\Program Files\Microsoft Visual Studio
> 8\VC\bin\nmake.exe" /NOLOGO
>  [exec] -Ogityb1 -WX -GF -Gs -MD -Zi -Zm400  -D_DLL -D_MT -DWIN32
> -D_WIN32_WINNT=3D0x0400 -D_WINSOCKAPI_ -DWINVER=3D0x0400   /IC:\Documents
> and Settings\TRA\workspace-harmony\Harmony\deploy\include /IC:\Documents 
> and Settings\TRA\workspace-harmony\Harmony\deploy\jdk\include /I.
> /I..\..\..\modules\luni\src\main\native\include\shared
> /I..\..\..\modules\luni\src\main\native\include\windows
> -Fo..\..\shared\sig\hysig_copyright.obj ..\..\shared\sig\hysig_copyright.c
>  [exec] '-Ogityb1' is not recognized as an internal or external command,
>  [exec] operable program or batch file.
>  [exec] NMAKE : fatal error U1077: '-Ogityb1' : return code '0x1'
>  [exec] Stop.
>  [exec] NMAKE : fatal error U1077: '"C:\Program Files\Microsoft
> Visual Studio 8\VC\bin\nmake.exe"' : return code '0x2'
>  [exec] Stop.
> 
> The question is then where this is defined.  I have worked quite a bit
> with gcc but am completely green with this environment.
> 
> What would a feasible path be from here?

Looks like one of the variables set in one of those "empty" included 
makefiles should be CC set to cl ?

-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: [drlvm] Doing the minimum to support Java 5 classfiles

[Geir Magnusson Jr]

Andrey Chernyshev wrote:
> On 6/23/06, Mark Hindess <[EMAIL PROTECTED]> wrote:
>>
>> On 23 June 2006 at 17:10, Tim Ellison <[EMAIL PROTECTED]> wrote:
>> > Rana Dasgupta wrote:
>> > > On 6/23/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote:
>> > >> >>Pavel Pervov wrote:
>> > >> >> Geir,
>> > >> >>
>> > >> >> What's the first thing we do?
>> > >> >> I'd suggest switching the build to 1.5.
>> > >> >>
>> > >> >> The rest will come shortly :)
>> > >>
>> > >> >Now that's a plan! :)
>> > >
>> > >
>> > > Hi Geir,
>> > >  Actually what Pavel says makes sense. Not sure what plan we need.
>> We could
>> > > do it either way. We can make some changes to the class structure,
>> loader,
>> > > and the jit/interpreter, and submit a couple of patches. It is not
>> the
>> > > "huge" patch that you have mentioned .. 7-8 files or so. Or we can
>> switch
>> > > the build first. This will break drlvm for a short time, and we can
>> > > submit a
>> > > couple of bug fixes to get it going again. This way, we will just
>> add the
>> > > minimum needed for removing the compiler hack. Whatever way you
>> think makes
>> > > sense.
>> > >  However, you started this thread with saying "no patch over the
>> wall"
>> > > and making this "learning exercise about DRLVM". Where are you
>> going with
>> > > this? Do you want to actually enumerate/discuss which source files
>> need to
>> > > change and in what way, on this thread so that more people can
>> participate?
>> > >
>> > > Marginally confused :-)
>> > > Rana
>> >
>> > Just for the record, my goal was to avoid 'moving the goalposts' for
>> > drlvm to integrate with the classlib and run the tests, apps, etc.
>> >
>> > If consensus here is that moving to 5.0 (and thereby delaying that
>> goal)
>> > is more desirable then I'm happy to go along with it, though I'm
>> keen to
>> > get the entire end-to-end story working soonest.
>> >
>> > Regards,
>> > Tim
>>
>> My feeling at the moment is that although drlvm and classlib are working
>> together[0], it is evident[1] that things are not really integrated.
>> I would prefer to see "real integration" before we break[0] things by
>> moving to 5.0.
> 
> I agree the integration doesn't look perfect. On the other hand,
> improving integration and moving to 5.0 could be quite independent.
> Integration issues seem to be mostly related to the building /
> packaging, while 5.0 support would require adding / changing a code.

This is my POV as well.  I'm guessing they are independent, at least the
basics for accepting a v5 classfile.

> 
>>
>> As Geir pointed out recently, we are not just a Class library project,
>> so perhaps a change of focus is warranted?  Perhaps if we can agree a
>> set of prerequisite goals (involving our JVMs) for moving to 5.0, we can
>> ... err ... encourage this change of focus?
>>
>> My prerequisite goals would include things like:
>>
>> 1) Fix the (reasonable) 'hacks' that help us get this far with drlvm
>> integration - e.g. the static libhyprt.a for instance.[2]
> 
> It seems libhyprt is needed by VMI module to implement GetPortLibrary
> function.
> I guess static hyprt library is still needed for Windows (this is why
> it was added) while it isn't needed on Linux. The dependency on hyprt
> could be handled more gracefully with  tags.

I don't understand why it has to be static.

> 
>>
>> 2) Implement enough of the classlibadapter kernel classes such that
>> JCHEVM will run 'ant rebuild' in classlib[3].  We have some difficult
>> problems (thread attach) but there is also a lot of low hanging fruit in
>> terms of missing or incomplete methods.
>>
>> 3) Get drlvm loading with the Harmony launcher from Classlib so we
>> can have both drlvm and IBM VME around for testing.  I think this is
>> important because it will make it easier for people to test with either
>> JVM.
> 
> Do we want every VM, capable of working with Harmony classlib, be
> started with the Harmony launcher? 

No, but ours certainly could.

> It's probably could be too
> restrictive and may require additional work for adopting other VM's
> for classlib.
> However, I completely agree that the non-standard name breaks other
> tools and scripts. Wouldn't it be sufficient just to rename ij->java?

Yes

> 
>>
>> 4) Change the drlvm build so that its deploy tree layout has no classlib
>> files in it.  So we can do ...
>>
>> 5) Create the top-level build that can combine the trimmed drlvm deploy
>> tree and the classlib deploy tree to produce a working jdk.  (In much
>> the same way that we currently combine the classlib and IBM VME.)
>>
>> 6) Pull out shared dependencies to top-level so we only need one copy.
> 
> It looks like most of these issues are relating to the building files.
> Geir, would you be willing to work on that, or, someone else could try?

Anyone can try.  I have a top-level federation started, and will do more
tomorrow and get that checked in.

What would help is to rip out all the dependency stuff for DRLVM and
just move to a peer direct

Re: [classlib] [beans] xml resource files in tests

[Thorbjørn Ravn Andersen]

Tim Ellison skrev  den 26-06-2006 13:22:

Should the tests be doing a line-by line comparison anyway?  i.e. I can
reformat the XML file and it still means the same thing, I would not
expect the test to fail.
  
James Clark defined Canonical XML in order to be able to compare xml 
documents as byte streams.


http://www.jclark.com/xml/canonxml.html

Perhaps this would be a good place to incorporate it?

--
 Thorbjørn



smime.p7s
Description: S/MIME Cryptographic Signature

[drlvm] design issues re: merging SableVM's GC write barrier code

[Weldon Washburn]

All,

Please take a look and tell me if the following seems correct:

drlvm/trunk/vm/vmcore/src/util/ia32/base/jit_runtime_support_ia32.cpp,
line 507 contains the entry point for the runtime helper that the JIT
uses for generating write barrier calls. (For simplicity, we will not
do any inlining at this point.)This JIT runtime helper is created
during boot and is called, getaddress__gc_write_barrier_fastcall() and
is in the same ...support_ia32.cpp file.  Its basically a very short
asm language stub that turns around and calls, gc_write_barrier()
which is located in, drlvm/trunk/vm/gc/src/gc_for_vm.cpp, line 572.
gc_write_barrier() is currently an empty stub.  This is where DRLVM
intends write barriers for GCs written in "C" to go.  And, by the way,
gc_for_vm.cpp in DRLVM mentions that the JIT should call the write
barrier *after* doing the write.  Two observations.  a) DRLVM did not
originally have the concept of substituting write barrier and b) its
probably best to observe the write followed by write barrier ordering
lest we trip upon some obscure bugs.  The lack of substituting write
barrier is not a biggie.  It should be simple to add this to the VM/GC
API when we neeed to do so.

Now let's talk about what goes in the empty stub called
gc_write_barrier() to support SableVM's generational GC.

At sableVM/sablevm-sdk-1.13/sablevm/src/libsablevm/gc_gencopy.h, line #35 is:

_svmf_write_barrier (_svmt_JNIEnv *env, _svmt_object_instance **ref)

This C routine is a very thin wrapper that does an indirect call of:

_svmf_remember_set_add()

Which is located at
sableVM/sablevm-sdk-1.13/sablevm/src/libsablevm/gc_gencopy.c, line
643.  This is a basic, simple open hash.  It looks like there are a
few #defines plus one typdef struct that have to be pulled into the
DRLVM code base to get the SableVM GC write barrier to build.

Does the above make sense?  Is there anything missing?  My next step
will be to turn in JIRA patches that merge SableVM GC write barriers
into DRLVM.

   Thanks





--
Weldon Washburn
Intel Middleware Products Division

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Using Visual Studio C++ Express to compile classlib - fails.

[Thorbjørn Ravn Andersen]

I have now tried fiddling with Visual Studio C++ Express (free download 
for the time being from Microsoft, which would enable me to participate) 
to see if I could build classlib with it under Windows XP, but have 
failed so far.


I made some progress however.  Nmake initially complains that it cannot 
find an ntwin32.mak which I then put in native-src/win.IA32 as an empty 
file.  Then win32.mak was missing - throwing liberal amount of empty 
win32.mak files all over made nmake happy, but then the actual compiler 
invocation fails:


 [exec] Microsoft (R) Program Maintenance Utility Version 8.00.50727.42
[exec] Copyright (C) Microsoft Corporation.  All rights reserved.
[exec] cd sig
[exec] "C:\Program Files\Microsoft Visual Studio 
8\VC\bin\nmake.exe" /NOLOGO
[exec] -Ogityb1 -WX -GF -Gs -MD -Zi -Zm400  -D_DLL -D_MT -DWIN32 
-D_WIN32_WINNT=0x0400 -D_WINSOCKAPI_ -DWINVER=0x0400   /IC:\Documents 
and Settings\TRA\workspace-harmony\Harmony\deploy\include /IC:\Documents 
and Settings\TRA\workspace-harmony\Harmony\deploy\jdk\include /I. 
/I..\..\..\modules\luni\src\main\native\include\shared 
/I..\..\..\modules\luni\src\main\native\include\windows 
-Fo..\..\shared\sig\hysig_copyright.obj ..\..\shared\sig\hysig_copyright.c

[exec] '-Ogityb1' is not recognized as an internal or external command,
[exec] operable program or batch file.
[exec] NMAKE : fatal error U1077: '-Ogityb1' : return code '0x1'
[exec] Stop.
[exec] NMAKE : fatal error U1077: '"C:\Program Files\Microsoft 
Visual Studio 8\VC\bin\nmake.exe"' : return code '0x2'

[exec] Stop.

The question is then where this is defined.  I have worked quite a bit 
with gcc but am completely green with this environment.


What would a feasible path be from here?

--
 Thorbjørn



smime.p7s
Description: S/MIME Cryptographic Signature

Re: svn commit: r416738 - /incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/init/bootclasspath.properties

[Ivan Volosyuk]

On 6/26/06, Tim Ellison <[EMAIL PROTECTED]> wrote:

Ivan Volosyuk wrote:
> Tim,
>
> I am talking about the version of eclipse compiler from eclipse
> downloaded by drlvm build. It works on jre1.4, but it refuses to
> accept -target jsr14 and -source 1.5 if running on jre1.4.
> The eclipse compiler downloaded by classlib (ecj_*) works fine with
> this settings.

Not sure what version you are getting, but support for that combination
of flags was quite recently added.


Well, this can possibly mean that the eclipse downloaded by drlvm's
'build update' contains outdate compiler without '-target jsr14'
support. It makes sense to stop download it anyway. I am going to make
JIRA with patch for this issue, may be tomorrow. I will not regret if
somebody else will do it before me ;)
--
Ivan



Regards,
Tim

> --
> Best regards,
> Ivan
>
> On 6/26/06, Tim Ellison <[EMAIL PROTECTED]> wrote:
>> Ivan Volosyuk wrote:
>> > I have found solution for this build problem. If somebody interested:
>> >
>> > To use downloaded eclipse (or its compiler) need to run:
>> > sh build.sh -Dbuild.compiler=org.eclipse.jdt.core.JDTCompilerAdapter
>> >
>> > But the compiler in theis eclipse version doesn't work with jre1.4, so
>>
>> Not quite sure what this means, since all the Eclipse code only requires
>> JRE1.4.
>>
>> Regards,
>> Tim
>>
>> > I need to change build.sh, removing:
>> >  CLASSPATH=$CLASSPATH:`pwd`/make/tmp/org.eclipse.jdt.core_3.1.1.jar
>> > and changing:
>> >  CLASSPATH=`pwd`/make/tmp/cpptasks/cpptasks.jar:$CLASSPATH
>> > in order to use CLASSPATH specified in command line environment. I
>> > used ecj_3.2RC5 from classlib. After this, compilation works fine.
>> >
>> > I run eclipse with the compiled drlvm and it started fine, except for
>> > the message:


-
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] Doing the minimum to support Java 5 classfiles

[Andrey Chernyshev]

On 6/23/06, Mark Hindess <[EMAIL PROTECTED]> wrote:


On 23 June 2006 at 17:10, Tim Ellison <[EMAIL PROTECTED]> wrote:
> Rana Dasgupta wrote:
> > On 6/23/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote:
> >> >>Pavel Pervov wrote:
> >> >> Geir,
> >> >>
> >> >> What's the first thing we do?
> >> >> I'd suggest switching the build to 1.5.
> >> >>
> >> >> The rest will come shortly :)
> >>
> >> >Now that's a plan! :)
> >
> >
> > Hi Geir,
> >  Actually what Pavel says makes sense. Not sure what plan we need. We could
> > do it either way. We can make some changes to the class structure, loader,
> > and the jit/interpreter, and submit a couple of patches. It is not the
> > "huge" patch that you have mentioned .. 7-8 files or so. Or we can switch
> > the build first. This will break drlvm for a short time, and we can
> > submit a
> > couple of bug fixes to get it going again. This way, we will just add the
> > minimum needed for removing the compiler hack. Whatever way you think makes
> > sense.
> >  However, you started this thread with saying "no patch over the wall"
> > and making this "learning exercise about DRLVM". Where are you going with
> > this? Do you want to actually enumerate/discuss which source files need to
> > change and in what way, on this thread so that more people can participate?
> >
> > Marginally confused :-)
> > Rana
>
> Just for the record, my goal was to avoid 'moving the goalposts' for
> drlvm to integrate with the classlib and run the tests, apps, etc.
>
> If consensus here is that moving to 5.0 (and thereby delaying that goal)
> is more desirable then I'm happy to go along with it, though I'm keen to
> get the entire end-to-end story working soonest.
>
> Regards,
> Tim

My feeling at the moment is that although drlvm and classlib are working
together[0], it is evident[1] that things are not really integrated.
I would prefer to see "real integration" before we break[0] things by
moving to 5.0.


I agree the integration doesn't look perfect. On the other hand,
improving integration and moving to 5.0 could be quite independent.
Integration issues seem to be mostly related to the building /
packaging, while 5.0 support would require adding / changing a code.



As Geir pointed out recently, we are not just a Class library project,
so perhaps a change of focus is warranted?  Perhaps if we can agree a
set of prerequisite goals (involving our JVMs) for moving to 5.0, we can
... err ... encourage this change of focus?

My prerequisite goals would include things like:

1) Fix the (reasonable) 'hacks' that help us get this far with drlvm
integration - e.g. the static libhyprt.a for instance.[2]


It seems libhyprt is needed by VMI module to implement GetPortLibrary function.
I guess static hyprt library is still needed for Windows (this is why
it was added) while it isn't needed on Linux. The dependency on hyprt
could be handled more gracefully with  tags.



2) Implement enough of the classlibadapter kernel classes such that
JCHEVM will run 'ant rebuild' in classlib[3].  We have some difficult
problems (thread attach) but there is also a lot of low hanging fruit in
terms of missing or incomplete methods.

3) Get drlvm loading with the Harmony launcher from Classlib so we
can have both drlvm and IBM VME around for testing.  I think this is
important because it will make it easier for people to test with either
JVM.


Do we want every VM, capable of working with Harmony classlib, be
started with the Harmony launcher? It's probably could be too
restrictive and may require additional work for adopting other VM's
for classlib.
However, I completely agree that the non-standard name breaks other
tools and scripts. Wouldn't it be sufficient just to rename ij->java?



4) Change the drlvm build so that its deploy tree layout has no classlib
files in it.  So we can do ...

5) Create the top-level build that can combine the trimmed drlvm deploy
tree and the classlib deploy tree to produce a working jdk.  (In much
the same way that we currently combine the classlib and IBM VME.)

6) Pull out shared dependencies to top-level so we only need one copy.


It looks like most of these issues are relating to the building files.
Geir, would you be willing to work on that, or, someone else could try?

Thanks,
Andrey.





At the moment, I think moving to 5.0 would increase the divide between
the JVMs and Classlib.

In the meantime there is still plenty of work to do for those that, for
whatever reasons, don't find these tasks exciting enough - for instance,
the missing java.lang.Character/java.lang.Math methods[4].

Regards,
 Mark.

[0] Thanks Geir!

[1] http://issues.apache.org/jira/browse/HARMONY-651

[2] This isn't a criticism; I think these hacks can be justified.

[3] I tried this the other day.  It got to the second (non-comment) line
of the first ant script before crashing because ClassLoader.getResources()
isn't implemented yet.

[4] http://www.kaffe.org/~stuart/japi/htmlout/h-jdk15-harmony.html#pkg_java

Re: [continuum] BUILD FAILURE: Classlib/linux.ia32 Build/Test

[Oliver Deakin]

Ok, this is my fault (gulp!) - I ran the build on both my Windows and 
Linux machines, and they both built and passed the tests. However, I 
think the Linux machine may have somehow picked up an old artifact (not 
sure how this would happen since the link error is against a lib not 
moved by my changes, but it's the only reason I can think of for it 
working) from another build and linked against that. My patch was 
missing an alteration to the Linux executable link line that pointed it 
to the deploy/jdk/jre/bin directory.


Mark has applied a fix to the link line and the Linux builds should be 
back in working order now. Sorry for the break - guess it's my turn at 
the bar...


Regards,
Oliver


Apache Harmony Build wrote:

Online report : 
http://ibmonly.hursley.ibm.com/continuum/linux.ia32/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/6/buildId/3134
Build statistics:
  State: Failed
  Previous State: Ok
  Started at: Mon, 26 Jun 2006 19:09:18 +0100
  Finished at: Mon, 26 Jun 2006 19:11:49 +0100
  Total time: 2m 31s
  Build Trigger: Schedule
  Exit code: 1
  Building machine hostname: hy2
  Operating system : Linux(unknown)
  Java version : 1.5.0_06(Sun Microsystems Inc.)


 [exec]  [exec] cc -O1 -march=pentium3 -DLINUX -D_REENTRANT 
-DIPv6_FUNCTION_SUPPORT -DHYX86  
-I/home/hybld/continuum-working-directory/6/classlib/deploy/include 
-I/home/hybld/continuum-working-directory/6/classlib/deploy/jdk/include -I. 
-I../shared/   -c -o ../shared/launcher_copyright.o 
../shared/launcher_copyright.c
 [exec]  [exec] cc -O1 -march=pentium3 -DLINUX -D_REENTRANT 
-DIPv6_FUNCTION_SUPPORT -DHYX86  
-I/home/hybld/continuum-working-directory/6/classlib/deploy/include 
-I/home/hybld/continuum-working-directory/6/classlib/deploy/jdk/include -I. 
-I../shared/   -c -o ../shared/strbuf.o ../shared/strbuf.c
 [exec]  [exec] cc -O1 -march=pentium3 -DLINUX -D_REENTRANT 
-DIPv6_FUNCTION_SUPPORT -DHYX86  
-I/home/hybld/continuum-working-directory/6/classlib/deploy/include 
-I/home/hybld/continuum-working-directory/6/classlib/deploy/jdk/include -I. 
-I../shared/   -c -o ../shared/libhlp.o ../shared/libhlp.c
 [exec]  [exec] cc  \
 [exec]  [exec] ../shared/main.o ../shared/cmain.o 
../shared/launcher_copyright.o ../shared/strbuf.o ../shared/libhlp.o   \
 [exec]  [exec] -Xlinker --start-group 
/home/hybld/continuum-working-directory/6/classlib/deploy/jdk/jre/bin/libhyprt.so
 
/home/hybld/continuum-working-directory/6/classlib/deploy/jdk/jre/bin/libhythr.so
 -Xlinker --end-group \
 [exec]  [exec] -o ../java -lm -lpthread -lc -ldl \
 [exec]  [exec] -Xlinker -z -Xlinker origin \
 [exec]  [exec] -Xlinker -rpath -Xlinker \$ORIGIN/ \
 [exec]  [exec] -Xlinker -rpath-link -Xlinker ..
 [exec]  [exec] /usr/bin/ld: warning: libhysig.so, needed by 
/home/hybld/continuum-working-directory/6/classlib/deploy/jdk/jre/bin/libhyprt.so,
 not found (try using -rpath or -rpath-link)
 [exec]  [exec] 
/home/hybld/continuum-working-directory/6/classlib/deploy/jdk/jre/bin/libhyprt.so:
 undefined reference to [EMAIL PROTECTED]'
 [exec]  [exec] 
/home/hybld/continuum-working-directory/6/classlib/deploy/jdk/jre/bin/libhyprt.so:
 undefined reference to [EMAIL PROTECTED]'
 [exec]  [exec] 
/home/hybld/continuum-working-directory/6/classlib/deploy/jdk/jre/bin/libhyprt.so:
 undefined reference to [EMAIL PROTECTED]'
 [exec]  [exec] 
/home/hybld/continuum-working-directory/6/classlib/deploy/jdk/jre/bin/libhyprt.so:
 undefined reference to [EMAIL PROTECTED]'
 [exec]  [exec] collect2: ld returned 1 exit status
 [exec]  [exec] make: *** [../java] Error 1

 [exec] BUILD FAILED
 [exec] /home/hybld/continuum-working-directory/6/classlib/build.xml:90: 
The following error occurred while executing this line:
 [exec] 
/home/hybld/continuum-working-directory/6/classlib/native-src/build.xml:136: 
The following error occurred while executing this line:
 [exec] 
/home/hybld/continuum-working-directory/6/classlib/modules/luni/build.xml:97: 
exec returned: 2

 [exec] Total time: 2 minutes 25 seconds

BUILD FAILED
/home/hybld/continuum-working-directory/6/build.xml:118: exec returned: 1

Total time: 2 minutes 29 seconds





  


--
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: svn commit: r417248 - in /incubator/harmony/enhanced/classlib/trunk: depends/build/ modules/luni/ modules/luni/src/main/native/launcher/ modules/luni/src/main/native/launcher/linux/ modules/luni/s

[Mark Hindess]

Fixed in r417277.

-Mark.

On 26 June 2006 at 22:45, Gregory Shimansky <[EMAIL PROTECTED]> wrote:
> Hello Tim
> 
> I've got another classlib build problem on linux. In the file below I had to 
> add $(DLLPATH)libhysig.so to MDLLIBFILES list or I get this error from 
> linker:
> 
> 
> Execute:Java13CommandLauncher: Executing 'make' with
>  [exec] cc  \ 
> [exec] ../shared/main.o ../shared/cmain.o ../shared/launcher_copyright.o ../s
> hared/strbuf.o ../shared/libhlp.o   
> \
> [exec] -g -Xlinker --start-group /home/gregory/work/Harmony/harmony/enhanced/
> classlib/trunk/deploy/jdk/jre/bin/libhyprt.so /home/gregory/work/Harmony/harm
> ony/enhanced/classlib/trunk/deploy/jdk/jre/bin/libhythr.so -Xlinker --end-gro
> up 
> \
>  [exec] -o ../java -lm -lpthread -lc -ldl \
>  [exec] -Xlinker -z -Xlinker origin \
>  [exec] -Xlinker -rpath -Xlinker \$ORIGIN/ \
>  [exec] -Xlinker -rpath-link -Xlinker .. 
> [exec] /usr/lib/gcc/i686-pc-linux-gnu/3.4.6/../../../../i686-pc-linux-gnu/bin
> /ld: 
> warning: libhysig.so, needed 
> by /home/gregory/work/Harmony/harmony/enhanced/classlib/trunk/deploy/jdk/jre/
> bin/libhyprt.so, 
> not found (try using -rpath or -rpath-link)
>  
> [exec] /home/gregory/work/Harmony/harmony/enhanced/classlib/trunk/deploy/jdk/
> jre/bin/libhyprt.so: 
> undefined reference to [EMAIL PROTECTED]'
>  
> [exec] /home/gregory/work/Harmony/harmony/enhanced/classlib/trunk/deploy/jdk/
> jre/bin/libhyprt.so: 
> undefined reference to [EMAIL PROTECTED]'
>  
> [exec] /home/gregory/work/Harmony/harmony/enhanced/classlib/trunk/deploy/jdk/
> jre/bin/libhyprt.so: 
> undefined reference to [EMAIL PROTECTED]'
>  
> [exec] /home/gregory/work/Harmony/harmony/enhanced/classlib/trunk/deploy/jdk/
> jre/bin/libhyprt.so: 
> undefined reference to [EMAIL PROTECTED]'
>  [exec] collect2: ld returned 1 exit status
>  [exec] make: *** [../java] Ошибка 1
> 
> 
> On Monday 26 June 2006 21:36 [EMAIL PROTECTED] wrote:
> > Author: tellison
> > Date: Mon Jun 26 10:35:59 2006
> > New Revision: 417248
> >
> > URL: http://svn.apache.org/viewvc?rev=417248&view=rev
> > Log:
> > Apply patch HARMONY-668 (Move vmls and launcher natives to luni module)
> 
> 
> 
> > ===
> >=== ---
> > incubator/harmony/enhanced/classlib/trunk/native-src/linux.IA32/launcher/ma
> >kefile (original) +++
> > incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/native/laun
> >cher/linux/makefile Mon Jun 26 10:35:59 2006 @@ -18,10 +18,11 @@
> >
> >  include $(HY_HDK)/build/make/makefile.include
> >
> > +SHAREDSUB=../shared/
> >  BUILDFILES = $(SHAREDSUB)main.o $(SHAREDSUB)cmain.o \
> > $(SHAREDSUB)launcher_copyright.o $(SHAREDSUB)strbuf.o \
> > $(SHAREDSUB)libhlp.o
> > -MDLLIBFILES = ../libhyprt.so ../libhythr.so
> > +MDLLIBFILES = $(DLLPATH)libhyprt.so $(DLLPATH)libhythr.so
> >  EXENAME = $(EXEPATH)java
> >
> >  include $(HY_HDK)/build/make/rules.mk
> 
> 
> -- 
> Gregory Shimansky, Intel Middleware Products Division
> 
> -
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]





-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: svn commit: r417248 - in /incubator/harmony/enhanced/classlib/trunk: depends/build/ modules/luni/ modules/luni/src/main/native/launcher/ modules/luni/src/main/native/launcher/linux/ modules/luni/s

[Gregory Shimansky]

Hello Tim

I've got another classlib build problem on linux. In the file below I had to 
add $(DLLPATH)libhysig.so to MDLLIBFILES list or I get this error from 
linker:


Execute:Java13CommandLauncher: Executing 'make' with
 [exec] cc  \ 
[exec] ../shared/main.o ../shared/cmain.o ../shared/launcher_copyright.o 
../shared/strbuf.o ../shared/libhlp.o   
\
[exec] -g -Xlinker --start-group 
/home/gregory/work/Harmony/harmony/enhanced/classlib/trunk/deploy/jdk/jre/bin/libhyprt.so
 
/home/gregory/work/Harmony/harmony/enhanced/classlib/trunk/deploy/jdk/jre/bin/libhythr.so
 -Xlinker --end-group 
\
 [exec] -o ../java -lm -lpthread -lc -ldl \
 [exec] -Xlinker -z -Xlinker origin \
 [exec] -Xlinker -rpath -Xlinker \$ORIGIN/ \
 [exec] -Xlinker -rpath-link -Xlinker .. 
[exec] 
/usr/lib/gcc/i686-pc-linux-gnu/3.4.6/../../../../i686-pc-linux-gnu/bin/ld: 
warning: libhysig.so, needed 
by 
/home/gregory/work/Harmony/harmony/enhanced/classlib/trunk/deploy/jdk/jre/bin/libhyprt.so,
 
not found (try using -rpath or -rpath-link)
 
[exec] 
/home/gregory/work/Harmony/harmony/enhanced/classlib/trunk/deploy/jdk/jre/bin/libhyprt.so:
 
undefined reference to [EMAIL PROTECTED]'
 
[exec] 
/home/gregory/work/Harmony/harmony/enhanced/classlib/trunk/deploy/jdk/jre/bin/libhyprt.so:
 
undefined reference to [EMAIL PROTECTED]'
 
[exec] 
/home/gregory/work/Harmony/harmony/enhanced/classlib/trunk/deploy/jdk/jre/bin/libhyprt.so:
 
undefined reference to [EMAIL PROTECTED]'
 
[exec] 
/home/gregory/work/Harmony/harmony/enhanced/classlib/trunk/deploy/jdk/jre/bin/libhyprt.so:
 
undefined reference to [EMAIL PROTECTED]'
 [exec] collect2: ld returned 1 exit status
 [exec] make: *** [../java] Ошибка 1


On Monday 26 June 2006 21:36 [EMAIL PROTECTED] wrote:
> Author: tellison
> Date: Mon Jun 26 10:35:59 2006
> New Revision: 417248
>
> URL: http://svn.apache.org/viewvc?rev=417248&view=rev
> Log:
> Apply patch HARMONY-668 (Move vmls and launcher natives to luni module)



> ===
>=== ---
> incubator/harmony/enhanced/classlib/trunk/native-src/linux.IA32/launcher/ma
>kefile (original) +++
> incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/native/laun
>cher/linux/makefile Mon Jun 26 10:35:59 2006 @@ -18,10 +18,11 @@
>
>  include $(HY_HDK)/build/make/makefile.include
>
> +SHAREDSUB=../shared/
>  BUILDFILES = $(SHAREDSUB)main.o $(SHAREDSUB)cmain.o \
>   $(SHAREDSUB)launcher_copyright.o $(SHAREDSUB)strbuf.o \
>   $(SHAREDSUB)libhlp.o
> -MDLLIBFILES = ../libhyprt.so ../libhythr.so
> +MDLLIBFILES = $(DLLPATH)libhyprt.so $(DLLPATH)libhythr.so
>  EXENAME = $(EXEPATH)java
>
>  include $(HY_HDK)/build/make/rules.mk


-- 
Gregory Shimansky, Intel Middleware Products Division

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [drlvm] Doing the minimum to support Java 5 classfiles

[Rana Dasgupta]

Several good, sensible comments on things to address in the JVM's fro better

integration. Specifically for DRLVM, I read them as ...



  1. Getting rid of ij.exe :-) and getting DRLVM to be launched by the
Harmony launcher as the IBM VME is done today. Volunteers welcome :-)
  2. Better build/deploy integration so that the drlvm deployment directory
has no classlib files in it ...and changing the top level build to be able
to create a jdk out of classlibs + drlvm. I think this is good to do, but
we can start a seperate thread for this..several existing threads have a
little scattered but useful informationand then do it.
 3. Removal of the some of the integration hacks eg., static libhyprt.a.
The "[classlibs] hythread implementation" thread is starting to discuss some
of these issues, hopefully that will identify what needs to happen.


  For the basic move to Java5 ( which eg., jchevm already supports ), I
would propose that we don't need to wait for the above items to complete,
but start making these code changes now since Evgueni posted a pretty clear
description of what needs to change. If someone is signing up to make any of
these( since this was somewhat the original intention of this thread),
please let this thread know. Would be happy to provide further clarification
as needed. It would be nice to finish this in a week. If there are any
concerns about this approach, please voice them :-)

Thanks,
Rana

Re: [website] building VM from the repository instructions

[Rana Dasgupta]

On 6/26/06, Andrey Chernyshev <[EMAIL PROTECTED]> wrote:


>Good suggestion. I'd also mention that there are some docs in the
>DRLVM source tree, e.g. Getting Started [2] and Developer's guide [3]
>which contain many useful info. May be it makes sense to post them on
>a web site as well:



Good idea. Maybe also the Simple DRLVM VM and JIT debugging guide that was
posted in the JIRA, ref [4]

[2]http://svn.apache.org/viewvc/incubator/harmony/enhanced/drlvm/trunk/vm/doc/GettingStarted.htm?view=markup


[3]

http://svn.apache.org/viewvc/incubator/harmony/enhanced/drlvm/trunk/vm/doc/DeveloperGuide.htm?view=markup



  [4]
  URL: http://issues.apache.org/jira/browse/HARMONY-626


Thanks,

Andrey.

>
> [1]
http://incubator.apache.org/harmony/subcomponents/classlibrary/build_classlib.html
>
> --
> Regards,
> Anton Luht,
> Intel Middleware Products Division
>
> -
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

-
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] building VM from the repository instructions

[Alexey Petrenko]

+1
2006/6/26, Andrey Chernyshev <[EMAIL PROTECTED]>:

On 6/26/06, Anton Luht <[EMAIL PROTECTED]> wrote:
> Good day,
>
> Though DRLVM is in the repository already, the classlib building
> instructions [1] still says nothing about it in the section "Obtaining
> a compatible VM" . I coudn't find instructions on building DRLVM on
> the site, either - I found them browsing SVN repository. Maybe it's
> worth to add info about DRLVM to the Harmony site?

Good suggestion. I'd also mention that there are some docs in the
DRLVM source tree, e.g. Getting Started [2] and Developer's guide [3]
which contain many useful info. May be it makes sense to post them on
a web site as well:

[2]http://svn.apache.org/viewvc/incubator/harmony/enhanced/drlvm/trunk/vm/doc/GettingStarted.htm?view=markup

[3]
http://svn.apache.org/viewvc/incubator/harmony/enhanced/drlvm/trunk/vm/doc/DeveloperGuide.htm?view=markup

Thanks,
Andrey.

>
> [1] 
http://incubator.apache.org/harmony/subcomponents/classlibrary/build_classlib.html
>
> --
> Regards,
> Anton Luht,
> Intel Middleware Products Division
>
> -
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





--
Alexey A. Petrenko
Intel Middleware Products Division

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [classlib] mem

[Geir Magnusson Jr]

Tim Ellison wrote:
> Geir Magnusson Jr wrote:
>> Except...
>>
>> 1) They aren't as Jimmy suggests, at least the one's I'm looking at.
>>
>> 2) the implementation in hymem.c just calls malloc()
>>
>> I'm confused.
> 
> Hopefully you are no longer confused after Oliver's explanation.

Yes, although I am still confused why you would want to do this.

We have an implementation in hymem.c :

  hymem_alloc_memory( HyPortLib *, int )

which looks just like

  hymem_alloc_memory(int)

(if you use the right header)

and it calls what might be two radically different things.

Why do we have himem.c?  Should we rename?   Toss?

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: build problems

[Tim Ellison]

Sure you are compiling with the correct version (2.8.0) of Xerces?

Regards,
Tim

Ivan Volosyuk wrote:
> There are a few more problems with classlib compilation using eclipse
> compiler:
> 
> 1. Tools modules ignores property build.compiler which is set in
> make/build-java.xml
> 2. Compilation problem in java/util/Properties.java (using ECJ on jre
> 1.4.x):
> 
>[javac] 1086. ERROR in
> /home/ivan/experiments/harmony/CLASSLIB/modules/luni/src/main/java/java/util/Properties.java
> 
>[javac]  (at line 568)
>[javac] String value = entry.getTextContent();
>[javac]  ^^
>[javac] The method getTextContent() is undefined for the type Element
> 
> There is no other problems, except huge number of ecj compiler warnings.
> -- 
> Ivan
> 
> 
> On 6/22/06, Tim Ellison <[EMAIL PROTECTED]> wrote:
>> Vladimir Ivanov wrote:
>> > Initial size can be reduced, it works fine. So far… Since the number of
>> > files to compile will only grow as time goes.
>> > Isn't it more general solution compile sources by modules (in same VM,
>> > without fork)?
>>
>> That's how I normally work anyway, and as we have snapshots available to
>> compile against people can always bootstrap the module compilation from
>> a previous build.
>>
>> However, we do need to retain the option to rebuild the entire world
>> from scratch, so I expect there will always be a top level build.
>>
>> I'll reduce the footprint options -- please howl if it does not suit.
>>
>> 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]
>>
>>
> 
> 

-- 

Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [classlib] mem

[Geir Magnusson Jr]

Oliver Deakin wrote:
> 
> Also defined in hyport.h is hymem_allocate_memory(param1) (the single param
> function Jimmy was talking about) which is a macro defined to be:
> privatePortLibrary->mem_allocate_memory(privatePortLibrary, param1).

Ah.  Thanks.  I didn't see that.

I'll continue answering tim's followup.

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] building VM from the repository instructions

[Andrey Chernyshev]

On 6/26/06, Anton Luht <[EMAIL PROTECTED]> wrote:

Good day,

Though DRLVM is in the repository already, the classlib building
instructions [1] still says nothing about it in the section "Obtaining
a compatible VM" . I coudn't find instructions on building DRLVM on
the site, either - I found them browsing SVN repository. Maybe it's
worth to add info about DRLVM to the Harmony site?


Good suggestion. I'd also mention that there are some docs in the
DRLVM source tree, e.g. Getting Started [2] and Developer's guide [3]
which contain many useful info. May be it makes sense to post them on
a web site as well:

[2]http://svn.apache.org/viewvc/incubator/harmony/enhanced/drlvm/trunk/vm/doc/GettingStarted.htm?view=markup

[3]
http://svn.apache.org/viewvc/incubator/harmony/enhanced/drlvm/trunk/vm/doc/DeveloperGuide.htm?view=markup

Thanks,
Andrey.



[1] 
http://incubator.apache.org/harmony/subcomponents/classlibrary/build_classlib.html

--
Regards,
Anton Luht,
Intel Middleware Products Division

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
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]hythreads implementation

[Andrey Chernyshev]

On 6/23/06, Tim Ellison <[EMAIL PROTECTED]> wrote:

Marina Goldburt wrote:
> Hi,
>
> I've noticed such a strange thing when examined drlvm building process.
> The drlvm replaces hythreads shared library with its own simple
> implementation based on APR. The drlvm hythreads library exports less
> than 1/2 functions comparing with the original hythr.dll.

Yes, that is strange.  Don't know why DRLVM would replace the classlib's
thread library -- seems a bit impolite ;-)


Sorry about that :)  Actually the issue was that the original hythread
library didn't work with the DRLVM - it required a thread to be
attached to the library because hythread monitors functions didn't
work otherwise. DRLVM has it's own threading code which wasn't
originally  based on the hythread.
Then the DRLVM did a quick solution - provided it's own hythr.dll
which exposes to class libraries only those functions which are really
needed.
I agree it doesn't look too nice, though it helped to make it working
with the classlib quickly.



> I thought the rest of functions are used by J9 VM, but
> replacing hythread classlib implementation with the slightly modified
> drlvm one doesn't lead to problems (all tests passed with j9 vm too).

The IBM VME doesn't use Harmony's thread library (there is a remarkably
similar library in the VM subdir called j9thr23).

And,of course, if other VM's want to use their own thread library they
are free to do so.

> So, the question : Why we have so much code in the hythreads module if
> nobody neads it?

The honest answer is, not all the thread library code is needed by
classlib -- but it forms a comprehensive library for any VM / classlib /
tools development.


If I understand correctly, classlibs are mostly using hythread for
synchronization purposes. Could the class libraries do all the needed
synchronization at the Java level by natural Java means like
synchronized blocks? In this case they won't need extra libraries
except java.lang.Object or java.lang.Thread.
Another advantage could be that Java monitors are well known to Java
debuggers while locating problems with synchronization of the native
code may require additional tools and hence could be more difficult...

Thanks,
Andrey.



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]

Re: [continuum] BUILD FAILURE: Classlib/win.ia32 Build/Test

[Tim Ellison]

Apache Harmony Build wrote:
> Online report : 
> http://ibmonly.hursley.ibm.com/continuum/win.ia32/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/6/buildId/1435
> Build statistics:
>   State: Failed
>   Previous State: Ok
>   Started at: Mon, 26 Jun 2006 16:09:03 +0100
>   Finished at: Mon, 26 Jun 2006 16:22:52 +0100
>   Total time: 13m 48s
>   Build Trigger: Schedule
>   Exit code: 1
>   Building machine hostname: hy1
>   Operating system : Windows XP(Service Pack 2)
>   Java version : 1.5.0_06(Sun Microsystems Inc.)



>  [exec] [junit] T2 not closed
>  [exec] [junit] T1 not closed
>  [exec] [junit] Read fail in capacity64KB, 
> testReadByteBuffer_NonBlocking_ReadWriteRealTooLargeData not finish.
>  [exec] [junit] Tests run: 80, Failures: 1, Errors: 0, Time elapsed: 
> 15.491 sec
>  [exec] [junit] TEST 
> org.apache.harmony.tests.java.nio.channels.SocketChannelTest FAILED
>  [exec] [junit] Tests run: 14, Failures: 0, Errors: 0, Time elapsed: 
> 0.313 sec
>  [exec] [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0 
> sec
>  [exec] [junit] Tests run: 9, Failures: 0, Errors: 0, Time elapsed: 
> 0.126 sec
>  [exec] [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 
> 0.016 sec
>  [exec] [junit] Tests run: 6, Failures: 0, Errors: 0, Time elapsed: 
> 0.094 sec
>  [exec] [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 
> 0.016 sec
>  [exec] [junit] Tests FAILED


This test seems to be frequently, if intermittently, failing.

expected:<7300> but was:<65536>

junit.framework.AssertionFailedError: expected:<7300> but was:<65536> at
org.apache.harmony.tests.java.nio.channels.SocketChannelTest.testReadByteBuffer_NonBlocking_ReadWriteRealTooLargeData(SocketChannelTest.java:2518)
at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:205)



Regards,
Tim

-- 

Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [classlib] Modularising the native code - it begins!

[Oliver Deakin]

Hi all,

Here's another heads up to let you all know how it's going.

As you have probably noticed, I raised HARMONY-628 last week moving
the prefs code into its module. This patch has already been applied to 
SVN head.

Earlier today I raised HARMONY-668 to move the launcher and vmls source
into the luni module.

Just in case anyone was wondering, the ordering of the native code I am
moving isn't (entirely) random. I'm working my way through the targets
in native-src//makefile in the reverse order they need to be 
built.

This provides me with gradual steps where I know all dependencies
will be built by the time my changes are reached.

I plan to move text, archive and auth next (into the text, archive and 
auth modules,
respectively and somewhat unsurprisingly!). I will post again if I hit 
any problems.


Regards,
Oliver


Oliver Deakin wrote:

Hi all,

As you have probably noticed, I recently raised HARMONY-596
(which Mark has already kindly applied) to make .lib and .a files 
generate

straight into the deploy/lib directory.

I think that now we are in a position to finally modularise the 
classlib native
code. I've volunteered to do this, and plan to move the code down into 
the

modules in the layout described in [1], since I believe there were no
objections.

I will probably warm up with some of the "easier" modules - 
prefs/text/auth

- before moving onto archive and luni. Ill raise a separate JIRA for each
set of moves, and let you all know how I progress and if there are any
problems/questions I have.

I also plan to create a doc for the website describing the location of 
the native

code, and summarising how platform specific and shared code is laid out
within each native component.

Please let me know if there are any issues with this - otherwise I will
continue to work on it and submit patches.

Regards,
Oliver

[1] 
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200605.mbox/[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: svn commit: r417205 - in /incubator/harmony/enhanced/classlib/trunk: modules/luni/src/main/java/java/io/ modules/luni/src/main/java/org/apache/harmony/luni/platform/ native-src/linux.IA32/luni/ na

[Tim Ellison]

Thanks Gregory, fixed in r417222.

(and left wondering why it didn't fail for me?)

Regards,
Tim

Gregory Shimansky wrote:
> Hello Tim
> 
> You've forgot semicolons at the end of lines so linker on Linux complains
> about syntax error in version script.
> 
> 2006/6/26, [EMAIL PROTECTED] <[EMAIL PROTECTED]>:
> 
>> Modified:
>> incubator/harmony/enhanced/classlib/trunk/native-src/linux.IA32/luni/libhyluni.exp
>>
>> URL:
>> http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/native-src/linux.IA32/luni/libhyluni.exp?rev=417205&r1=417204&r2=417205&view=diff
>>
>>
>> ==
>>
>> ---
>> incubator/harmony/enhanced/classlib/trunk/native-src/linux.IA32/luni/libhyluni.exp
>>
>> (original)
>> +++
>> incubator/harmony/enhanced/classlib/trunk/native-src/linux.IA32/luni/libhyluni.exp
>>
>> Mon Jun 26 08:05:49 2006
>> @@ -150,6 +150,8 @@
>>
>>
>> Java_org_apache_harmony_luni_platform_OSFileSystem_lockImpl;
>>
>>
>> Java_org_apache_harmony_luni_platform_OSFileSystem_unlockImpl;
>>
>>
>> Java_org_apache_harmony_luni_platform_OSFileSystem_transferImpl;
>> +
>> Java_org_apache_harmony_luni_platform_OSFileSystem_ttyAvailableImpl
>> +
>> Java_org_apache_harmony_luni_platform_OSFileSystem_ttyReadImpl
>>
>>
>> Java_org_apache_harmony_luni_platform_OSMemory_isLoadedImpl;
>> Java_org_apache_harmony_luni_platform_OSMemory_loadImpl;
>> Java_org_apache_harmony_luni_platform_OSMemory_mmapImpl;
>>
> 
> 

-- 

Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: svn commit: r416738 - /incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/init/bootclasspath.properties

[Tim Ellison]

Ivan Volosyuk wrote:
> Tim,
> 
> I am talking about the version of eclipse compiler from eclipse
> downloaded by drlvm build. It works on jre1.4, but it refuses to
> accept -target jsr14 and -source 1.5 if running on jre1.4.
> The eclipse compiler downloaded by classlib (ecj_*) works fine with
> this settings.

Not sure what version you are getting, but support for that combination
of flags was quite recently added.

Regards,
Tim

> -- 
> Best regards,
> Ivan
> 
> On 6/26/06, Tim Ellison <[EMAIL PROTECTED]> wrote:
>> Ivan Volosyuk wrote:
>> > I have found solution for this build problem. If somebody interested:
>> >
>> > To use downloaded eclipse (or its compiler) need to run:
>> > sh build.sh -Dbuild.compiler=org.eclipse.jdt.core.JDTCompilerAdapter
>> >
>> > But the compiler in theis eclipse version doesn't work with jre1.4, so
>>
>> Not quite sure what this means, since all the Eclipse code only requires
>> JRE1.4.
>>
>> Regards,
>> Tim
>>
>> > I need to change build.sh, removing:
>> >  CLASSPATH=$CLASSPATH:`pwd`/make/tmp/org.eclipse.jdt.core_3.1.1.jar
>> > and changing:
>> >  CLASSPATH=`pwd`/make/tmp/cpptasks/cpptasks.jar:$CLASSPATH
>> > in order to use CLASSPATH specified in command line environment. I
>> > used ecj_3.2RC5 from classlib. After this, compilation works fine.
>> >
>> > I run eclipse with the compiled drlvm and it started fine, except for
>> > the message:
> 
> -
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 

-- 

Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [classlib] mem

[Tim Ellison]

Geir Magnusson Jr wrote:
> 
> Tim Ellison wrote:
>> Jimmy, Jing Lv wrote:
>>> Geir Magnusson Jr wrote:
 Why would I use

 portLib->mem_allocate_memory(portLib)

 over just calling

 hymem_allocate_memory(portlib, )

>>> Hi Geir:
>>>
>>>Not sure if the later is "hymem_allocate_memory(int size)"? If so,
>>> they are the same indeed, and the later is the a macro. Everytime before
>>> we use the macro, call "PORT_ACCESS_FROM_ENV (env)"
>>>e.g.:
>>>somemethod(JNIEnv * env, ...){
>>> PORT_ACCESS_FROM_ENV (env);
>>> ...
>>> hymem_allocate_memory(sizeof(something));
>>> ...
>>>}
>>>
>>>And they are defined in hyport.h. :)
>> I think the second style is more readable, so would advocate using that.
>>
>> As you say, the readable macros are set up using the PORT_ACCESS_FROM_*
>> directives, so that you can use them if you are passed different types.
>>
>> PORT_ACCESS_FROM_ENV(JNIEnv)  - you have a JNIEnv struct ptr
>> PORT_ACCESS_FROM_JAVAVM(JavaVM)   - you have a JavaVM struct ptr
>> PORT_ACCESS_FROM_PORT(portlib)- you have a portlib ptr
> 
> Except...
> 
> 1) They aren't as Jimmy suggests, at least the one's I'm looking at.
> 
> 2) the implementation in hymem.c just calls malloc()
> 
> I'm confused.

Hopefully you are no longer confused after Oliver's explanation.

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: [SableVM] please tell us when it will be donated to Harmony project

[Tim Ellison]

I'll let Etienne speak for himself of course, but my understanding was
that SableVM will stay where it is.  Code (maybe a specific version) was
licensed as ALv2 to enable the free interop referred to below.

You also may get more notice on the sablevm-devel list.

Regards,
Tim

Weldon Washburn wrote:
> Etienne,
> 
> Please tell us when the below will be official.  This will help with
> mixing/matching the various VM pieces.
> 
>  Thanks
> Weldon
> 
>> From http://sablevm.org/lists/sablevm-devel/2006-March/000608.html:
> 
>> I think that it would be in the best interest of the SableVM project to
>> participate to the Harmony project by adding our virtual machine body of
>> code to the pool of existing Harmony code, so that it could be mixed and
>> matched with the code of other virtual machines to create something
>> bigger than all its parts.
> 
> 

-- 

Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: svn commit: r417205 - in /incubator/harmony/enhanced/classlib/trunk: modules/luni/src/main/java/java/io/ modules/luni/src/main/java/org/apache/harmony/luni/platform/ native-src/linux.IA32/luni/ na

[Gregory Shimansky]

Hello Tim

You've forgot semicolons at the end of lines so linker on Linux complains
about syntax error in version script.

2006/6/26, [EMAIL PROTECTED] <[EMAIL PROTECTED]>:


Modified:
incubator/harmony/enhanced/classlib/trunk/native-src/linux.IA32/luni/libhyluni.exp
URL:
http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/native-src/linux.IA32/luni/libhyluni.exp?rev=417205&r1=417204&r2=417205&view=diff

==
---
incubator/harmony/enhanced/classlib/trunk/native-src/linux.IA32/luni/libhyluni.exp
(original)
+++
incubator/harmony/enhanced/classlib/trunk/native-src/linux.IA32/luni/libhyluni.exp
Mon Jun 26 08:05:49 2006
@@ -150,6 +150,8 @@

Java_org_apache_harmony_luni_platform_OSFileSystem_lockImpl;

Java_org_apache_harmony_luni_platform_OSFileSystem_unlockImpl;

Java_org_apache_harmony_luni_platform_OSFileSystem_transferImpl;
+
Java_org_apache_harmony_luni_platform_OSFileSystem_ttyAvailableImpl
+
Java_org_apache_harmony_luni_platform_OSFileSystem_ttyReadImpl

Java_org_apache_harmony_luni_platform_OSMemory_isLoadedImpl;
Java_org_apache_harmony_luni_platform_OSMemory_loadImpl;
Java_org_apache_harmony_luni_platform_OSMemory_mmapImpl;




--
Gregory Shimansky, Intel Middleware Products Division

[drlvm] build fails on Windows os

[Marina Goldburt]

Hi,

I've caught the following error when tried to build the drlvm today on
Windows OS:



  [cc] 0 total files to be compiled.

  [cc] Starting link

  [cc]Creating library vmcore.lib and object vmcore.exp

  [cc] aprutil-1.lib(apr_xml.obj) : error LNK2019: unresolved external
symb

ol _XML_SetCharacterDataHandler referenced in function
[EMAIL PROTECTED]

  [cc] aprutil-1.lib(apr_xml.obj) : error LNK2019: unresolved external
symb

ol _XML_SetElementHandler referenced in function [EMAIL PROTECTED]

  [cc] aprutil-1.lib(apr_xml.obj) : error LNK2019: unresolved external
symb

ol _XML_SetUserData referenced in function [EMAIL PROTECTED]

  [cc] aprutil-1.lib(apr_xml.obj) : error LNK2019: unresolved external
symb

ol _XML_ParserCreate referenced in function [EMAIL PROTECTED]

  [cc] aprutil-1.lib(apr_xml.obj) : error LNK2019: unresolved external
symb

ol _XML_ParserFree referenced in function _cleanup_parser

  [cc] aprutil-1.lib(apr_xml.obj) : error LNK2019: unresolved external
symb

ol _XML_GetErrorCode referenced in function _do_parse

  [cc] aprutil-1.lib(apr_xml.obj) : error LNK2019: unresolved external
symb

ol _XML_Parse referenced in function _do_parse

  [cc] aprutil-1.lib(apr_xml.obj) : error LNK2019: unresolved external
symb

ol _XML_ErrorString referenced in function [EMAIL PROTECTED]

  [cc] vmcore.dll : fatal error LNK1120: 8 unresolved externals



Adding compilation of xml/expat/lib/xmlparse.c xmlrole.c xmltok.c to
aprutil.lib fixed the problem.

Jira issue with the suggested fix :
http://issues.apache.org/jira/browse/HARMONY-669



Marina

Re: [drlvm]ij.bat on Windows....

[Alexey Petrenko]

2006/6/26, Ivan Volosyuk <[EMAIL PROTECTED]>:

Imho, the purpose was to have a runner script

And what's the purpose of runner script?


Linux. We can remove it. Patch is welcome :)

Guys, can somebody (with the access rights) remove this file?
Or it's better to open JIRA issue?


On 6/26/06, Alexey Petrenko <[EMAIL PROTECTED]> wrote:
> Guys,
>
> Does anybody know why drlvm has ij.bat in its bin directory?
> This ij.bat calls .\ij.exe. It means that you can not run something
> like "c:\work\drlvm\bin\ij" because ij.bat will not find ij.exe in
> this case.
>
> The workaround is obvious but why do we need it?
>
> SY, Alexey
>
> --
> Alexey A. Petrenko
> Intel Middleware Products Division

--
Ivan
Intel Middleware Products Division

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





--
Alexey A. Petrenko
Intel Middleware Products Division

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [drlvm]ij.bat on Windows....

[Ivan Volosyuk]

Imho, the purpose was to have a runner script, just like ij.sh for
Linux. We can remove it. Patch is welcome :)
--
Ivan

On 6/26/06, Alexey Petrenko <[EMAIL PROTECTED]> wrote:

Guys,

Does anybody know why drlvm has ij.bat in its bin directory?
This ij.bat calls .\ij.exe. It means that you can not run something
like "c:\work\drlvm\bin\ij" because ij.bat will not find ij.exe in
this case.

The workaround is obvious but why do we need it?

SY, Alexey

--
Alexey A. Petrenko
Intel Middleware Products Division


--
Ivan
Intel Middleware Products Division

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [DRLVM] Integration checks (was building from svn on FC5)

[Salikh Zakirov]

Alexey Petrenko wrote:
> Some checks before commits are defenetly good...
> 
> 2006/6/23, Andrey Chernyshev <[EMAIL PROTECTED]>:
>> We may probably also need to define the list of
>> platforms/configurations covered by this procedure.
> I'm not sure that I get your idea correctly.
> Do you suggest to ask every developer to make some checks on different
> platforms and software configurations?
> If so... Yes, it is good for product stability.
> But it will be nearly impossible because very small number of
> developers have access to different platforms and software
> configurations...

First and foremost question is *what* to run as integration tests,
rather than on what platforms. I think we need to define what use cases
we care for in the form of integration tests. 
The more conveniently the integration tests are packaged, the higher is the 
probability of anyone running them.
The good example is the "smoke tests" included with DRLVM: they can be built 
and run
with a single command 'build.bat test' ('build.sh test' on Linux).

Once the integration test set is defined, we can think of platform coverage.
BuildBot [1] could be the way to interested parties to contribute CPU cycles
to verify Harmony quality.

[1] http://buildbot.sourceforge.net/

-
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] ant test fail

[Mark Hindess]

On 26 June 2006 at 22:51, Richard Liang <[EMAIL PROTECTED]> wrote:
> --090101060803000509020200
> Thanks a lot, Geir.
> 
> I do copy junit.jar to my ant/lib, but notice there is no ant-junit.jar 
> in the directory. Just wondering why my Ubuntu does not install a 
> full-version of ant. ;-)

Debian has an "ant-optional" package.  (IIRC, it is split from the ant
package to reduce the interdependencies when the building packages.  The
"ant-optional" package is in the "Recommends" list for "ant" so install
tools like aptitude should [offer to] install it when you install ant.)

-Mark.

> Geir Magnusson Jr wrote:
> > is junit.jar in your ant/lib directory?
> >
> > geir
> >
> >
> > Richard Liang wrote:
> >   
> >> Hello,
> >>
> >> When I try to run all tests of the classlib, the following errors occur.
> >> It's about junit, I think I should not be required for additional
> >> configuration, or do I miss something? ;-)
> >>
> >> [EMAIL PROTECTED]:~/harmony/trunk$ ant test
> >> Buildfile: build.xml
> >>
> >> test:
> >> [echo]
> >> [echo] 
> >> [echo] Testing class libraries...
> >> [echo] 
> >>
> >> clean:
> >>   [delete] Deleting directory /home/liangyx/harmony/trunk/build/test_repor
> t
> >>
> >> copy-test-resources:
> >>
> >> check-support-jars:
> >>
> >> check:
> >> [echo] Checking for depends/jars/xalan-j_2.7.0/xalan.jar
> >> [echo] Checking for depends/jars/xerces_2.8.0/resolver.jar
> >> [echo] Checking for depends/jars/xerces_2.8.0/xercesImpl.jar
> >> [echo] Checking for depends/jars/xerces_2.8.0/xml-apis.jar
> >> [echo] Checking for depends/jars/junit_3.8.2/junit.jar
> >> [echo] Checking for depends/jars/bcprov-jdk14-133/signed.bcprov.jar
> >> [echo] Checking for depends/jars/icu4j_3.4.4/icu4j_3_4_4.jar
> >> [echo] Checking for depends/jars/mx4j_3.0.1/mx4j.jar
> >> [echo] Checking for depends/jars/mx4j_3.0.1/mx4j-remote.jar
> >> [echo] Checking for depends/jars/ecj_3.2MAINT/ecj_3.2MAINT.jar
> >>
> >> create-unsigned-bcprov-jar:
> >>
> >> check-win:
> >>
> >> compile-support:
> >>
> >> test-modules:
> >>
> >> call-modules-all:
> >>
> >> compile.java:
> >> [echo] Compiling ACCESSIBILITY classes
> >>
> >> build.jar:
> >>
> >> build:
> >>
> >> compile.tests:
> >> [echo] Compiling ACCESSIBILITY tests
> >>
> >> run.tests:
> >>[mkdir] Created dir: /home/liangyx/harmony/trunk/build/test_report
> >>
> >> BUILD FAILED
> >> /home/liangyx/harmony/trunk/build.xml:105: The following error occurred
> >> while executing this line:
> >> /home/liangyx/harmony/trunk/make/build-test.xml:48: The following error
> >> occurred while executing this line:
> >> /home/liangyx/harmony/trunk/make/properties.xml:176: The following error
> >> occurred while executing this line:
> >> /home/liangyx/harmony/trunk/make/properties.xml:186: The following error
> >> occurred while executing this line:
> >> /home/liangyx/harmony/trunk/modules/accessibility/build.xml:110: Could
> >> not create task or type of type: junit.
> >>
> >> 
> >
> > -
> > 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 
> 
> 
> --090101060803000509020200--





-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: svn commit: r416738 - /incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/init/bootclasspath.properties

[Ivan Volosyuk]

Tim,

I am talking about the version of eclipse compiler from eclipse
downloaded by drlvm build. It works on jre1.4, but it refuses to
accept -target jsr14 and -source 1.5 if running on jre1.4.
The eclipse compiler downloaded by classlib (ecj_*) works fine with
this settings.
--
Best regards,
Ivan

On 6/26/06, Tim Ellison <[EMAIL PROTECTED]> wrote:

Ivan Volosyuk wrote:
> I have found solution for this build problem. If somebody interested:
>
> To use downloaded eclipse (or its compiler) need to run:
> sh build.sh -Dbuild.compiler=org.eclipse.jdt.core.JDTCompilerAdapter
>
> But the compiler in theis eclipse version doesn't work with jre1.4, so

Not quite sure what this means, since all the Eclipse code only requires
JRE1.4.

Regards,
Tim

> I need to change build.sh, removing:
>  CLASSPATH=$CLASSPATH:`pwd`/make/tmp/org.eclipse.jdt.core_3.1.1.jar
> and changing:
>  CLASSPATH=`pwd`/make/tmp/cpptasks/cpptasks.jar:$CLASSPATH
> in order to use CLASSPATH specified in command line environment. I
> used ecj_3.2RC5 from classlib. After this, compilation works fine.
>
> I run eclipse with the compiled drlvm and it started fine, except for
> the message:


-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [classlib] mem

[Oliver Deakin]

Geir Magnusson Jr wrote:

Jimmy, Jing Lv wrote:
  

Geir Magnusson Jr wrote:


Why would I use

portLib->mem_allocate_memory(portLib)

over just calling

hymem_allocate_memory(portlib, )

  

Hi Geir:

   Not sure if the later is "hymem_allocate_memory(int size)"? 



Well, the one I'm looking at is

hymem.c

void *VMCALL
hymem_allocate_memory (struct HyPortLibrary *portLibrary,
UDATA byteAmount)


If so,
  

they are the same indeed, and the later is the a macro. Everytime before
we use the macro, call "PORT_ACCESS_FROM_ENV (env)"
   e.g.:
   somemethod(JNIEnv * env, ...){
PORT_ACCESS_FROM_ENV (env);
...
hymem_allocate_memory(sizeof(something));
...
   }

   And they are defined in hyport.h. :)



I've heard this rumor before, but I don't ever see how.
PORT_ACCESS_FROM_* is a simple little macro that just returns *portLib.
  


yeah, that's right - the PORT_ACCESS_FROM_* macro (defined
in hyport.h) sets the pointer privatePortLibrary to address the relevant 
port library.


Also defined in hyport.h is hymem_allocate_memory(param1) (the single param
function Jimmy was talking about) which is a macro defined to be:
privatePortLibrary->mem_allocate_memory(privatePortLibrary, param1).

So the call to PORT_ACCESS_FROM_* sets up a port library pointer, and the
macro versions of the hymem calls automatically add it in as the first 
parameter

to the relevant function call.

Regards,
Oliver


geir

  

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]


  


--
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]hythreads implementation

[Marina Goldburt]

Hi,

On 6/23/06, Tim Ellison <[EMAIL PROTECTED]> wrote:


The IBM VME doesn't use Harmony's thread library (there is a remarkably
similar library in the VM subdir called j9thr23).

And,of course, if other VM's want to use their own thread library they
are free to do so.



And if the both VM use their own thread library, maybe it's more correctly
to let the library be a part of VM, not classlib?


So, the question : Why we have so much code in the hythreads module if
> nobody neads it?

The honest answer is, not all the thread library code is needed by
classlib -- but it forms a comprehensive library for any VM / classlib /
tools development.



Actually, I'm interested in porting classlib to em64t platform and the
hythread library is the most compex part to port. And if the library isn't
used, I'm confused how can I port and test it?

Marina

Regards,

Tim

--

Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [classlib] ant test fail

[Richard Liang]

Thanks a lot, Geir.

I do copy junit.jar to my ant/lib, but notice there is no ant-junit.jar 
in the directory. Just wondering why my Ubuntu does not install a 
full-version of ant. ;-)


Geir Magnusson Jr wrote:

is junit.jar in your ant/lib directory?

geir


Richard Liang wrote:
  

Hello,

When I try to run all tests of the classlib, the following errors occur.
It's about junit, I think I should not be required for additional
configuration, or do I miss something? ;-)

[EMAIL PROTECTED]:~/harmony/trunk$ ant test
Buildfile: build.xml

test:
[echo]
[echo] 
[echo] Testing class libraries...
[echo] 

clean:
  [delete] Deleting directory /home/liangyx/harmony/trunk/build/test_report

copy-test-resources:

check-support-jars:

check:
[echo] Checking for depends/jars/xalan-j_2.7.0/xalan.jar
[echo] Checking for depends/jars/xerces_2.8.0/resolver.jar
[echo] Checking for depends/jars/xerces_2.8.0/xercesImpl.jar
[echo] Checking for depends/jars/xerces_2.8.0/xml-apis.jar
[echo] Checking for depends/jars/junit_3.8.2/junit.jar
[echo] Checking for depends/jars/bcprov-jdk14-133/signed.bcprov.jar
[echo] Checking for depends/jars/icu4j_3.4.4/icu4j_3_4_4.jar
[echo] Checking for depends/jars/mx4j_3.0.1/mx4j.jar
[echo] Checking for depends/jars/mx4j_3.0.1/mx4j-remote.jar
[echo] Checking for depends/jars/ecj_3.2MAINT/ecj_3.2MAINT.jar

create-unsigned-bcprov-jar:

check-win:

compile-support:

test-modules:

call-modules-all:

compile.java:
[echo] Compiling ACCESSIBILITY classes

build.jar:

build:

compile.tests:
[echo] Compiling ACCESSIBILITY tests

run.tests:
   [mkdir] Created dir: /home/liangyx/harmony/trunk/build/test_report

BUILD FAILED
/home/liangyx/harmony/trunk/build.xml:105: The following error occurred
while executing this line:
/home/liangyx/harmony/trunk/make/build-test.xml:48: The following error
occurred while executing this line:
/home/liangyx/harmony/trunk/make/properties.xml:176: The following error
occurred while executing this line:
/home/liangyx/harmony/trunk/make/properties.xml:186: The following error
occurred while executing this line:
/home/liangyx/harmony/trunk/modules/accessibility/build.xml:110: Could
not create task or type of type: junit.




-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


  


--
Richard Liang
China Software Development Lab, IBM 

Re: svn commit: r416738 - /incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/init/bootclasspath.properties

[Mark Hindess]

On 26 June 2006 at 15:06, "Alexey Petrenko" <[EMAIL PROTECTED]> wrote:
>
> Mark,
> 
> have you tried to run ij after your fix?

Of course.

> I still can not run it... I got "unknown constant type in classfile"
> error with "Hello, World!" application...

This sounds like a compiler 'jsr14' issue.  Are you using the Eclipse
compiler?  You have to use one of the recent 3.2 release candidates
for jsr14 to work.  Otherwise it fails (but doesn't die) and builds
1.5 class files instead.

Regards,
 Mark.

> 2006/6/24, Alexey Petrenko <[EMAIL PROTECTED]>:
> > Right, agreed.
> >
> > Thanks again for the fast fix.
> > I'll check it on monday... I'm playing with prebuilt jpeg and png
> > libraries found in the net... :)
> >
> > SY, Alexey
> >
> > 2006/6/24, Mark Hindess <[EMAIL PROTECTED]>:
> > >
> > > On 23 June 2006 at 23:43, "Alexey Petrenko" <[EMAIL PROTECTED]>
>  wrote:
> > > > Mark,
> > > >
> > > > thanks for the fast fix.
> > > >
> > > > But probably Tim was right and we should not fix properties file but
> > > > should fix drlvm to work inside classlib deploy directory?
> > >
> > > Indeed.  See my comment in the JIRA HARMONY-651.  I would have used
> > > the version from classlib, but there is an outstanding issue with
> > > serializer.jar - which drlvm current adds to jre/lib/boot but classlib
> > > does not.
> > >
> > > As I suggested in an earlier message (subject Re: [drlvm] Doing the
> > > minimum to support Java 5 classfiles) I think drlvm's deploy tree
> > > shouldn't contain any classlib files but should produce a deploy tree
> > > that a top-level build can combine with a classlib tree to produce a
> > > fully working deploy tree.  Much like we do manually when we combine the
> > > IBM VME and classlib.
> > >
> > > That is, we should do more to reduce the coupling between drlvm and
> > > classlib.  At the moment, drlvm is trying to understand classlib - i.e.
> > > knowing what to copy across but it is not going to be maintainable.
> > > (And arguably it is already failing because it is not copying the jre/
> > > lib/ext/bcprov.jar that classlib uses - instead drlvm puts an older
> > > version in jre/lib/boot.  This is just confusing we should stop trying
> > > to do it in drlvm and delegate this task to the top-level build.)
> > >
> > > > Gregory?
> > >
> > > I'd like to know what Gregory thinks about this too.
> > >
> > > Regards,
> > >  Mark.
> > >
> > > > 2006/6/23, Mark Hindess <[EMAIL PROTECTED]>:
> > > > >
> > > > > On 23 June 2006 at 22:37, Gregory Shimansky <[EMAIL PROTECTED]> wr
> ote:
> > > > > > Hello Mark
> > > > > >
> > > > > > While resolving conflict between your and mine changes to this file
> > > > > > I've found that you didn't include awt.jar. Should it be added
> > > > > > perhaps?
> > > > >
> > > > > Yes.  Fixed in r416804 (and I've fixed the reason why it was missing
> > > > > from my build).
> > > > >
> > > > > -Mark.
> > > > >
> > > > > > On Friday 23 June 2006 19:22 [EMAIL PROTECTED] wrote:
> > > > > > > Author: hindessm
> > > > > > > Date: Fri Jun 23 08:22:20 2006
> > > > > > > New Revision: 416738
> > > > > > >
> > > > > > > URL: http://svn.apache.org/viewvc?rev=416738&view=rev
> > > > > > > Log:
> > > > > > > Fixed to point to all jars (or at least a version of all jars).
> > > > > > >
> > > > > > > Modified:
> > > > > > >
> > > > > > > incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/init/bootcla
> sspath
> > > > .pro
> > > > > > >perties
> > > > > > >
> > > > > > > Modified:
> > > > > > > incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/init/bootcla
> sspath
> > > > .pro
> > > > > > >perties URL:
> > > > > > > http://svn.apache.org/viewvc/incubator/harmony/enhanced/drlvm/tru
> nk/vm/
> > > > vmco
> > > > > > >re/src/init/bootclasspath.properties?rev=416738&r1=416737&r2=41673
> 8&view
> > > > =dif
> > > > > > >f
> > > > > > > =
> ==
> > > > 
> > > > > > >=== ---
> > > > > > > incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/init/bootcla
> sspath
> > > > .pro
> > > > > > >perties (original) +++
> > > > > > > incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/init/bootcla
> sspath
> > > > .pro
> > > > > > >perties Fri Jun 23 08:22:20 2006 @@ -38,46 +38,68 @@
> > > > > > >  # unspecified then the source is deemed to be available rooted a
> t '/'.
> > > > > > >  # Packageroots given with no source location are ignored.
> > > > > > >
> > > > > > > -bootclasspath.1=archive.jar
> > > > > > > +bootclasspath.1=accessibility.jar
> > > > > > >
> > > > > > > -bootclasspath.2=bcprov-jdk14-129.jar
> > > > > > > +bootclasspath.2=annotation.jar
> > > > > > >
> > > > > > > -bootclasspath.3=beans.jar
> > > > > > > +bootclasspath.3=applet.jar
> > > > > > >
> > > > > > > -bootclasspath.4=crypto.jar
> > > > > > > +bootclasspath.4=archive.jar
> > > > > > >
> > > > > > > -bootclasspath.5=icu4j_3_4.jar
> > > > > > > +bootclasspath.5=auth.jar
> > > > > > >
> > > > > > > -bootclasspath.6=icu4jni-3.4.jar
> > > >

Re: [DRLVM] Integration checks (was building from svn on FC5)

[Salikh Zakirov]

Anton Luht wrote:
> As far as I understand Andrey, he suggests to run tests when a piece
> of code is integrated into the code base, by the person who has access
> to the repository (committer). A developer shouldn't test his piece of
> code on any platform, though it'd be good if he did it and reported
> results in the JIRA issue.
> 
> I don't know if running tests for hours is suitable for integration
> check, if so, I can suggest using Eclipse automated tests  (can be
> found in download section for each Eclipse release). Total amount of
> tests is > 1 . They test Eclipse functionality quite deeply. Note:
> they'll fail without GUI.

IMHO, For integration testing it would be enough to run just one test
that verify that the change is not breaking major use case.

Running Eclipse for Java development is one of the major targets of DRLVM 
development,
so it would be very convenient to have just *one* Eclipse unit test,
that would model basic Eclipse workflow:
* create project
* inject java code
* compile java code
* (maybe) debug java code: set breakpoints, run the program, inquire variable 
state, etc.

To make this usable for DRLVM committers, the unit test needs to be readily
available, for example, .jar file committed directly to depends/ or downloadable
from some external source. Its download can be handled in exactly the same
way as other dependencies are downloaded by 'ant fetch-depends'.

As a final result, the committer will be able to run a *single* command,
that will verify that changes in the DRLVM do not break Eclipse use case.

Does this make sense?

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [classlib] Merging frameworks for testing serialization - first step

[Stepan Mishura]

On 6/26/06, Tim Ellison wrote:


Stepan Mishura wrote:
> On 6/26/06, Tim Ellison wrote:
>>
>> Stepan Mishura wrote:
>> > Hi,
>> >
>> > I've updated framework for testing serialization page[1] - I added
>> > guidelines
>> > for developing serialization tests. Also I've removed confusing
>> 'TestCase'
>> > parameter in SerializationTest.verifySelf() methods.
>> >
>> > If there are no objections I'm going in next two days to move
>> > SerializationTest.java from 'security' module to support folder. So
new
>> > location will be:
>> > support/src/test/java/org/apache/harmony/testframework/serialization
>> > folder.
>> > Class name won't change.
>> >
>> > Thoughts?
>>
>> Looks good, just a couple of minor comments:
>>
>> - You might as well move them (or duplicate them) to an
>> org.apache.harmony. package while you are moving things around, since
we
>> want to get rid of tests.util as a package name.
>
> 'Them' means tests, right?

Sorry, I actually meant the testing framework itself.  The doc says

   "The testing framework provides support class
tests.util.SerializationTest  for serialization testing."

I figured it would be easier to put them in the right place.



Ops..., sorry. I thought about replacing SerializationTester and
accidentally put its package name. It should say:
" The testing framework provides support class
org.apache.harmony.testframework.serialization.SerializationTest for
serialization testing."

I fixed the doc in r417196. Looks better now? :-)


- Please will you ensure that the Manifests are updated accordingly so
>> that the world is not broken.
>
>
> Sure, I will try.
>
> - Not sure about the word 'golden' to mean 'reference' data, when we
>> could just use reference, but whatever.
>
> In the method names or resource file name? Or both?

Ideally both, it just seems like jargon -- but I realize that such
renaming doesn't really 'advance the cause', so whatever you think.



I'm OK with 'reference' and currently 'golden' can be easily replaced with
it. Otherwise after we rename everything it will be not so simple.

Thanks,
Stepan.

Regards,

Tim

>> >
>> > [1]
>> >
>>
http://incubator.apache.org/harmony/subcomponents/classlibrary/ser_testing.html
>>
>> >
>> >
>> > On 6/20/06, Stepan Mishura  wrote:
>> >>
>> >>  Hi,
>> >>
>> >> I'm going to start merging existing frameworks for testing
>> serialization.
>> >>
>> >> As first step I've updated 'security' framework. The updated
framework
>> >> searches and loads resource files according [1] and eliminates
>> >> requirement
>> >> to extend SerializationTest. Also to provide smooth frameworks
merging
>> >> I've
>> >> put stub to let the framework search resources in the 'old' way (
i.e.
>> >> via
>> >> "RESOURCE_DIR" system property). The stub will be removed after
>> >> completing
>> >> the merge.
>> >>
>> >> The updated framework suggests the following way for testing
>> >> serialization:
>> >>
>> >> a) Compatibility – 4 new static methods are introduced.
>> >> verifyGolden(TestCase, Object)
>> >> verifyGolden(TestCase, Object, SerializableAssert)
>> >> verifyGolden(TestCase, Object[])
>> >> verifyGolden(TestCase, Object[], SerializableAssert)
>> >>
>> >> A test should invoke one of above methods, for example,
>> >> public void testCompatibility() throws Exception {
>> >> SerializationTest.verifyGolden(this, new SomeSerializableClass
>> ());
>> >> }
>> >>
>> >> b) Self-testing: the same as for compatibility – there are 4 new
>> static
>> >> methods that should be invoked from a test:
>> >> verifySelf(TestCase, Object)
>> >> verifySelf(Object, SerializableAssert)
>> >> verifySelf(TestCase, Object[])
>> >> verifySelf(Object[], SerializableAssert)
>> >>
>> >> For example,
>> >> public void testSelf() throws Exception {
>> >> SerializationTest.verifySelf(new SomeSerializableClass(), new
>> >> MyComparator());
>> >> }
>> >>
>> >> To complete frameworks merging I'd like to suggest the next steps:
>> >> 2) Reviewing the update and the suggested way for testing
>> >> serialization by
>> >> the community. Please let me know if it is acceptable and what can
be
>> >> improved.
>> >> 3) Replace SerializationTester class with SerializationTest. I'm
going
>> to
>> >> add more stubs to let existing tests work in the 'old' way.
>> >> 4) Adjusting existing serialization tests (moving and renaming
>> resource
>> >> files, replacing stubs invocation with new methods)
>> >> 5) Removing stubs.
>> >>
>> >> Thanks,
>> >> Stepan Mishura
>> >> Intel Middleware Products Division
>> >>
>> >> [1]
>> >>
>>
http://incubator.apache.org/harmony/subcomponents/classlibrary/ser_testing.html
>>



--
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[SableVM] please tell us when it will be donated to Harmony project

[Weldon Washburn]

Etienne,

Please tell us when the below will be official.  This will help with
mixing/matching the various VM pieces.

 Thanks
Weldon


From http://sablevm.org/lists/sablevm-devel/2006-March/000608.html:



I think that it would be in the best interest of the SableVM project to
participate to the Harmony project by adding our virtual machine body of
code to the pool of existing Harmony code, so that it could be mixed and
matched with the code of other virtual machines to create something
bigger than all its parts.



--
Weldon Washburn
Intel Middleware Products Division

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [classlib] mem

[Geir Magnusson Jr]

Tim Ellison wrote:
> Jimmy, Jing Lv wrote:
>> Geir Magnusson Jr wrote:
>>> Why would I use
>>>
>>> portLib->mem_allocate_memory(portLib)
>>>
>>> over just calling
>>>
>>> hymem_allocate_memory(portlib, )
>>>
>> Hi Geir:
>>
>>Not sure if the later is "hymem_allocate_memory(int size)"? If so,
>> they are the same indeed, and the later is the a macro. Everytime before
>> we use the macro, call "PORT_ACCESS_FROM_ENV (env)"
>>e.g.:
>>somemethod(JNIEnv * env, ...){
>> PORT_ACCESS_FROM_ENV (env);
>> ...
>> hymem_allocate_memory(sizeof(something));
>> ...
>>}
>>
>>And they are defined in hyport.h. :)
> 
> I think the second style is more readable, so would advocate using that.
> 
> As you say, the readable macros are set up using the PORT_ACCESS_FROM_*
> directives, so that you can use them if you are passed different types.
> 
> PORT_ACCESS_FROM_ENV(JNIEnv)  - you have a JNIEnv struct ptr
> PORT_ACCESS_FROM_JAVAVM(JavaVM)   - you have a JavaVM struct ptr
> PORT_ACCESS_FROM_PORT(portlib)- you have a portlib ptr

Except...

1) They aren't as Jimmy suggests, at least the one's I'm looking at.

2) the implementation in hymem.c just calls malloc()

I'm confused.

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] mem

[Geir Magnusson Jr]

Jimmy, Jing Lv wrote:
> Geir Magnusson Jr wrote:
>> Why would I use
>>
>> portLib->mem_allocate_memory(portLib)
>>
>> over just calling
>>
>> hymem_allocate_memory(portlib, )
>>
> 
> Hi Geir:
> 
>Not sure if the later is "hymem_allocate_memory(int size)"? 

Well, the one I'm looking at is

hymem.c

void *VMCALL
hymem_allocate_memory (struct HyPortLibrary *portLibrary,
UDATA byteAmount)


If so,
> they are the same indeed, and the later is the a macro. Everytime before
> we use the macro, call "PORT_ACCESS_FROM_ENV (env)"
>e.g.:
>somemethod(JNIEnv * env, ...){
> PORT_ACCESS_FROM_ENV (env);
> ...
> hymem_allocate_memory(sizeof(something));
> ...
>}
> 
>And they are defined in hyport.h. :)

I've heard this rumor before, but I don't ever see how.
PORT_ACCESS_FROM_* is a simple little macro that just returns *portLib.

geir

> 
>> 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] Merging frameworks for testing serialization - first step

[Tim Ellison]

Stepan Mishura wrote:
> On 6/26/06, Tim Ellison wrote:
>>
>> Stepan Mishura wrote:
>> > Hi,
>> >
>> > I've updated framework for testing serialization page[1] - I added
>> > guidelines
>> > for developing serialization tests. Also I've removed confusing
>> 'TestCase'
>> > parameter in SerializationTest.verifySelf() methods.
>> >
>> > If there are no objections I'm going in next two days to move
>> > SerializationTest.java from 'security' module to support folder. So new
>> > location will be:
>> > support/src/test/java/org/apache/harmony/testframework/serialization
>> > folder.
>> > Class name won't change.
>> >
>> > Thoughts?
>>
>> Looks good, just a couple of minor comments:
>>
>> - You might as well move them (or duplicate them) to an
>> org.apache.harmony. package while you are moving things around, since we
>> want to get rid of tests.util as a package name.
> 
> 'Them' means tests, right?

Sorry, I actually meant the testing framework itself.  The doc says

"The testing framework provides support class
 tests.util.SerializationTest  for serialization testing."

I figured it would be easier to put them in the right place.

> - Please will you ensure that the Manifests are updated accordingly so
>> that the world is not broken.
> 
> 
> Sure, I will try.
> 
> - Not sure about the word 'golden' to mean 'reference' data, when we
>> could just use reference, but whatever.
> 
> In the method names or resource file name? Or both?

Ideally both, it just seems like jargon -- but I realize that such
renaming doesn't really 'advance the cause', so whatever you think.


Regards,
Tim

>> >
>> > [1]
>> >
>> http://incubator.apache.org/harmony/subcomponents/classlibrary/ser_testing.html
>>
>> >
>> >
>> > On 6/20/06, Stepan Mishura  wrote:
>> >>
>> >>  Hi,
>> >>
>> >> I'm going to start merging existing frameworks for testing
>> serialization.
>> >>
>> >> As first step I've updated 'security' framework. The updated framework
>> >> searches and loads resource files according [1] and eliminates
>> >> requirement
>> >> to extend SerializationTest. Also to provide smooth frameworks merging
>> >> I've
>> >> put stub to let the framework search resources in the 'old' way ( i.e.
>> >> via
>> >> "RESOURCE_DIR" system property). The stub will be removed after
>> >> completing
>> >> the merge.
>> >>
>> >> The updated framework suggests the following way for testing
>> >> serialization:
>> >>
>> >> a) Compatibility – 4 new static methods are introduced.
>> >> verifyGolden(TestCase, Object)
>> >> verifyGolden(TestCase, Object, SerializableAssert)
>> >> verifyGolden(TestCase, Object[])
>> >> verifyGolden(TestCase, Object[], SerializableAssert)
>> >>
>> >> A test should invoke one of above methods, for example,
>> >> public void testCompatibility() throws Exception {
>> >> SerializationTest.verifyGolden(this, new SomeSerializableClass
>> ());
>> >> }
>> >>
>> >> b) Self-testing: the same as for compatibility – there are 4 new
>> static
>> >> methods that should be invoked from a test:
>> >> verifySelf(TestCase, Object)
>> >> verifySelf(Object, SerializableAssert)
>> >> verifySelf(TestCase, Object[])
>> >> verifySelf(Object[], SerializableAssert)
>> >>
>> >> For example,
>> >> public void testSelf() throws Exception {
>> >> SerializationTest.verifySelf(new SomeSerializableClass(), new
>> >> MyComparator());
>> >> }
>> >>
>> >> To complete frameworks merging I'd like to suggest the next steps:
>> >> 2) Reviewing the update and the suggested way for testing
>> >> serialization by
>> >> the community. Please let me know if it is acceptable and what can be
>> >> improved.
>> >> 3) Replace SerializationTester class with SerializationTest. I'm going
>> to
>> >> add more stubs to let existing tests work in the 'old' way.
>> >> 4) Adjusting existing serialization tests (moving and renaming
>> resource
>> >> files, replacing stubs invocation with new methods)
>> >> 5) Removing stubs.
>> >>
>> >> Thanks,
>> >> Stepan Mishura
>> >> Intel Middleware Products Division
>> >>
>> >> [1]
>> >>
>> http://incubator.apache.org/harmony/subcomponents/classlibrary/ser_testing.html
>>
>>
>>
> 
> --
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 

-- 

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][testing] excluding the failed tests

[Tim Ellison]

Mikhail Loenko wrote:
> Hi Vladimir,
> 
> IMHO the tests are to verify that an update does not introduce any
> regression. So there are two options: remember which exactly tests may fail
> and remember that all tests must pass. I believe the latter one is a bit
> easier and safer.

+1

Tim

> Thanks,
> Mikhail
> 
> 2006/6/26, Vladimir Ivanov <[EMAIL PROTECTED]>:
>> Hi,
>> Working with tests I noticed that we are excluding some tests just
>> because
>> several tests from single TestCase fail.
>>
>> For example, the TestCase 'tests.api.java.lang.StringTest' has 60
>> tests and
>> only 2 of them fails. But the build excludes the whole TestCase and we
>> just
>> miss testing of java.lang.String implementation.
>>
>> Do we really need to exclude TestCases in 'ant test' target?
>>
>> My suggestion is: do not exclude any tests until it crashes VM.
>> If somebody needs a list of tests that always passed a separated
>> target can
>> be added to build.
>>
>> Do you think we should add target 'test-all' to the build?
>>  Thanks, Vladimir
>>
>>
> 
> -
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 

-- 

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] Merging frameworks for testing serialization - first step

[Stepan Mishura]

On 6/26/06, Tim Ellison wrote:


Stepan Mishura wrote:
> Hi,
>
> I've updated framework for testing serialization page[1] - I added
> guidelines
> for developing serialization tests. Also I've removed confusing
'TestCase'
> parameter in SerializationTest.verifySelf() methods.
>
> If there are no objections I'm going in next two days to move
> SerializationTest.java from 'security' module to support folder. So new
> location will be:
> support/src/test/java/org/apache/harmony/testframework/serialization
> folder.
> Class name won't change.
>
> Thoughts?

Looks good, just a couple of minor comments:

- You might as well move them (or duplicate them) to an
org.apache.harmony. package while you are moving things around, since we
want to get rid of tests.util as a package name.



'Them' means tests, right?

- Please will you ensure that the Manifests are updated accordingly so

that the world is not broken.



Sure, I will try.

- Not sure about the word 'golden' to mean 'reference' data, when we

could just use reference, but whatever.



In the method names or resource file name? Or both?

Thanks,
Stepan.

Regards,

Tim


> Thanks,
> Stepan.
>
> [1]
>
http://incubator.apache.org/harmony/subcomponents/classlibrary/ser_testing.html
>
>
> On 6/20/06, Stepan Mishura  wrote:
>>
>>  Hi,
>>
>> I'm going to start merging existing frameworks for testing
serialization.
>>
>> As first step I've updated 'security' framework. The updated framework
>> searches and loads resource files according [1] and eliminates
>> requirement
>> to extend SerializationTest. Also to provide smooth frameworks merging
>> I've
>> put stub to let the framework search resources in the 'old' way ( i.e.
>> via
>> "RESOURCE_DIR" system property). The stub will be removed after
>> completing
>> the merge.
>>
>> The updated framework suggests the following way for testing
>> serialization:
>>
>> a) Compatibility – 4 new static methods are introduced.
>> verifyGolden(TestCase, Object)
>> verifyGolden(TestCase, Object, SerializableAssert)
>> verifyGolden(TestCase, Object[])
>> verifyGolden(TestCase, Object[], SerializableAssert)
>>
>> A test should invoke one of above methods, for example,
>> public void testCompatibility() throws Exception {
>> SerializationTest.verifyGolden(this, new SomeSerializableClass ());
>> }
>>
>> b) Self-testing: the same as for compatibility – there are 4 new static
>> methods that should be invoked from a test:
>> verifySelf(TestCase, Object)
>> verifySelf(Object, SerializableAssert)
>> verifySelf(TestCase, Object[])
>> verifySelf(Object[], SerializableAssert)
>>
>> For example,
>> public void testSelf() throws Exception {
>> SerializationTest.verifySelf(new SomeSerializableClass(), new
>> MyComparator());
>> }
>>
>> To complete frameworks merging I'd like to suggest the next steps:
>> 2) Reviewing the update and the suggested way for testing
>> serialization by
>> the community. Please let me know if it is acceptable and what can be
>> improved.
>> 3) Replace SerializationTester class with SerializationTest. I'm going
to
>> add more stubs to let existing tests work in the 'old' way.
>> 4) Adjusting existing serialization tests (moving and renaming resource
>> files, replacing stubs invocation with new methods)
>> 5) Removing stubs.
>>
>> Thanks,
>> Stepan Mishura
>> Intel Middleware Products Division
>>
>> [1]
>>
http://incubator.apache.org/harmony/subcomponents/classlibrary/ser_testing.html




--
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [classlib] [beans] xml resource files in tests

[Alexei Zakharov]

Since this code is located in unit test IMHO it makes some sense to
compare the output line by line with the desired content.  Of course
it also can be (should be) read into DOM but I will need to refactor
the tests to apply it.

BTW, Geir has said (in private) it is ok to simply remove the license
from test data. So I'm going to do as he suggested.

Of course

2006/6/26, Tim Ellison <[EMAIL PROTECTED]>:

Should the tests be doing a line-by line comparison anyway?  i.e. I can
reformat the XML file and it still means the same thing, I would not
expect the test to fail.

Can't you read the golden data into a DOM and check it is the same
(maybe Node.isEqualNode(Node) or thereabouts)?

Regards,
Tim

Alexei Zakharov wrote:
> Well, the real question I'd like to get an answer for was: is it
> really impossible to remove the license from these files?
>
> 2006/6/22, Alexei Zakharov <[EMAIL PROTECTED]>:
>> Ilya, yes, it is technically possible. But IMHO is not very elegant at
>> the same time.
>>
>> 2006/6/22, Ilya Neverov <[EMAIL PROTECTED]>:
>> > Hi,
>> >
>> > Is it easier to preprocess golden files data before the string
>> > comparison? Removing first XML comment with the text
>> > "Copyright*Apache" seems to be an action which can not modify content
>> > used in the comparison.
>> >
>> > Thank you.
>> > Ilya Neverov,
>> > Intel Middleware Products Division
>> >
>> > On 6/22/06, Alexei Zakharov <[EMAIL PROTECTED]> wrote:
>> > > Hi people,
>> > >
>> > > While working on java.beans tests I've faced a funny problem. There
>> > > are tests for XMLEncoder that perform line by line comparison of the
>> > > encoder's output with static xml files from /test/resources folder
>> > > (string compare). And it seems that at some point of time someone
>> > > simply prepend Apache license to all static xmls and all tests fail
>> > > since then. :)
>> > > Since there is no easy way to force XMLEncoder to generate Apache
>> > > license, I see two possible resolutions:
>> > > 1. Remove the license from xmls. I am not sure we can do that.
>> > > 2. Replace string compare with xml compare, by means of sax parser
>> for
>> > > example. Comments will be thrown away in this case.
>> > > Personally I like (2) more. However, it will take additional efforts.
>> > > Suggestions?
>> > >
>> > > --
>> > > Alexei Zakharov,
>> > > Intel Middleware Product Division
>

--

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]





--
Alexei Zakharov,
Intel Middleware Product Division

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[website] building VM from the repository instructions

[Anton Luht]

Good day,

Though DRLVM is in the repository already, the classlib building
instructions [1] still says nothing about it in the section "Obtaining
a compatible VM" . I coudn't find instructions on building DRLVM on
the site, either - I found them browsing SVN repository. Maybe it's
worth to add info about DRLVM to the Harmony site?

[1] 
http://incubator.apache.org/harmony/subcomponents/classlibrary/build_classlib.html

--
Regards,
Anton Luht,
Intel Middleware Products Division

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [classlib][testing] excluding the failed tests

[Mikhail Loenko]

Hi Vladimir,

IMHO the tests are to verify that an update does not introduce any
regression. So there are two options: remember which exactly tests may fail
and remember that all tests must pass. I believe the latter one is a bit
easier and safer.

Thanks,
Mikhail

2006/6/26, Vladimir Ivanov <[EMAIL PROTECTED]>:

Hi,
Working with tests I noticed that we are excluding some tests just because
several tests from single TestCase fail.

For example, the TestCase 'tests.api.java.lang.StringTest' has 60 tests and
only 2 of them fails. But the build excludes the whole TestCase and we just
miss testing of java.lang.String implementation.

Do we really need to exclude TestCases in 'ant test' target?

My suggestion is: do not exclude any tests until it crashes VM.
If somebody needs a list of tests that always passed a separated target can
be added to build.

Do you think we should add target 'test-all' to the build?
 Thanks, Vladimir




-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [DRLVM] Integration checks (was building from svn on FC5)

[Tim Ellison]

Alexey Petrenko wrote:
> Yes, I understand this.
> 
> But are you sure that every committer now and in the future has access
> to the different platforms and configurations?
> 
> Committers, are you? :)

If I'm patching some general Java code then I just test on my local
workstation and wait for the build system to try it elsewhere; but if I
am writing code that is platform-specific then I will test locally on
windows and linux before committing (because I can).  As the number of
platforms increases then I'll need access to more architectures to test.

Regards,
Tim


> 2006/6/26, Anton Luht <[EMAIL PROTECTED]>:
>> Alexey,
>>
>> As far as I understand Andrey, he suggests to run tests when a piece
>> of code is integrated into the code base, by the person who has access
>> to the repository (committer). A developer shouldn't test his piece of
>> code on any platform, though it'd be good if he did it and reported
>> results in the JIRA issue.
>>
>> I don't know if running tests for hours is suitable for integration
>> check, if so, I can suggest using Eclipse automated tests  (can be
>> found in download section for each Eclipse release). Total amount of
>> tests is > 1 . They test Eclipse functionality quite deeply. Note:
>> they'll fail without GUI.
>>
>> > > We may probably also need to define the list of
>> platforms/configurations covered by this procedure.
>> > I'm not sure that I get your idea correctly.
>> > Do you suggest to ask every developer to make some checks on different
>> > platforms and software configurations?
>> > If so... Yes, it is good for product stability.
>> > But it will be nearly impossible because very small number of
>> > developers have access to different platforms and software
>> > configurations...
>>
>> -- 
>> 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]
>>
>>
> 
> 

-- 

Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [DRLVM] Integration checks (was building from svn on FC5)

[Alexey Petrenko]

Yes, I understand this.

But are you sure that every committer now and in the future has access
to the different platforms and configurations?

Committers, are you? :)

2006/6/26, Anton Luht <[EMAIL PROTECTED]>:

Alexey,

As far as I understand Andrey, he suggests to run tests when a piece
of code is integrated into the code base, by the person who has access
to the repository (committer). A developer shouldn't test his piece of
code on any platform, though it'd be good if he did it and reported
results in the JIRA issue.

I don't know if running tests for hours is suitable for integration
check, if so, I can suggest using Eclipse automated tests  (can be
found in download section for each Eclipse release). Total amount of
tests is > 1 . They test Eclipse functionality quite deeply. Note:
they'll fail without GUI.

> > We may probably also need to define the list of platforms/configurations 
covered by this procedure.
> I'm not sure that I get your idea correctly.
> Do you suggest to ask every developer to make some checks on different
> platforms and software configurations?
> If so... Yes, it is good for product stability.
> But it will be nearly impossible because very small number of
> developers have access to different platforms and software
> configurations...

--
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]





--
Alexey A. Petrenko
Intel Middleware Products Division

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [classlib] Merging frameworks for testing serialization - first step

[Tim Ellison]

Stepan Mishura wrote:
> Hi,
> 
> I've updated framework for testing serialization page[1] - I added
> guidelines
> for developing serialization tests. Also I've removed confusing 'TestCase'
> parameter in SerializationTest.verifySelf() methods.
> 
> If there are no objections I'm going in next two days to move
> SerializationTest.java from 'security' module to support folder. So new
> location will be:
> support/src/test/java/org/apache/harmony/testframework/serialization
> folder.
> Class name won't change.
> 
> Thoughts?

Looks good, just a couple of minor comments:

 - You might as well move them (or duplicate them) to an
org.apache.harmony. package while you are moving things around, since we
want to get rid of tests.util as a package name.

 - Please will you ensure that the Manifests are updated accordingly so
that the world is not broken.

 - Not sure about the word 'golden' to mean 'reference' data, when we
could just use reference, but whatever.

Regards,
Tim


> Thanks,
> Stepan.
> 
> [1]
> http://incubator.apache.org/harmony/subcomponents/classlibrary/ser_testing.html
> 
> 
> On 6/20/06, Stepan Mishura  wrote:
>>
>>  Hi,
>>
>> I'm going to start merging existing frameworks for testing serialization.
>>
>> As first step I've updated 'security' framework. The updated framework
>> searches and loads resource files according [1] and eliminates
>> requirement
>> to extend SerializationTest. Also to provide smooth frameworks merging
>> I've
>> put stub to let the framework search resources in the 'old' way ( i.e.
>> via
>> "RESOURCE_DIR" system property). The stub will be removed after
>> completing
>> the merge.
>>
>> The updated framework suggests the following way for testing
>> serialization:
>>
>> a) Compatibility – 4 new static methods are introduced.
>> verifyGolden(TestCase, Object)
>> verifyGolden(TestCase, Object, SerializableAssert)
>> verifyGolden(TestCase, Object[])
>> verifyGolden(TestCase, Object[], SerializableAssert)
>>
>> A test should invoke one of above methods, for example,
>> public void testCompatibility() throws Exception {
>> SerializationTest.verifyGolden(this, new SomeSerializableClass ());
>> }
>>
>> b) Self-testing: the same as for compatibility – there are 4 new static
>> methods that should be invoked from a test:
>> verifySelf(TestCase, Object)
>> verifySelf(Object, SerializableAssert)
>> verifySelf(TestCase, Object[])
>> verifySelf(Object[], SerializableAssert)
>>
>> For example,
>> public void testSelf() throws Exception {
>> SerializationTest.verifySelf(new SomeSerializableClass(), new
>> MyComparator());
>> }
>>
>> To complete frameworks merging I'd like to suggest the next steps:
>> 2) Reviewing the update and the suggested way for testing
>> serialization by
>> the community. Please let me know if it is acceptable and what can be
>> improved.
>> 3) Replace SerializationTester class with SerializationTest. I'm going to
>> add more stubs to let existing tests work in the 'old' way.
>> 4) Adjusting existing serialization tests (moving and renaming resource
>> files, replacing stubs invocation with new methods)
>> 5) Removing stubs.
>>
>> Thanks,
>> Stepan Mishura
>> Intel Middleware Products Division
>>
>> [1]
>> http://incubator.apache.org/harmony/subcomponents/classlibrary/ser_testing.html
>>
>>
>>
>> --
>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
> 
> 
> 

-- 

Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [DRLVM] Integration checks (was building from svn on FC5)

[Anton Luht]

Alexey,

As far as I understand Andrey, he suggests to run tests when a piece
of code is integrated into the code base, by the person who has access
to the repository (committer). A developer shouldn't test his piece of
code on any platform, though it'd be good if he did it and reported
results in the JIRA issue.

I don't know if running tests for hours is suitable for integration
check, if so, I can suggest using Eclipse automated tests  (can be
found in download section for each Eclipse release). Total amount of
tests is > 1 . They test Eclipse functionality quite deeply. Note:
they'll fail without GUI.


> We may probably also need to define the list of platforms/configurations 
covered by this procedure.
I'm not sure that I get your idea correctly.
Do you suggest to ask every developer to make some checks on different
platforms and software configurations?
If so... Yes, it is good for product stability.
But it will be nearly impossible because very small number of
developers have access to different platforms and software
configurations...


--
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]

[classlib][testing] excluding the failed tests

[Vladimir Ivanov]

Hi,
Working with tests I noticed that we are excluding some tests just because
several tests from single TestCase fail.

For example, the TestCase 'tests.api.java.lang.StringTest' has 60 tests and
only 2 of them fails. But the build excludes the whole TestCase and we just
miss testing of java.lang.String implementation.

Do we really need to exclude TestCases in 'ant test' target?

My suggestion is: do not exclude any tests until it crashes VM.
If somebody needs a list of tests that always passed a separated target can
be added to build.

Do you think we should add target 'test-all' to the build?
Thanks, Vladimir

defining the bootclasspath (was: Re: svn commit: r416738 - /incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/init/bootclasspath.properties)

[Tim Ellison]

Alexey Petrenko wrote:
> 2006/6/26, Tim Ellison <[EMAIL PROTECTED]>:
>> Magnusson, Geir wrote:
>> > Its an element of uncertainty because if you change the load order,
>> surprises can happen.
>>
>> I'm confused?  The stubs do not participate in the bootclasspath order,
>> which is defined by the properties file.
> I think that we can easily avoid the problem mentioned by Geir by
> hardcoding the jar with VM kernel classes to the first place in the
> boot class path.

Yes, I understood that is what Gregory had done in HARMONY-655.

While this is fine, I also pointed out that the launcher would help VMs
do this without explicit modification.

> I mean that VM can load kernel.jar or whatever first and then read
> bootclasspath.properties, check parameters or whatever.

Agreed.

Regards,
Tim


-- 

Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: svn commit: r416738 - /incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/init/bootclasspath.properties

[Vladimir Gorr]

On 6/26/06, Mark Hindess <[EMAIL PROTECTED]> wrote:



On 25 June 2006 at 22:01, "Vladimir Gorr" <[EMAIL PROTECTED]> wrote:
>
> String & StringBuffer should be removed from the DRLVM sources
> to eliminate this issue. These classes will be taken from the luni.jarafter
> this action.
> We had own implementation for these classes because they were a part of
the
> kernel classes
> for IBM VM some time ago. Should we create new JIRA issue for doing this
> action?

A JIRA would be great.  Thanks Vladimir.



Harmony-666 has been created. I don't like its "devil" number :-).

Thanks,
Vladimir.


-Mark




-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: svn commit: r416738 - /incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/init/bootclasspath.properties

[Gregory Shimansky]

2006/6/26, Geir Magnusson Jr <[EMAIL PROTECTED]>:




Ivan Volosyuk wrote:
>
> loaded
> java.lang.NoSuchMethodError: Can't find method
>
org/apache/harmony/kernel/vm/VM.bootCallerClassLoader()Ljava/lang/ClassLoader;
>
> while resolving constant pool entry at index 74 in class
> org/apache/harmony/luni/util/MsgHelp
>at org.apache.harmony.luni.util.Msg.(Msg.java:47)
>at java.net.URL.(URL.java:291)
>at java.net.URL.(URL.java:155)
>at org.eclipse.core.launcher.Main.buildURL(Main.java:773)
>at
>

[SNIP]

> The exception is reproducible with and without Gregory's patch.
> Gregory, is it the same problem you are working on?

I don't think so.  We're just missing the method (obviously) in the
DRLVM implementation of VM.java



That's correct. I added this method in a patch which I created when I tried
to run specjvm98. It is attached to HARMONY-644.

--
Gregory Shimansky, Intel Middleware Products Division

Re: [classlib][testing]resource files: location and usage

[Tim Ellison]

Anton Luht wrote:
>> Indeed, unless you are extremely paranoid that all the other API
>> implementations wrong, but are conspiring to make your test pass then
>> you should assume that everything else is working ok and you are testing
>> some specific piece of functionality.
> 
> Why should we have gold files then? Let's imagine we test
> deserialization. According to your proposal - we suppose that
> serialization works fine then. Let's serialize something in a file or
> an array, deserialize and compare - if non-transient fields are equal,
> it's OK.

Yes, for *compatibility* we need some external data like the
serialization data.

> I suggest to trust only resources created outside Harmony VM - for
> example, created by Java executed in RI, application on any other
> language but Java or taken from SVN.

Hopefully you don't mean that literally.  If you don't trust anything
created by the Harmony VM then you can not implement a meaningful test.

> Only paranoids survive :)

But a little trust will get us further faster ;-)

Regards,
Tim


-- 

Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: svn commit: r416738 - /incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/init/bootclasspath.properties

[Alexey Petrenko]

2006/6/26, Tim Ellison <[EMAIL PROTECTED]>:

Magnusson, Geir wrote:
> Its an element of uncertainty because if you change the load order, surprises 
can happen.

I'm confused?  The stubs do not participate in the bootclasspath order,
which is defined by the properties file.

I think that we can easily avoid the problem mentioned by Geir by
hardcoding the jar with VM kernel classes to the first place in the
boot class path.
I mean that VM can load kernel.jar or whatever first and then read
bootclasspath.properties, check parameters or whatever.

--
Alexey A. Petrenko
Intel Middleware Products Division

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [classlib] [beans] xml resource files in tests

[Tim Ellison]

Should the tests be doing a line-by line comparison anyway?  i.e. I can
reformat the XML file and it still means the same thing, I would not
expect the test to fail.

Can't you read the golden data into a DOM and check it is the same
(maybe Node.isEqualNode(Node) or thereabouts)?

Regards,
Tim

Alexei Zakharov wrote:
> Well, the real question I'd like to get an answer for was: is it
> really impossible to remove the license from these files?
> 
> 2006/6/22, Alexei Zakharov <[EMAIL PROTECTED]>:
>> Ilya, yes, it is technically possible. But IMHO is not very elegant at
>> the same time.
>>
>> 2006/6/22, Ilya Neverov <[EMAIL PROTECTED]>:
>> > Hi,
>> >
>> > Is it easier to preprocess golden files data before the string
>> > comparison? Removing first XML comment with the text
>> > "Copyright*Apache" seems to be an action which can not modify content
>> > used in the comparison.
>> >
>> > Thank you.
>> > Ilya Neverov,
>> > Intel Middleware Products Division
>> >
>> > On 6/22/06, Alexei Zakharov <[EMAIL PROTECTED]> wrote:
>> > > Hi people,
>> > >
>> > > While working on java.beans tests I've faced a funny problem. There
>> > > are tests for XMLEncoder that perform line by line comparison of the
>> > > encoder's output with static xml files from /test/resources folder
>> > > (string compare). And it seems that at some point of time someone
>> > > simply prepend Apache license to all static xmls and all tests fail
>> > > since then. :)
>> > > Since there is no easy way to force XMLEncoder to generate Apache
>> > > license, I see two possible resolutions:
>> > > 1. Remove the license from xmls. I am not sure we can do that.
>> > > 2. Replace string compare with xml compare, by means of sax parser
>> for
>> > > example. Comments will be thrown away in this case.
>> > > Personally I like (2) more. However, it will take additional efforts.
>> > > Suggestions?
>> > >
>> > > --
>> > > Alexei Zakharov,
>> > > Intel Middleware Product Division
> 

-- 

Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: svn commit: r416738 - /incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/init/bootclasspath.properties

[Tim Ellison]

Magnusson, Geir wrote:
> Its an element of uncertainty because if you change the load order, surprises 
> can happen.

I'm confused?  The stubs do not participate in the bootclasspath order,
which is defined by the properties file.

> I understand the need for compilation, but don't see why they are necessary 
> in jars for deployment...

Right, they are not needed at runtime because the VM provides its own
version.  They appear there to satisfy the compile-time requirements
(and development-time visibility rules).

FYI  Our simple javac tool queries the VM it is running on to find out
the location of the kernel and other bootclasspath jars.

Regards,
Tim

>  -Original Message-
> From: Tim Ellison [mailto:[EMAIL PROTECTED]
> Sent: Monday, June 26, 2006 02:30 AM Pacific Standard Time
> To:   harmony-dev@incubator.apache.org
> Subject:  Re: svn commit: r416738 - 
> /incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/init/bootclasspath.properties
> 
> Magnusson, Geir wrote:
>> Isn't it better to not have the stubs around at all?  Gets rid of one
>> element of uncertainty - load order.
> 
> As Mark points out, they are not referenced by the
> bootclasspath.properties, which defines the load-order.  However, they
> are needed to allow Java code to compile (both our build scripts and our
> Javac).
> 
> 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]

[drlvm]ij.bat on Windows....

[Alexey Petrenko]

Guys,

Does anybody know why drlvm has ij.bat in its bin directory?
This ij.bat calls .\ij.exe. It means that you can not run something
like "c:\work\drlvm\bin\ij" because ij.bat will not find ij.exe in
this case.

The workaround is obvious but why do we need it?

SY, Alexey

--
Alexey A. Petrenko
Intel Middleware Products Division

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: svn commit: r416738 - /incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/init/bootclasspath.properties

[Alexey Petrenko]

Mark,

have you tried to run ij after your fix?
I still can not run it... I got "unknown constant type in classfile"
error with "Hello, World!" application...

2006/6/24, Alexey Petrenko <[EMAIL PROTECTED]>:

Right, agreed.

Thanks again for the fast fix.
I'll check it on monday... I'm playing with prebuilt jpeg and png
libraries found in the net... :)

SY, Alexey

2006/6/24, Mark Hindess <[EMAIL PROTECTED]>:
>
> On 23 June 2006 at 23:43, "Alexey Petrenko" <[EMAIL PROTECTED]> wrote:
> > Mark,
> >
> > thanks for the fast fix.
> >
> > But probably Tim was right and we should not fix properties file but
> > should fix drlvm to work inside classlib deploy directory?
>
> Indeed.  See my comment in the JIRA HARMONY-651.  I would have used
> the version from classlib, but there is an outstanding issue with
> serializer.jar - which drlvm current adds to jre/lib/boot but classlib
> does not.
>
> As I suggested in an earlier message (subject Re: [drlvm] Doing the
> minimum to support Java 5 classfiles) I think drlvm's deploy tree
> shouldn't contain any classlib files but should produce a deploy tree
> that a top-level build can combine with a classlib tree to produce a
> fully working deploy tree.  Much like we do manually when we combine the
> IBM VME and classlib.
>
> That is, we should do more to reduce the coupling between drlvm and
> classlib.  At the moment, drlvm is trying to understand classlib - i.e.
> knowing what to copy across but it is not going to be maintainable.
> (And arguably it is already failing because it is not copying the jre/
> lib/ext/bcprov.jar that classlib uses - instead drlvm puts an older
> version in jre/lib/boot.  This is just confusing we should stop trying
> to do it in drlvm and delegate this task to the top-level build.)
>
> > Gregory?
>
> I'd like to know what Gregory thinks about this too.
>
> Regards,
>  Mark.
>
> > 2006/6/23, Mark Hindess <[EMAIL PROTECTED]>:
> > >
> > > On 23 June 2006 at 22:37, Gregory Shimansky <[EMAIL PROTECTED]> wrote:
> > > > Hello Mark
> > > >
> > > > While resolving conflict between your and mine changes to this file
> > > > I've found that you didn't include awt.jar. Should it be added
> > > > perhaps?
> > >
> > > Yes.  Fixed in r416804 (and I've fixed the reason why it was missing
> > > from my build).
> > >
> > > -Mark.
> > >
> > > > On Friday 23 June 2006 19:22 [EMAIL PROTECTED] wrote:
> > > > > Author: hindessm
> > > > > Date: Fri Jun 23 08:22:20 2006
> > > > > New Revision: 416738
> > > > >
> > > > > URL: http://svn.apache.org/viewvc?rev=416738&view=rev
> > > > > Log:
> > > > > Fixed to point to all jars (or at least a version of all jars).
> > > > >
> > > > > Modified:
> > > > >
> > > > > 
incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/init/bootclasspath
> > .pro
> > > > >perties
> > > > >
> > > > > Modified:
> > > > > 
incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/init/bootclasspath
> > .pro
> > > > >perties URL:
> > > > > 
http://svn.apache.org/viewvc/incubator/harmony/enhanced/drlvm/trunk/vm/
> > vmco
> > > > 
>re/src/init/bootclasspath.properties?rev=416738&r1=416737&r2=416738&view
> > =dif
> > > > >f
> > > > > 
===
> > 
> > > > >=== ---
> > > > > 
incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/init/bootclasspath
> > .pro
> > > > >perties (original) +++
> > > > > 
incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/init/bootclasspath
> > .pro
> > > > >perties Fri Jun 23 08:22:20 2006 @@ -38,46 +38,68 @@
> > > > >  # unspecified then the source is deemed to be available rooted at 
'/'.
> > > > >  # Packageroots given with no source location are ignored.
> > > > >
> > > > > -bootclasspath.1=archive.jar
> > > > > +bootclasspath.1=accessibility.jar
> > > > >
> > > > > -bootclasspath.2=bcprov-jdk14-129.jar
> > > > > +bootclasspath.2=annotation.jar
> > > > >
> > > > > -bootclasspath.3=beans.jar
> > > > > +bootclasspath.3=applet.jar
> > > > >
> > > > > -bootclasspath.4=crypto.jar
> > > > > +bootclasspath.4=archive.jar
> > > > >
> > > > > -bootclasspath.5=icu4j_3_4.jar
> > > > > +bootclasspath.5=auth.jar
> > > > >
> > > > > -bootclasspath.6=icu4jni-3.4.jar
> > > > > +bootclasspath.6=bcprov-jdk14-129.jar
> > > > >
> > > > > -bootclasspath.7=kernel.jar
> > > > > +bootclasspath.7=beans.jar
> > > > >
> > > > > -bootclasspath.8=logging.jar
> > > > > +bootclasspath.8=crypto.jar
> > > > >
> > > > > -bootclasspath.9=luni.jar
> > > > > +bootclasspath.9=icu4j_3.4.4/icu4j_3_4_4.jar
> > > > >
> > > > > -bootclasspath.10=math.jar
> > > > > +bootclasspath.10=icu4jni-3.4.jar
> > > > >
> > > > > -bootclasspath.11=nio.jar
> > > > > +bootclasspath.11=jndi.jar
> > > > >
> > > > > -bootclasspath.12=nio_char.jar
> > > > > +bootclasspath.12=kernel.jar
> > > > >
> > > > > -bootclasspath.13=regex.jar
> > > > > +bootclasspath.13=logging.jar
> > > > >
> > > > > -bootclasspath.14=resolver.jar
> > > > > +bootclasspath.14=luni.jar
> > > > >
> > > > > -bootclasspath.15=security.jar
> > 

Re: [classlib] Merging frameworks for testing serialization - first step

[Stepan Mishura]

On 6/26/06, Paulex Yang wrote:


Stepan,

Thank you for the answer,  the updated version on the website is fine,
only one issue:

About this method:
|verifyGolden(TestCase, Object[], SerializableAssert)

Do we need to add the SerializableAssert's definition on that page? (I
suppose it is an interface or so?)



Yes, it is an interface. I agree that it makes sense to add definition of
the interface - done in r417165, please review.

Thanks,
Stepan.

|

Stepan Mishura wrote:
> Hi Paulex,
>
> see answers below
>
> On 6/20/06, Paulex Yang wrote:
>
>> Stepan,
>>
>> Cool! Basically I'm fine with the merging plan, and I'm very interested
>> in more details, please see my comments below:
>>
>> Stepan Mishura wrote:
>> > Hi,
>> >
>> > I'm going to start merging existing frameworks for testing
>> serialization.
>> >
>> > As first step I've updated 'security' framework. The updated
framework
>> > searches and loads resource files according [1] and eliminates
>> > requirement
>> > to extend SerializationTest. Also to provide smooth frameworks
merging
>> > I've
>> > put stub to let the framework search resources in the 'old' way (i.e.
>> via
>> > "RESOURCE_DIR" system property). The stub will be removed after
>> > completing
>> > the merge.
>> >
>> > The updated framework suggests the following way for testing
>> > serialization:
>> >
>> > a) Compatibility – 4 new static methods are introduced.
>> >verifyGolden(TestCase, Object)
>> I suppose the TestCase is used to locate the golden file, i.e.
>> BlablaTest will load BlablaTest.golden.ser?
>
>
>
> Right, it is used to locate the golden file.
>
>>verifyGolden(TestCase, Object, SerializableAssert)
>> Is the SerializableAssert a command object? Does it currently exist? if
>> not, what will it look like?
>> >verifyGolden(TestCase, Object[])
>> >verifyGolden(TestCase, Object[], SerializableAssert)
>> What's the meaning of Object[]?  I guess the Object[i] is compared with
>> Test.golden.1.ser?
>
>
> Right again. So if you have one object to be verified you will use
> verifyGolden(TestCase, Object) and if there are several objects to be
> tested
> then you may wish to use  verifyGolden(TestCase, Object[]).
>
>
>>
>> > A test should invoke one of above methods, for example,
>> > public void testCompatibility() throws Exception {
>> >SerializationTest.verifyGolden(this, new SomeSerializableClass
());
>> > }
>> >
>> > b) Self-testing: the same as for compatibility – there are 4 new
>> static
>> > methods that should be invoked from a test:
>> >verifySelf(TestCase, Object)
>> >verifySelf(Object, SerializableAssert)
>> >verifySelf(TestCase, Object[])
>> >verifySelf(Object[], SerializableAssert)
>> What's the difference between methods with and without TestCase?
>
>
> The difference is quite simple: in case of TestCase the framework
> looks up
> for an appropriate SerializationAssert. In other words, it is
equivalent:
> verifySelf(object, defineComparator(test, object));
>
> May be methods with TestCase param are little bit confusing - it is
> possible
> to remove them.
>
>
>> Does this imply if it needs to find persistent serialization files?
>
> No, it doesn't.
>
>> And why the methods with TestCase parameter don't need
>> customized SerializationAssert?
>>
>
> As I wrote above the framework tries to figure out an appropriate
> SerializationAssert.
>
>> For example,
>> > public void testSelf() throws Exception {
>> >SerializationTest.verifySelf(new SomeSerializableClass(), new
>> > MyComparator());
>> > }
>> >
>> > To complete frameworks merging I'd like to suggest the next steps:
>> > 2) Reviewing the update and the suggested way for testing
>> > serialization by
>> > the community. Please let me know if it is acceptable and what can be
>> > improved.
>> > 3) Replace SerializationTester class with SerializationTest. I'm
going
>> to
>> > add more stubs to let existing tests work in the 'old' way.
>> > 4) Adjusting existing serialization tests (moving and renaming
>> resource
>> > files, replacing stubs invocation with new methods)
>> > 5) Removing stubs.
>> Thank you, Stepan, it is a really good plan!
>
>
> Thank you for your feedback.
>
> - Stepan
>
>
> --
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>


--
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]





--
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] Help wanted!

[George Harley]

Nathan Beyer wrote:

-Original Message-
From: George Harley [mailto:[EMAIL PROTECTED]

Nathan Beyer wrote:


Yeah, I noticed that. Unfortunately, it can only be used luni for now,
  

since


the compiler is turning it into an interface class. The sooner we move
  

to


1.5 class files the better; I'm tired of the weird 1.5 source to 1.4
  

class


file behavior that's basically undefined.


  

Hi Nathan,

Do you mean that using @SuppressWarnings in types outside of the LUNI
module results in compiler problems for you ? If so then I cannot
recreate this problem.

Best regards,
George



That is the problem I'm having. When all source is compiled together using
ECJ I can use the annotations outside the project they are declared in.
However, when trying to use the annotations in a project an compiling
against pre-built class files, then the annotation classes can't be
resolved. This is why the meta-annotations on Deprecated, SuppressWarnings
and Override are currently commented out.

The way to recreate this is to open LUNI and another project, such as NIO in
an Eclipse workspace and then add an annotation to a class in NIO. It should
compile fine as 'Plug-in Dependencies' will resolve the LUNI reference in
the workspace. Close the LUNI project and rebuild NIO. The dependencies now
resolve to the target platform's JARs and the class using the annotation
will fail to compile.

-Nathan

  


Hi Nathan,

OK, I see this too. If I understand correctly, this is a failure that 
only occurs inside the Eclipse world and only with the LUNI project 
closed. It seems to me that the *temporary* workaround of keeping LUNI 
open while working on project X is not particularly prohibitive. So long 
as the subsequent changes do not then nobble the build and test cycle 
outside Eclipse (i.e. on the modern compiler) then all should be well. 
What do you think ?


Best regards,
George




-Original Message-
From: Tim Ellison [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 22, 2006 6:04 AM
To: harmony-dev@incubator.apache.org
Subject: Re: [classlib] Help wanted!

Nathan Beyer wrote:



I've been hacking away at those warnings every chance I get. The
  

'luni'


module is going to be filled warnings until we can begin using

  

annotations,



specifically the @SuppressWarning, especially the Collections classes.

  

Thanks to George [1] you can now use @SuppressWarning.

[1] http://svn.apache.org/viewvc?view=rev&revision=416121

Regards,
Tim




There
are a number of cases where unchecked type uses are a requirement

  

because of



limitations in current APIs, backwards compatability and generic array
construction.

Here are some of the major pieces that can't be avoided and need

  

suppressing



annotations:
* Cloning - When you clone a generified object you have no choice but
  

to


do



an unchecked cast.
* Generic Array Construction - The only thing you can do is T[] =

  

(T[])new



Object[size]; and suppress the warning.

In any case, I'm all for keep this stuff as clean as possible. I have
  

my


Eclipse compiler settings cranked to the max in the IDE.

-Nathan


  

-Original Message-
From: Mark Hindess [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 21, 2006 12:49 AM
To: Apache Harmony Dev List
Subject: [classlib] Help wanted!


I was looking at building (and testing) with Eclipse + IBM VME.  I



think



this is really important since ecj has a much cleaner classpath when


it


compiles so it helps us find errors quicker.

The logs come out at over 3MB!  There are lots of warnings about less
than ideal type checking - mostly as a result of our adoption of more
generics.  For example:

[javac] 1. WARNING in
/pbuilder/tmp/Harmony.my/modules/accessibility/src/mai
n/java/javax/accessibility/AccessibleRelationSet.java
[javac]  (at line 44)
[javac] relations.add(relation);
[javac] ^^^
[javac] Type safety: The method add(Object) belongs to the raw


type


Vector.
References to generic type Vector should be parameterized
[javac] --
[javac] 2. WARNING in
/pbuilder/tmp/Harmony.my/modules/accessibility/src/mai
n/java/javax/accessibility/AccessibleRelationSet.java
[javac]  (at line 88)
[javac] (AccessibleRelation[])relations.toArray(new
AccessibleRelation[r
elations.size()]);
[javac]
^^
^
[javac] Type safety: The method toArray(Object[]) belongs to the



raw



type Ve
ctor. References to generic type Vector should be parameterized

I think we should try to improve these, but there are rather too many
for me to do on my own!  What do others think?  I think we could



disable



th

Re: svn commit: r416738 - /incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/init/bootclasspath.properties

[Magnusson, Geir]

Its an element of uncertainty because if you change the load order, surprises 
can happen.

I understand the need for compilation, but don't see why they are necessary in 
jars for deployment...

Geir

 -Original Message-
From:   Tim Ellison [mailto:[EMAIL PROTECTED]
Sent:   Monday, June 26, 2006 02:30 AM Pacific Standard Time
To: harmony-dev@incubator.apache.org
Subject:Re: svn commit: r416738 - 
/incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/init/bootclasspath.properties

Magnusson, Geir wrote:
> Isn't it better to not have the stubs around at all?  Gets rid of one
> element of uncertainty - load order.

As Mark points out, they are not referenced by the
bootclasspath.properties, which defines the load-order.  However, they
are needed to allow Java code to compile (both our build scripts and our
Javac).

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]

RE: svn commit: r417148 - in /incubator/harmony/enhanced/classlib/trunk/modules/luni/src: main/java/java/util/Formatter.java test/java/tests/api/java/util/FormatterTest.java

[Nathan Beyer]

Sure, no problem.

While talking about this issue, I did want to bring up that the
FormatterTest as it stands, even before this small addendum, doesn't pass
against the RI (Sun 5.0_7). This particular test isn't in the 'api' test
folder as defined by our suggested best practice, so this may not be
important, but is this expected/known?

-Nathan

> -Original Message-
> From: Tim Ellison [mailto:[EMAIL PROTECTED]
> Sent: Monday, June 26, 2006 4:46 AM
> To: harmony-dev@incubator.apache.org
> Subject: Re: svn commit: r417148 - in
> /incubator/harmony/enhanced/classlib/trunk/modules/luni/src:
> main/java/java/util/Formatter.java
> test/java/tests/api/java/util/FormatterTest.java
> 
> Soory for being petty, but could you please include the JIRA title as
> well as the JIRA number in the log message, so I can read the reason
> without having to endure the joys of the JIRA webpages?
> 
> Thanks
> Tim
> 
> [EMAIL PROTECTED] wrote:
> > Author: ndbeyer
> > Date: Mon Jun 26 02:06:44 2006
> > New Revision: 417148
> >
> > URL: http://svn.apache.org/viewvc?rev=417148&view=rev
> > Log:
> > Apply patch for HARMONY-653.
> >
> > Modified:
> >
> incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java/
> util/Formatter.java
> >
> incubator/harmony/enhanced/classlib/trunk/modules/luni/src/test/java/tests
> /api/java/util/FormatterTest.java
> 
> --
> 
> 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: svn commit: r417148 - in /incubator/harmony/enhanced/classlib/trunk/modules/luni/src: main/java/java/util/Formatter.java test/java/tests/api/java/util/FormatterTest.java

[Tim Ellison]

Soory for being petty, but could you please include the JIRA title as
well as the JIRA number in the log message, so I can read the reason
without having to endure the joys of the JIRA webpages?

Thanks
Tim

[EMAIL PROTECTED] wrote:
> Author: ndbeyer
> Date: Mon Jun 26 02:06:44 2006
> New Revision: 417148
> 
> URL: http://svn.apache.org/viewvc?rev=417148&view=rev
> Log:
> Apply patch for HARMONY-653.
> 
> Modified:
> 
> incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/java/java/util/Formatter.java
> 
> incubator/harmony/enhanced/classlib/trunk/modules/luni/src/test/java/tests/api/java/util/FormatterTest.java

-- 

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: RI's bug of Socket.getOutputStream().write(byte[]) ?

[Tim Ellison]

Florian Weimer wrote:
> * Tim Ellison:
> 
>> Thanks Florian, I need to go back and read Steven's more closely ;-) .
>> I have no doubt you are correct, but have never seen a close overtake
>> the data -- we should of course do it right.
> 
> Hmm, I think I was wrong.  The scenario I had on mind can only occur
> if the client also sends some data which is still in transit when the
> server closes the connection.  In this case, the server sends an RST
> when that data arrives, and some clients discard all pending the data
> they receive the RST.

Yes, of course, but in this case the sender is doing the close(), so
reading until -1 should be safe, right?

Regards,
Tim

-- 

Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [classlib] Help wanted!

[Nathan Beyer]

> -Original Message-
> From: George Harley [mailto:[EMAIL PROTECTED]
> 
> Nathan Beyer wrote:
> > Yeah, I noticed that. Unfortunately, it can only be used luni for now,
> since
> > the compiler is turning it into an interface class. The sooner we move
> to
> > 1.5 class files the better; I'm tired of the weird 1.5 source to 1.4
> class
> > file behavior that's basically undefined.
> >
> >
> 
> Hi Nathan,
> 
> Do you mean that using @SuppressWarnings in types outside of the LUNI
> module results in compiler problems for you ? If so then I cannot
> recreate this problem.
> 
> Best regards,
> George

That is the problem I'm having. When all source is compiled together using
ECJ I can use the annotations outside the project they are declared in.
However, when trying to use the annotations in a project an compiling
against pre-built class files, then the annotation classes can't be
resolved. This is why the meta-annotations on Deprecated, SuppressWarnings
and Override are currently commented out.

The way to recreate this is to open LUNI and another project, such as NIO in
an Eclipse workspace and then add an annotation to a class in NIO. It should
compile fine as 'Plug-in Dependencies' will resolve the LUNI reference in
the workspace. Close the LUNI project and rebuild NIO. The dependencies now
resolve to the target platform's JARs and the class using the annotation
will fail to compile.

-Nathan

> 
> 
> >> -Original Message-
> >> From: Tim Ellison [mailto:[EMAIL PROTECTED]
> >> Sent: Thursday, June 22, 2006 6:04 AM
> >> To: harmony-dev@incubator.apache.org
> >> Subject: Re: [classlib] Help wanted!
> >>
> >> Nathan Beyer wrote:
> >>
> >>> I've been hacking away at those warnings every chance I get. The
> 'luni'
> >>> module is going to be filled warnings until we can begin using
> >>>
> >> annotations,
> >>
> >>> specifically the @SuppressWarning, especially the Collections classes.
> >>>
> >> Thanks to George [1] you can now use @SuppressWarning.
> >>
> >> [1] http://svn.apache.org/viewvc?view=rev&revision=416121
> >>
> >> Regards,
> >> Tim
> >>
> >>
> >>> There
> >>> are a number of cases where unchecked type uses are a requirement
> >>>
> >> because of
> >>
> >>> limitations in current APIs, backwards compatability and generic array
> >>> construction.
> >>>
> >>> Here are some of the major pieces that can't be avoided and need
> >>>
> >> suppressing
> >>
> >>> annotations:
> >>> * Cloning - When you clone a generified object you have no choice but
> to
> >>>
> >> do
> >>
> >>> an unchecked cast.
> >>> * Generic Array Construction - The only thing you can do is T[] =
> >>>
> >> (T[])new
> >>
> >>> Object[size]; and suppress the warning.
> >>>
> >>> In any case, I'm all for keep this stuff as clean as possible. I have
> my
> >>> Eclipse compiler settings cranked to the max in the IDE.
> >>>
> >>> -Nathan
> >>>
> >>>
>  -Original Message-
>  From: Mark Hindess [mailto:[EMAIL PROTECTED]
>  Sent: Wednesday, June 21, 2006 12:49 AM
>  To: Apache Harmony Dev List
>  Subject: [classlib] Help wanted!
> 
> 
>  I was looking at building (and testing) with Eclipse + IBM VME.  I
> 
> >> think
> >>
>  this is really important since ecj has a much cleaner classpath when
> it
>  compiles so it helps us find errors quicker.
> 
>  The logs come out at over 3MB!  There are lots of warnings about less
>  than ideal type checking - mostly as a result of our adoption of more
>  generics.  For example:
> 
>  [javac] 1. WARNING in
>  /pbuilder/tmp/Harmony.my/modules/accessibility/src/mai
>  n/java/javax/accessibility/AccessibleRelationSet.java
>  [javac]  (at line 44)
>  [javac] relations.add(relation);
>  [javac] ^^^
>  [javac] Type safety: The method add(Object) belongs to the raw
> type
>  Vector.
>  References to generic type Vector should be parameterized
>  [javac] --
>  [javac] 2. WARNING in
>  /pbuilder/tmp/Harmony.my/modules/accessibility/src/mai
>  n/java/javax/accessibility/AccessibleRelationSet.java
>  [javac]  (at line 88)
>  [javac] (AccessibleRelation[])relations.toArray(new
>  AccessibleRelation[r
>  elations.size()]);
>  [javac]
>  ^^
>  ^
>  [javac] Type safety: The method toArray(Object[]) belongs to the
> 
> >> raw
> >>
>  type Ve
>  ctor. References to generic type Vector should be parameterized
> 
>  I think we should try to improve these, but there are rather too many
>  for me to do on my own!  What do others think?  I think we could
> 
> >> disable
> >>
>  the warnings from Eclipse but I don't think that's really the right
>  thing to do.
> 
>  The distribution of warnings is as follows:
> 
>  4 accessibility
> 24 archive
> 90 a

Re: [classlib] mem

[Tim Ellison]

Paulex Yang wrote:
> Tim Ellison wrote:

>> PORT_ACCESS_FROM_PORT(portlib)- you have a portlib ptr
>>   
> So in the scenario of multiple HyPortLib instances, it can be used to
> specify which one to use?

You are right, when you have multiple instances the simple macros do not
help and you need to revert to -> .

> Then how about document these directives and
> advocation on the port documentation instead of current ones?

Thanks for volunteering ;-)

Regards,
Tim

-- 

Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [classlib][LUNI | NIO] How to write stable tests for blocking write/read operations of Socket and SocketChannel

[Tim Ellison]

Jimmy, Jing Lv wrote:

> however on my workstation(windows XP, RI v1.5.06), the
> testcase you listed below still fails randomly (fails 1 out of 4
> approximately) on RI, is that a bug of RI?

It would be interesting to know if you can reproduce it on other JREs /
platforms.

Regards,
Tim

-- 

Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: svn commit: r416240 - /incubator/harmony/enhanced/classlib/trunk/make/depends.xml

[Tim Ellison]

Nathan Beyer wrote:
> Actually, we probably want to use the 3.2 maintenance URL, at least until
> 3.2 is finalized.
> 
> I've updated the depends.properties to the latest 3.2 maintenance build of
> ecj.jar. Check it out and let me know if there are any issues.

The Continuum build machines do not automatically download new
dependencies (for security reasons), so the build was temporarily broken
but should be fixed now.

(And note to self: the javac tool code needs to be updated to cope with
these updates, since it is currently referencing the ECJ JAR by
hard-coded file name.)

Regards,
Tim


> -Nathan
> 
>> -Original Message-
>> From: Richard Liang [mailto:[EMAIL PROTECTED]
>> Sent: Sunday, June 25, 2006 11:09 AM
>> To: harmony-dev@incubator.apache.org
>> Subject: Re: svn commit: r416240 -
>> /incubator/harmony/enhanced/classlib/trunk/make/depends.xml
>>
>> Hello Mark,
>>
>> The url of ecj.jar has been changed to:
>> http://archive.eclipse.org/eclipse/downloads/drops/S-3.2RC5-
>> 200605191206/ecj.jar.
>> And I'm not sure if we still use the ecj.jar in 3.2RC5 or upgrade to
>> 3.2RC7 :-)
>>
>> Richard.
>>
>> [EMAIL PROTECTED] wrote:
>>> Author: hindessm
>>> Date: Wed Jun 21 22:09:51 2006
>>> New Revision: 416240
>>>
>>> URL: http://svn.apache.org/viewvc?rev=416240&view=rev
>>> Log:
>>> Uncomment ecj.jar dependency.
>>>
>>> Modified:
>>> incubator/harmony/enhanced/classlib/trunk/make/depends.xml
>>>
>>> Modified: incubator/harmony/enhanced/classlib/trunk/make/depends.xml
>>> URL:
>> http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/mak
>> e/depends.xml?rev=416240&r1=416239&r2=416240&view=diff
>> ==
>> 
>>> --- incubator/harmony/enhanced/classlib/trunk/make/depends.xml
>> (original)
>>> +++ incubator/harmony/enhanced/classlib/trunk/make/depends.xml Wed Jun
>> 21 22:09:51 2006
>>> @@ -48,9 +48,7 @@
>>>
>>> > />
>>> -   
>>>
>>> >>srcfile="${signed.bcprov.jar}"
>>>
>>>
>>>
>>>
>> --
>> 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]
> 
> 

-- 

Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: svn commit: r416738 - /incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/init/bootclasspath.properties

[Tim Ellison]

Magnusson, Geir wrote:
> Isn't it better to not have the stubs around at all?  Gets rid of one
> element of uncertainty - load order.

As Mark points out, they are not referenced by the
bootclasspath.properties, which defines the load-order.  However, they
are needed to allow Java code to compile (both our build scripts and our
Javac).

Regards,
Tim

-- 

Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: svn commit: r416738 - /incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/init/bootclasspath.properties

[Tim Ellison]

Ivan Volosyuk wrote:
> I have found solution for this build problem. If somebody interested:
> 
> To use downloaded eclipse (or its compiler) need to run:
> sh build.sh -Dbuild.compiler=org.eclipse.jdt.core.JDTCompilerAdapter
> 
> But the compiler in theis eclipse version doesn't work with jre1.4, so

Not quite sure what this means, since all the Eclipse code only requires
JRE1.4.

Regards,
Tim

> I need to change build.sh, removing:
>  CLASSPATH=$CLASSPATH:`pwd`/make/tmp/org.eclipse.jdt.core_3.1.1.jar
> and changing:
>  CLASSPATH=`pwd`/make/tmp/cpptasks/cpptasks.jar:$CLASSPATH
> in order to use CLASSPATH specified in command line environment. I
> used ecj_3.2RC5 from classlib. After this, compilation works fine.
> 
> I run eclipse with the compiled drlvm and it started fine, except for
> the message:
> ---

-- 

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: syncronization in Charset

[Paulex Yang]

Tim Ellison wrote:

Paulex Yang wrote:
  

Tim,

Good catch! But I'm afraid it not only a test defect, but also a
possible Harmony implementation bug.

The JavaDoc for String says nothing about synchronization, but Charset's
does: " All of the methods defined in this class are safe for use by
multiple concurrent threads.". So it should be safe to invoke
Charset.encode() concurrently.



Yep, so if that had been used then I would have complained differently,
but since String doesn't claim to be thread-safe I moved it out.

  

Looking inside the Charset.encode(CharBuffer), it has got lock on
itself, the cause is the system wide cached CharsetEncoder instance is
not synchronized[1], so if String.getBytes() always use
Charset.forName() to get the cached charset instance for some certain
encoding, the error won't happen. Probably String create a new Charset
every time.



Agreed, if the String was not using the 'lastCharset' it will create
multiple instances.  Not sure why it would have this churn, unless there
was some IO on another thread or something with a different charset.

  

Even so, I think the Charset implementation should be safe
according to spec, so I suggest to also hold lock on the cached
CharsetEncoder during Charset.encode() so that this method is safe
enough to be used concurrently.

comments?



Yes, all instances of Charset should safely use the cached
encoders/decoders.  You may then also be able to reduce the
synchronization of the Charset itself (it would be redundant, but would
not matter if two instances cache the same encoder simultaneously).
  
+1, the Charset.decode() has same issue, I'll raise a JIRA and create 
patch for this.

Regards,
Tim


  

[1] code fragment from Charset.encode()
synchronized public final ByteBuffer encode(CharBuffer buffer) {
  CharsetEncoder e = getCachedCharsetEncoder(canonicalName);
 ...
  try {
// e is not safe for concurrent use
   return e.encode(buffer);
  } catch (CharacterCodingException ex) {
   throw new Error(ex.getMessage(), ex);
  }
}

Tim Ellison wrote:


The failing test does this (amongst other things):

final int THREAD_NUM = 20;
Thread[] thread = new Thread[THREAD_NUM];
for (int i = 0; i < THREAD_NUM; i++) {
thread[i] = new Thread() {
public void run() {
try {
sink
.write(ByteBuffer.wrap("bytes"
*   .getBytes(ISO8859_1)));
} catch (IOException e) {
throw new RuntimeException(e);
}
}
};
}
for (int i = 0; i < THREAD_NUM; i++) {
thread[i].start();
}

If String#getBytes(String) is not thread safe then we are doomed ;-)

How about:


@@ -104,14 +104,13 @@
 public void test_write_LByteBuffer_mutliThread() throws IOException,
 InterruptedException {
 final int THREAD_NUM = 20;
+final byte[] strbytes = "bytes".getBytes(ISO8859_1);
 Thread[] thread = new Thread[THREAD_NUM];
 for (int i = 0; i < THREAD_NUM; i++) {
 thread[i] = new Thread() {
 public void run() {
 try {
-sink
-.write(ByteBuffer.wrap("bytes"
-.getBytes(ISO8859_1)));
+sink.write(ByteBuffer.wrap(strbytes));
 } catch (IOException e) {
 throw new RuntimeException(e);
 }


Regards,
Tim


Apache Harmony Build wrote:

 
  

 [exec] [junit] java.lang.IllegalStateException
 [exec] [junit] at
java.nio.charset.CharsetEncoder.encode(CharsetEncoder.java:480)
 [exec] [junit] at
java.nio.charset.CharsetEncoder.encode(CharsetEncoder.java:347)
 [exec] [junit] at
java.nio.charset.Charset.encode(Charset.java:639)
 [exec] [junit] at
java.lang.String.getBytes(String.java:838)
 [exec] [junit] at
org.apache.harmony.tests.java.nio.channels.SinkChannelTest$1.run(SinkChannelTest.java:112)

 [exec] [junit] Tests FAILED


  
  



  



--
Paulex Yang
China Software Development Lab
IBM



-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: svn commit: r416738 - /incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/init/bootclasspath.properties

[Tim Ellison]

Gregory Shimansky wrote:
> On Sunday 25 June 2006 17:26 Mark Hindess wrote:
>> On 24 June 2006 at 22:38, Tim Ellison <[EMAIL PROTECTED]> wrote:
>>> Mark Hindess wrote:
 On 24 June 2006 at 14:44, Gregory Shimansky <[EMAIL PROTECTED]> 
> wrote:
> Btw I've figured why kernel.jar has to be added to
> bootclasspath.properties before luni.jar. They have many classes with
> the same name but different code (Class, ClassLoader, Thread, System,
> String to mention a few). So if luni.jar goes first in bootclasspath,
> then all of those kernel classes implementations are taken from
> classlib which isn't very good because they should be taken from VM's
> kernel.jar. So there is no surprise that it doesn't work.
 Oops... I can't believe we didn't spot this before! ...
>>> That's a regression :-(  We used to specifically exclude the kernel
>>> patternsets from each JAR packaging step.  I agree that it should be
>>> restored.
>> Yes, it's definitely a regression.  Probably at least partly my fault,
>> so I've fixed it in r417017.
>>
>> Gregory, this should almost fix the ordering issue except for String
>> which has moved out of the kernel classes in to luni.  But as Tim says
>> the real solution is to load the VM's versions of kernel classes first
>> the same way the IBM VME does it.
> 
> Sure I've created a patch to properties parser which adds kernel.jar 
> unconditionally to the beginning of bootclasspath, and filters out everything 
> which isn't beginning with bootclasspath.[0-9] so no *.source and other 
> properties appear in the property.

Ok, that will work. As I said earlier, an alternative is to participate
in the Harmony launcher since it can set up VM-specific options via a
properties file, and create the portlib, etc.  Perhaps that can wait for
a 'round two' ;-)

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]