Or just put the test in java.lang as an implementation test.
We should resolve this. Among others, we're going to have spec tests,
which Tim and others rightly point out that we need to be careful with
and keep out of the boot classpath to ensure that tests happen in the
context of userland.
[Original Message]
From: Mikhail Loenko [EMAIL PROTECTED]
To: harmony-dev@incubator.apache.org; [EMAIL PROTECTED]
Date: 4/21/06 1:05:26 AM
Subject: Re: [classlib] String is special
Why not put all the tests that control String's behavior to the suite?
Are there any possible harmful
]
To: harmony-dev harmony-dev@incubator.apache.org
Date: 4/20/06 8:12:34 AM
Subject: [classlib] String is special
You'll recall a while ago when we were discussing moving j.l.String out
from KERNEL to LUNI [1] that the shape of String is something we would
expect VMs JITs to be sensitive
of making sure we do not make mistakes
such as what you anticipate that 'svn:needs-lock' can help
out on.
Dan Lydick
[Original Message]
From: Tim Ellison [EMAIL PROTECTED]
To: harmony-dev harmony-dev@incubator.apache.org
Date: 4/20/06 8:12:34 AM
Subject: [classlib] String
I suggest you write a helper method to create a String with that
constructor using reflection (setAccessible(true)).
Regards,
Tim
Nathan Beyer wrote:
Since I probably share some responsibility in the String is special topic
being brought up, I wanted to try out the golden ticket bit for some
So howabout a firmer test that will break when string is changed? that
might at least let you sleep better.
geir
Tim Ellison wrote:
Ok, so reading everyone's post it seems that:
- we agree that there should be some way to ensure people do
not inadvertently modify String's shape, but
You'll recall a while ago when we were discussing moving j.l.String out
from KERNEL to LUNI [1] that the shape of String is something we would
expect VMs JITs to be sensitive to (like all our KERNEL classes), but
that there is significant shared behavior that it is worth sharing
(which is why we
Hi Tim,
I have an objection.
Locking has nothing to do with commit control. Allowing for svn
locking functionality is opening a can of worms. What if somebody
aquires a lock and loses network connectivity for a week (because of a
Hurricane, because he forgot and went on vacation, etc.)? The
Etienne Gagnon wrote:
Hi Tim,
I have an objection.
Sure, that's why I asked!
Locking has nothing to do with commit control.
Yes it does, your commit will fail if I have the lock; but I am abusing
it to achieve a somewhat different goal of 'inadvertent modification'.
Allowing for svn
Tim Ellison wrote:
Yes it does, your commit will fail if I have the lock; but I am abusing
it to achieve a somewhat different goal of 'inadvertent modification'.
OK, we both agree on the abuse part. ;-P
If we cannot contact the lock holder we simply break/steal the lock.
Right. But, locks
Archie Cobbs wrote:
Etienne Gagnon wrote:
Tim Ellison wrote:
Not really. I can add the warning, but I was looking for a way to
ensure people did not mistakenly change String or did not read the
doc/dev list. By failing people's commit and making them explicitly
acquire the token first they
Geir Magnusson Jr wrote:
3) Lock down function and behavior tightly with tests - that if
modified, tests will break, and that should raise an alarm to the
committer.
One easy way would be to add a test that compares the String.java source
code with a saved version, and that fails if unequal.
Etienne Gagnon wrote:
Hi Tim,
I have an objection.
Locking has nothing to do with commit control. Allowing for svn
locking functionality is opening a can of worms. What if somebody
aquires a lock and loses network connectivity for a week (because of a
Hurricane, because he forgot and went on
Since I probably share some responsibility in the String is special topic
being brought up, I wanted to try out the golden ticket bit for some
further enhancements.
I've made some changes to String to add the new Java 5 APIs related to code
points, StringBuilder, etc.
I've posted a proposed
String APIs (code points, StringBuilder, etc) RE:
[classlib] String is special
Since I probably share some responsibility in the String is special
topic
being brought up, I wanted to try out the golden ticket bit for some
further enhancements.
I've made some changes to String to add the new
-lock' can help
out on.
Dan Lydick
[Original Message]
From: Tim Ellison [EMAIL PROTECTED]
To: harmony-dev harmony-dev@incubator.apache.org
Date: 4/20/06 8:12:34 AM
Subject: [classlib] String is special
You'll recall a while ago when we were discussing moving j.l.String out
from KERNEL to LUNI
16 matches
Mail list logo
