Based on the goal of being least confusing to users, I'm in favour
of matching the behaviour rather than the spec when there is any doubt
- users will expect something that runs on reference jre to run on
harmony and fail in the same way(s).
Based on the same goal, I also think matching 5.0
Mark, IMHO in this case we shouldn't follow RI because Harmony
implementation corresponds to the spec. and it is consistent. I'm not OK
with introducing confusing behavior to our users. Why only string was
selected as invalid? Why not to check string also (RI rejects such
string with
On 4/11/06, Mark Hindess wrote:
Based on the goal of being least confusing to users, I'm in favour
of matching the behaviour rather than the spec when there is any doubt
- users will expect something that runs on reference jre to run on
harmony and fail in the same way(s).
And what if RI
Yes. I was using the failureproperty mechanism. Trying to get this
property propogated back to the top level ant file was what I was
having trouble with.
Using a file as you suggest might help. I'll give that a try shortly...
Incidentally, I'm seeing 12 failures and 3 errors on r393111. (And
Geir Magnusson Jr wrote:
testRequestPasswordAuthentication1()
I mean, why do we want to embed all that crap in the testcase name?
Who cares? The only person that will care is someone fixing when a
testcase breaks, and they'll read the code...
I agree with Geir. May be just 1 is
On 4/11/06, Mark Hindess wrote:
Yes. I was using the failureproperty mechanism. Trying to get this
property propogated back to the top level ant file was what I was
having trouble with.
Using a file as you suggest might help. I'll give that a try shortly...
Incidentally, I'm seeing 12
There are no other opinions but I believe this issue needs broader attention
so I'd like to start another thread.
Harmony has a number of external libraries on the bootclasspath: ICU4C,
Xerces/Xalan. What if an app. uses the same library but another version?
What if library versions are not
Stepan Mishura wrote:
Hi,
I've checked out at morning last updates, built the code base and run the
tests …and there are 24 tests failures!
There are 9 tests failures in
org.apache.harmony.tests.java.nio.channels.DatagramChannelTest – I saw these
failures before from time to time. It seems
No. These:
F
org.apache.harmony.security.asn1.der.DerGeneralizedTimeEDTest.testGeneralizedEncoder
E
org.apache.harmony.security.asn1.der.DerGeneralizedTimeEDTest.testGeneralizedEncoderDecoder01
E
org.apache.harmony.security.asn1.der.DerGeneralizedTimeEDTest.testGeneralizedEncoderDecoder02
F
The same for me + DatagramChannelTest
Thanks,
Stepan.
On 4/11/06, Mark Hindess wrote:
No. These:
F
org.apache.harmony.security.asn1.der.DerGeneralizedTimeEDTest.testGeneralizedEncoder
E
org.apache.harmony.security.asn1.der.DerGeneralizedTimeEDTest.testGeneralizedEncoderDecoder01
E
Hi,
It *seems* like things started failing after I committed the changes for
HARMONY-205 last night. I'm looking into this now. If the investigation
begins to take up too much time I will back the changes out.
Best regards,
George
Stepan Mishura wrote:
The same for me +
We can load those libraries by a dedicated class loader so that they
will be invisible for apps but visible for our 'bridge' classes
Thanks,
Mikhail
2006/4/11, Stepan Mishura [EMAIL PROTECTED]:
There are no other opinions but I believe this issue needs broader attention
so I'd like to start
Mark Hindess wrote:
George is taking a look at the ones I mentioned - which are from our
Linux build.
I see quite a few more (including DatagramChannelTest) on our windows
build.
Our internal Windows build has not been clean for a while now. I am
currently not looking at anything beyond the
Mikhail Loenko wrote:
It's not too late to think about it once again and probably revisit
the decision.
BTW, I don't think of this as a blanket rule-of-law, but rather a
guideline, a motivation for how we make decisions on a bug-by-bug or
issue-by-issue basis.
As I understand goal #1
LvJimmy，Jing wrote:
2006/4/11, Geir Magnusson Jr [EMAIL PROTECTED]:
testRequestPasswordAuthentication1()
I mean, why do we want to embed all that crap in the testcase name? Who
cares? The only person that will care is someone fixing when a testcase
breaks, and they'll read the code...
Mark Hindess wrote:
On 4/11/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote:
My real fear is that we'd collectively forget. Maybe I'm just projecting :)
No comment. ;-)
Pthbbb.
So how about this - why don't we put a text file somewhere (in SVN!) in
which we log major things that
Your suggestion is probably how I would have done it, because I'm lazy.
I'd add output from a try/catch if I thought that I had more
meaningful information to add. is there a fail() that also shows the
stacktrace for the throw exception?
geir
Mikhail Loenko wrote:
I'm evaluating
Mark Hindess wrote:
Yes. I was using the failureproperty mechanism. Trying to get this
property propogated back to the top level ant file was what I was
having trouble with.
I had the same problem. I wanted the whole thing to halt on any
failure, and it didn't work... the top level ant
Just curious (and this isn't a criticism - I'm just as guilty of not
doing this)...
Don't you run the tests before committing?
geir
George Harley wrote:
Hi,
It *seems* like things started failing after I committed the changes for
HARMONY-205 last night. I'm looking into this now. If the
Sanket Sharma wrote:
Hi..
Can anyone put up source tarballs on the site ?
Yes - we should do this in the future for our snapshots - include a src
tarball at the same time.
If no one beats me to it, I'll do one for the latest binary snapshot
that's out there.
I don't want to do one w/
I've submitted a JIRA containing a fix that is something close to what
Stepan suggested. Having module test targets append the name of the
module to a build/test_report/test.errors (or test.failures) and the
top level target fails if those files exist at the end of the run.
The diff to make this
There is code that prints exception name but not the trace.
} catch (Exception e) {
fail(Exception while creating policy file : + e);
}
Thanks,
Mikhail
2006/4/11, Geir Magnusson Jr [EMAIL PROTECTED]:
Your suggestion is probably how I would have done it, because
Mikhail,
I came across one of these the other day, when looking at the
integration of the security tests from HARMNOY-88 IIRC. It did seem
to result in particularly unhelpful output. I think we should fix
them to give more helpful errors in the event of problems.
-Mark.
On 4/11/06, Mikhail
Geir Magnusson Jr wrote:
Just curious (and this isn't a criticism - I'm just as guilty of not
doing this)...
Don't you run the tests before committing?
Hi Geir,
Depends what do you mean by the tests.
The change was completely encapsulated in the text component. I ran the
text tests. I
I did briefly look at adding a source snapshot to the snapshot target
but decided that trying to avoid picking up any non-source files was
too error prone and that the only reliable way to make them is to take
a clean checkout.
While looking at this, I wondered about whether the source snapshot
On 4/11/06, Paulex Yang wrote:
Stepan Mishura wrote:
Hi,
I've checked out at morning last updates, built the code base and run
the
tests …and there are 24 tests failures!
There are 9 tests failures in
org.apache.harmony.tests.java.nio.channels.DatagramChannelTest – I saw
these
On 4/11/06, Mark Hindess wrote:
Personally, obviously, I'd expect people to run the tests before
committing.
However, I notice that since enabling the security tests - which fork
for every test - that the tests take over half an hour to run now on
our Linux build machine. So I can see why
Download a tar ball with a download manager seems to be easier, despite the
size. Further, I believe, casual developers often refrain from downloading the
source as they dont know svn tricks.
My problem is a slow network connection. I have tried downloading via svn but
it just freezes after
So the answer is no?
George Harley wrote:
Geir Magnusson Jr wrote:
Just curious (and this isn't a criticism - I'm just as guilty of not
doing this)...
Don't you run the tests before committing?
Hi Geir,
Depends what do you mean by the tests.
The change was completely encapsulated in the
Stepan Mishura wrote:
On 4/11/06, Mark Hindess wrote:
Personally, obviously, I'd expect people to run the tests before
committing.
However, I notice that since enabling the security tests - which fork
for every test - that the tests take over half an hour to run now on
our Linux build
Mark Hindess wrote:
I did briefly look at adding a source snapshot to the snapshot target
but decided that trying to avoid picking up any non-source files was
too error prone and that the only reliable way to make them is to take
a clean checkout.
Yah, indeed, but that's not too much of a
Mark Hindess wrote:
On 4/11/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote:
Mikhail Loenko wrote:
It's not too late to think about it once again and probably revisit
the decision.
BTW, I don't think of this as a blanket rule-of-law, but rather a
guideline, a motivation for how we make
You are right, we probably should. At the time I was looking at
integration and so trying to avoid making additional changes.
-Mark.
On 4/11/06, Mikhail Loenko [EMAIL PROTECTED] wrote:
why not fix according to the guidlines Stepan has posted in this thread?
Thanks,
Mikhail
2006/4/11, Mark
Have you tried just doing svn co URL in a loop? it should
eventually get you complete...
geir
Sanket Sharma wrote:
Download a tar ball with a download manager seems to be easier, despite the
size. Further, I believe, casual developers often refrain from downloading the
source as they
I forgot the smiley.
I don't think this problem is so odd. Do you really think that
side-effects like this will be that rare?
geir
Geir Magnusson Jr wrote:
So the answer is no?
George Harley wrote:
Geir Magnusson Jr wrote:
Just curious (and this isn't a criticism - I'm just as guilty of
Hi Geir,
From my point of view the answer is yes, I ran the tests for the
patched module. The build/test server picked up the downstream breakages
in the other modules. I fixed matters so that the builds ran again.
Elsewhere in this thread I am trying to cooperate with others to make it
George Harley wrote:
Hi Geir,
From my point of view the answer is yes, I ran the tests for the
patched module. The build/test server picked up the downstream breakages
in the other modules. I fixed matters so that the builds ran again.
Right - I thought we considered the build/test
Perhaps :)
But I'm curious if just iterating his way to the first checkout solves
his problem w/o us having to burden every other person who wants a
source snapshot with a double-size snapshot...
I wish SVN had a mode where .svn and meta information in .svn was there,
and it would populate
Stepan Mishura wrote:
On 4/11/06, Paulex Yang wrote:
Stepan Mishura wrote:
Hi,
I've checked out at morning last updates, built the code base and run
the
tests …and there are 24 tests failures!
There are 9 tests failures in
Geir Magnusson Jr wrote:
I forgot the smiley.
:-)
I don't think this problem is so odd. Do you really think that
side-effects like this will be that rare?
Seriously, I don't really know. The case we have been discussing today
was the first concrete example that I have encountered and I
On 4/3/06, Alex Orlov [EMAIL PROTECTED] wrote:
On 4/3/06, Mark Hindess [EMAIL PROTECTED] wrote:
I did something similar one evening a couple of weeks back. I raised
separate JIRAs about a number of the issues I found and included fixes
and test cases. I've still got numerous outstanding
Geir Magnusson Jr wrote:
Tim Ellison wrote:
The IBM VME comes with a check utility that complains about bad
practices detected in JNI code:
Usage: -Xcheck:jni:[option[,option[,...]]]
...
pedantic perform more thorough, but slower checks
What a cool option. :-)
This is
Geir Magnusson Jr wrote:
George Harley wrote:
Hi Geir,
From my point of view the answer is yes, I ran the tests for the
patched module. The build/test server picked up the downstream
breakages in the other modules. I fixed matters so that the builds
ran again.
Right - I thought we
George Harley wrote:
Geir Magnusson Jr wrote:
George Harley wrote:
Hi Geir,
From my point of view the answer is yes, I ran the tests for the
patched module. The build/test server picked up the downstream
breakages in the other modules. I fixed matters so that the builds
ran again.
On 4/11/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote:
George Harley wrote:
Geir Magnusson Jr wrote:
George Harley wrote:
Hi Geir,
From my point of view the answer is yes, I ran the tests for the
patched module. The build/test server picked up the downstream
breakages in the
Mark Hindess wrote:
On 4/11/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote:
There is a cultural element to it - maybe we keep tabs on who breaks the
build, and that decides who buys the beer next time we all meet...
Not that I object to George buying me beer, but this seems a little
harsh
I have uploaded java.rmi -modified for getting 1.4 bytecode- to JIRA
HARMONY-211
Daniel
- Original Message -
From: Daniel Gandara (JIRA) [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, April 11, 2006 2:52 PM
Subject: [jira] Updated: (HARMONY-211) Contribution of java.rmi
Hi Paulex,
Thanks for the update. Just so you know, I have been able to take the
original patch containing the 5.0 features which mandated a 5.0 compiler
and compile things successfully using the jsr14 target that has been
previously discussed on the list. Making further use of that compiler
We can load those libraries by a dedicated class loader so that they
will be invisible for apps but visible for our 'bridge' classes
Thanks,
Mikhail
Hi,
So you are able to run two different versions of one class within the
one jvm instance? This is cool,
and of course much more elegant
George Harley wrote:
Hi Paulex,
Thanks for the update. Just so you know, I have been able to take the
original patch containing the 5.0 features which mandated a 5.0
compiler and compile things successfully using the jsr14 target that
has been previously discussed on the list. Making further
I think I had the appropriate changes, but I did do another update and build
just in case and it still failed with the same message. Since the error
message mentioned the JAVA_HOME environment variable, I looked and I did
have it setup, but it was pointing to an alternate JRE, which I use for Ant
So it really happens... platform dependency, or platform-release dependenecy
make things in mess.
In my opinion, George Harley's method of grouping test above and in the
threads of matching reference implementation exception behaviour is fairly
good.
And another serious problem leaves here: how
In my opinion, the tests are independent from each other. So every test
start up with its own environment, and release the resources when finished.
In this way, there's no dependancy chain and no mess at all.
Yes, we've met serveral side effect testcases, how about making a list to
warn the
Sounds great! :)
At least one benefit, poeple do not need to write code in 1.4, and then
re-write it to 1.5
2006/4/12, George Harley [EMAIL PROTECTED]:
Hi Paulex,
Thanks for the update. Just so you know, I have been able to take the
original patch containing the 5.0 features which mandated a
Hi Nathan,
Look to readme.txt: Troubleshooting Known Problems
Thanks,
Stepan.
On 4/12/06, Nathan Beyer wrote:
I think I had the appropriate changes, but I did do another update and
build
just in case and it still failed with the same message. Since the error
message mentioned the
On 4/11/06, Paulex Yang wrote:
[SNIP]
I've run tests on Linux. They fail on the same assertion:
[junit] Testcase: testReceiveSend_Block_Normal(
org.apache.harmony.tests.java.nio.channels.DatagramChannelTest):
FAILED
[junit] expected:... but was:localdomain
[junit]
I just uploaded a new zip file to JIRA Harmony-318 that contains the
mods to Harmony Classlib that will allow it to run on an unmodified
generic GNU Classpath JVM.
Some of the issues encountered:
1)
libtool was not behaving. So, I gave up and used raw ld.
2)
dlopen() refused to load the output
Hi George,
Your example looks good for me and I think everybody agreed that we should
organize testing to avoid running all tests for each update: if you fix bug
in 'net' module you don't have to run tests say for 'awt' module but if you
update 'luni' then you have to run tests for all modules.
Hi:
2006/4/12, Stepan Mishura [EMAIL PROTECTED]:
On 4/11/06, Paulex Yang wrote:
[SNIP]
I've run tests on Linux. They fail on the same assertion:
[junit] Testcase: testReceiveSend_Block_Normal(
org.apache.harmony.tests.java.nio.channels.DatagramChannelTest ):
FAILED
59 matches
Mail list logo
