You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Jesse Wilson <je...@google.com> on 2010/10/05 01:09:43 UTC
Commit to 5 or 6?
Harmony Folks,
I'm planning to do some work on the Harmony 6 tests. I'm planning to do
small improvements: isolating tests for security managers, replace
assertTrue() with assertEquals(), etc. This work will be driven by me trying
to get Android's class library passing Harmony's tests as they appear in
SVN. Currently we only run our own forked copy; that's lame and it doubles
our maintenance burden.
In which branch should I commit these changes? If I commit to the Java 5
branch, then the changes benefit both development trees. I'm not personally
interested in Java 5 anymore, but I can't speak for everyone. But if I
commit to the Java 6 branch, I can immediately take advantage of the
changes. I don't want to think about Java 5 and I'm always running the
complete set of Java 6 tests.
Any guidance?
Thanks.
--
Android libcore team.
office hours <https://sites.google.com/a/google.com/dalvik/office-hours>every
afternoon, 1–5pm
Re: Commit to 5 or 6?
Posted by Tim Ellison <t....@gmail.com>.
On 05/Oct/2010 00:09, Jesse Wilson wrote:
> I'm planning to do some work on the Harmony 6 tests. I'm planning to do
> small improvements: isolating tests for security managers, replace
> assertTrue() with assertEquals(), etc. This work will be driven by me trying
> to get Android's class library passing Harmony's tests as they appear in
> SVN. Currently we only run our own forked copy; that's lame and it doubles
> our maintenance burden.
>
> In which branch should I commit these changes? If I commit to the Java 5
> branch, then the changes benefit both development trees. I'm not personally
> interested in Java 5 anymore, but I can't speak for everyone. But if I
> commit to the Java 6 branch, I can immediately take advantage of the
> changes. I don't want to think about Java 5 and I'm always running the
> complete set of Java 6 tests.
>
> Any guidance?
The preferred option, from my POV, is to commit to the 5 branch, and
merge the changes into the 6 branch. We put fixes and enhancements into
the 5 branch unless they are 6 API specific. If you only commit to 6
then it will make later merges more complex.
Regards,
Tim
Re: Commit to 5 or 6?
Posted by Alexei Fedotov <al...@gmail.com>.
Jesse, Mark,
Thanks for explaining your point!
--
With best regards / с наилучшими пожеланиями,
Alexei Fedotov / Алексей Федотов,
http://dataved.ru/
+7 916 562 8095
On Sun, Oct 10, 2010 at 12:36 AM, Mark Hindess
<ma...@googlemail.com> wrote:
>
> In message <AA...@mail.gmail.com>,
> Jesse Wilson writes:
> >
> > [snip]
> >
> > It comes up less frequently, but I have some other preferences related
> > to better detail messages. When comparing arrays, equals() does the
> > wrong thing. To work around, I compare the string form for primitives:
> >
> > byte[] actual = ...
> > byte[] expected = ...
> > assertEquals(Arrays.toString(actual), Arrays.toString(expected));
> >
> > And the list form for reference types:
> >
> > Object[] actual = ...
> > Object[] expected = ...
> > assertEquals(Arrays.asList(actual), Arrays.asList(expected));
>
> +1 - expected comes first though.
>
> > I'm not actually planning on doing massive scrubbing to change styles
> > or anything. But when I investigate specific problematic tests, it's
> > helpful to fix the test to tell me everything that it can.
>
> +1. I tend to fix them if I see any obvious ones on the commit list but
> sometimes I look at the file and decide it's just too much work for the
> time available.
>
> Regards,
> Mark.
>
>
Re: Commit to 5 or 6?
Posted by Mark Hindess <ma...@googlemail.com>.
In message <AA...@mail.gmail.com>,
Jesse Wilson writes:
>
> [snip]
>
> It comes up less frequently, but I have some other preferences related
> to better detail messages. When comparing arrays, equals() does the
> wrong thing. To work around, I compare the string form for primitives:
>
> byte[] actual = ...
> byte[] expected = ...
> assertEquals(Arrays.toString(actual), Arrays.toString(expected));
>
> And the list form for reference types:
>
> Object[] actual = ...
> Object[] expected = ...
> assertEquals(Arrays.asList(actual), Arrays.asList(expected));
+1 - expected comes first though.
> I'm not actually planning on doing massive scrubbing to change styles
> or anything. But when I investigate specific problematic tests, it's
> helpful to fix the test to tell me everything that it can.
+1. I tend to fix them if I see any obvious ones on the commit list but
sometimes I look at the file and decide it's just too much work for the
time available.
Regards,
Mark.
Re: Commit to 5 or 6?
Posted by Jesse Wilson <je...@google.com>.
On Sat, Oct 9, 2010 at 5:58 AM, Alexei Fedotov <al...@gmail.com>wrote:
> I'm trying to understand best coding practices. Do you mean replacing
> assertTrue to assertEquals for assertions like a = b? isAvailable()
> assertions still may be implemented via assertTrue?
>
Mostly I prefer this:
assertEquals("hotdog", concatenate("hot", "dog"));
Over this:
assertTrue("hotdog".equals(concatenate("hot", "dog")));
If the expression fails, assertEquals() gives more detail in the failure
message. That's pretty non-controversial and we should prefer assertEquals()
when it applies.
It comes up less frequently, but I have some other preferences related to
better detail messages. When comparing arrays, equals() does the wrong
thing. To work around, I compare the string form for primitives:
byte[] actual = ...
byte[] expected = ...
assertEquals(Arrays.toString(actual), Arrays.toString(expected));
And the list form for reference types:
Object[] actual = ...
Object[] expected = ...
assertEquals(Arrays.asList(actual), Arrays.asList(expected));
I'm not actually planning on doing massive scrubbing to change styles or
anything. But when I investigate specific problematic tests, it's helpful to
fix the test to tell me everything that it can.
Cheers,
Jesse
Re: Commit to 5 or 6?
Posted by Alexei Fedotov <al...@gmail.com>.
Jesse,
I'm trying to understand best coding practices. Do you mean replacing
assertTrue to assertEquals for assertions like a = b? isAvailable()
assertions still may be implemented via assertTrue?
--
With best regards / с наилучшими пожеланиями,
Alexei Fedotov / Алексей Федотов,
http://dataved.ru/
+7 916 562 8095
On Tue, Oct 5, 2010 at 3:09 AM, Jesse Wilson <je...@google.com> wrote:
> Harmony Folks,
>
> I'm planning to do some work on the Harmony 6 tests. I'm planning to do
> small improvements: isolating tests for security managers, replace
> assertTrue() with assertEquals(), etc. This work will be driven by me trying
> to get Android's class library passing Harmony's tests as they appear in
> SVN. Currently we only run our own forked copy; that's lame and it doubles
> our maintenance burden.
>
> In which branch should I commit these changes? If I commit to the Java 5
> branch, then the changes benefit both development trees. I'm not personally
> interested in Java 5 anymore, but I can't speak for everyone. But if I
> commit to the Java 6 branch, I can immediately take advantage of the
> changes. I don't want to think about Java 5 and I'm always running the
> complete set of Java 6 tests.
>
> Any guidance?
>
> Thanks.
>
> --
> Android libcore team.
> office hours <https://sites.google.com/a/google.com/dalvik/office-hours>every
> afternoon, 1–5pm
>