jtreg testing integrated

[Andrew John Hughes]

snip...
> >  I mention this because I think the
> > term could be a little disparaging to outsiders, as it implies only a
> > build with proprietary Sun code is considered production ready.
> >
>
>  Yes, getting accurate, descriptive, and neutral (and concise) wording can
> be tricky, as "proprietary" is also disparaging in some contexts ;-)
>

Er... it's very much intended to be disparaging.  There's a good basis
for that, whereas I don't see one for simply classifying all other
builds as below the standard of this 'production build' -- well,
outside Sun anyway :)

>
> > I wouldn't add any code to rely on the name of a build from the GPLed
> > code.  It's just asking for trouble further down the line.  Besides,
> > by including such tests, you're effectively wrongly favouring some
> > GPLed distributions over others.
> >
>
>  Well, the tests in question come with the code, both under GPL, so if
> someone wanted to have java.runtime.name=Fred for some reason, the tests in
> question could be updated to expect "Fred" instead.
>
>

I must be missing something but I don't see why:

if (proprietaryBuild)
  doX();
else
  doY();

is a problem, given its the proprietary build that needs a special
case.  Otherwise you're inconveniencing every other build for the sake
of one.

> > Is a test for the production system (with an appropriate comment so we
> > know that's what it is) not sufficient?
> >
>
>  That is probably sufficient for the cases in question.
>
>  There are really three cases of possible interest: Sun's traditional
> (proprietary) product bits, a "usual" OpenJDK build, and something else.  A
> "usual" OpenJDK build perhaps is something yet to come about; I'm thinking
> there may be conventions we all choose to follow as good practices that may
> affect how the tests are written in some way.  A "something else" build
> would, say, be based on the OpenJDK code, but choose to go against usual
> practice in some manner.
>
>  The cases currently under consideration just need to make a decision based
> on "Sun's traditional (proprietary) product" versus "not Sun's traditional
> (proprietary) product."
>

Ah that seems to agree with what I said above :)

>
> >
> > >  For the javax/script tests, I was going to add "if (no javascript
> engine
> > > and production JDK) fail else note/warning" logic so that our production
> > > build gets the same coverage and if an OpenJDK build come with a
> javascript
> > > engine, it would get testing too.
> > >
> > >
> >
> > Wouldn't testing the result of
> > ScriptEngineManager.getEngineFactories() suffice? Why do
> you need to
> > specifically test for a production build?
> >
>
>  In Sun's proprietary product JDK we've chosen to ship a javascript engine;
> this is *not* required by the specification.  The OpenJDK sources do not
> include a javascript engine; although people could add one of course.  I'd
> like the tests to require javascript to be present in Sun's proprietary
> product JDK; otherwise, if a javascript engine happens to be present, it
> should be tested the same way, but not having the engine shouldn't be fatal.
>  This would preserve the same degree of testing of the product bits, allow
> the tests to pass out of the box for an OpenJDK build, and perform the same
> tests for an OpenJDK  build if an engine happens to be present.
>

So I see two things to test for in that case:

1. Is a Javascript implementation provided?
2.  Do we require one as part of this test run?

The latter could be a property, which would be set for a proprietary
build and any other where someone wants to require that a JS
implementation is provided.
I guess a similar case will be needed for SNMP.

>  -Joe
>

-- 
Andrew :-)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8