Why not put all the tests that control String's behavior to the suite? Are there any possible harmful differences that are untestable?
Thanks, Mikhail 2006/4/21, bootjvm <[EMAIL PROTECTED]>: > > I have been watching this issue closely because it will directly > affect my work on BootJVM with the (minimal) native part > of java.lang.String . I am in favor of a stricter control on this > class in the interest 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 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 to (like all our KERNEL classes), but > > that there is significant shared behavior that it is worth sharing > > (which is why we moved it into LUNI). > > > > I suggested that we could deal with this by ensuring changes to String > > were closely monitored, and any such changes agreed on the list first > > (thereby acquiring a 'golden ticket'). There have been a few changes to > > String recently (I have reviewed them, and they look benign) but I'd > > like to reiterate that call. > > > > To ensure that all committers can continue to update String, but that > > they do so 'knowingly' (i.e. after considering the consequences) I'd > > like to impose a 'positive action' pre-commit step by setting the > > "svn:needs-lock" property on String.java. > > > > That will ensure that committers do not inadvertently (despite their > > thorough diff review) apply a patch that modifies String.java. The > > extra step required would simply be to acquire a lock on String.java > > first and that should be enough to remind people that they are modifying > > this class. > > > > (This is for my benefit as much as anyone else's) > > > > If there are no objections I'll go ahead and do this. > > > > Regards, > > Tim > > > > [1] > > > http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200602.mbox/% > [EMAIL PROTECTED] > > > > -- > > > > Tim Ellison ([EMAIL PROTECTED]) > > IBM Java technology centre, UK. > > > > --------------------------------------------------------------------- > > Terms of use : http://incubator.apache.org/harmony/mailing.html > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > --------------------------------------------------------------------- > Terms of use : http://incubator.apache.org/harmony/mailing.html > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
