Hi Brian,
On May 23, 2008, at 10:11 AM, Brian Murphy wrote:
On Fri, May 23, 2008 at 1:28 AM, Peter Jones <[EMAIL PROTECTED]>
wrote:
[I am curious: why update the old directory tree (trunk/qatests) as
well as the new one (qatests/trunk)?
I'm not sure how much detail you want,
Thanks for indulging me. To the point of my curiosity: your
explanation seems consistent with my previous understanding that I
needn't worry about the old trees (so either choice of yours was fine).
I'm unclear why the old tree is even still visible.]
When the new structure was put in place, Mark B said that
at some point the old directory structure should eventually
be removed, but that hasn't happened yet.
I see that he has just filed an issue to do that-- should remove
confusion from browsing the source trees.
Anyway, I presume that the change to this NameServiceImpl class:
http://svn.apache.org/viewvc/incubator/river/qatests/trunk/source/
vob/qa/src/com/sun/jini/test/impl/reggie/NameServiceImpl.java?
r1=615035&r2=658927&diff_format=h
was done so that it would compile against Sun's JDK 6. Unfortunately,
that makes it no longer compile against earlier Sun JDKs, like 5.0
and
1.4.x.
Are you saying that prior to my commit, you were able to checkout
the distribution and compile the qatests under 5.0 and 1.4.x? Or
simply that they would compile under 1.4.x and 5.0, as long as the
appropriate ant, make, maven, shell, etc. script or command line
was provided?
I wasn't making any claim about the overall compilability of the
qatests area-- I haven't tried to build it all from the River tree
myself.
For my recent River changes, I only tried to run the jtreg suite from
the River tree. My changes were all in the JERI area, which has good
coverage from the jtreg tests, and (as you may recall) the jtreg
tests are what I am most familiar with, so I focused on running
them. In doing so, and running with JDK 6, I encountered this issue
with test classes implementing sun.net.spi.nameservice.NameService--
so when I was skimming through your commits, I gathered that you
encountered the exact same issue with the above reggie test class in
the regular qatests area, hence my comments about the JDK version
dependency above.
I was assuming, perhaps mistakenly, that no one was using the
tests because the make files wouldn't compile the source and
build the jar files correctly, under any jdk version. So I figured
that being able to compile the tests under 1.6 was better than
nothing at all. But if my assumption was wrong about how the
tests are being used, then maybe we should back out the
changes I made. Do you have an opinion?
I suspect that your assumption was right, and I think that it's great
that you have put this effort into improving the situation.
I experimented
with a solution that uses a dynamic proxy implementing NameService
with an invocation handler that obeys whichever version of the
interface it determines to be in effect at runtime.
I would be happy if we could assume JDK 6, but I gather that the
discussion to raise the minimum even to 5.0 is still pending.
Yes it is. And based on how long it took folks to agree on the
project name, I'm guessing a discussion on the jdk version
could take quite some time. So, since we're talking about a
change to a test -- a single test -- not the actual River/Jini source,
I'm not sure I'd choose to wait for the results of that discussion
to provide a means for people to compile and run the tests;
especially given the fact that I was under the impression no one
was using those tests in the first place. If people are going to
be committing changes in the future, it seems like it would be
useful for them to take advantage of the hundreds and hundreds
of regression tests that already exist, rather than committing
on faith, or rolling their own test infrastructure.
Agreed, of course. I probably shouldn't have even mentioned the
"platform Java version" question, because as I said later, it's
really a red herring for this particular test issue. Evolution of
the Java platform API, in general, should never introduce such
incompatibility dilemmas, so it should be possible (and is
important!) to run the tests with a later JDK version.
That said, I'm wondering if there's a proposal implied in your
statement above. Are you maybe proposing that the changes
to the reggie/NameServiceImpl test be rolled back, and then
tell folks that they have to compile the tests under 1.4.x or 1.5?
If yes, then I'm certainly okay with that.
I'm not proposing rolling back your changes or anything else in
particular. I mostly just wanted to share that I had encountered the
same problem that you had evidently encountered, although in a
different River test suite (jtreg vs. the regular qatests), and some
further thoughts about it.
Admittedly, the changes I made were at best, a hack, and I made
them because I didn't think anyone else was going to. I focussed
on 1.6 because my company happens to rely on a number of 1.6
features, but I'm okay with requiring 1.4.x/1.5, if that's what you
were getting at. I just don't want to wait for the endless debates
on the jdk version to complete.
If we have to choose one or the other, then personally, I think that
working with JDK 6 (as you chose) is more useful at this point. But
I will try to look further into the hack to make it work either way.
(It's actually less of a problem for the jtreg tests, because they
are compiled on a per-test basis, so this problem only causes the
affected tests to fail, it doesn't block executing the rest of the
suite.)
Cheers,
-- Peter
