harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sergey Soldatov" <sergey.solda...@gmail.com>
Subject Re: [classlib] String is special
Date Fri, 21 Apr 2006 08:33:56 GMT
+1.Unit tests that control the critical behavior usually are more useful
than any kind of locking or byte-to-byte comparison.

On 4/21/06, Mikhail Loenko <mloenko@gmail.com> wrote:
>
> 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 <bootjvm@earthlink.net>:
> >
> > 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 <t.p.ellison@gmail.com>
> > > 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.Stringout
> > > 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/%
> > 3C43FDB1AE.7060807@gmail.com%3E
> > >
> > > --
> > >
> > > Tim Ellison (t.p.ellison@gmail.com)
> > > IBM Java technology centre, UK.
> > >
> > > ---------------------------------------------------------------------
> > > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> > > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> > >
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>


--
Sergey Soldatov
Intel Middleware Products Division

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message