www-jcp-open mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Loughran <ste...@apache.org>
Subject Re: Handling Innovation and Producing an RI
Date Mon, 17 Mar 2008 16:36:06 GMT
Sam Ruby wrote:
> On Mon, Mar 17, 2008 at 7:23 AM, Geir Magnusson Jr. <geir@pobox.com> wrote:
>>  On Mar 17, 2008, at 7:17 AM, Steve Loughran wrote:
>>
>>  > Endre StĂžlsvik wrote:
>>  >
>>  >> Can this be easily copied in other projects? Do one have the
>>  >> dedication from the dumpsters to pull this through, as one has
>>  >> _had_ with Sun on Tomcat? .. or the dedication from other vendors,
>>  >> having full-time employees basically owning the implementation, as
>>  >> JBoss on Tomcat?
>>  >> It most definitely didn't work with IBM on Pluto, IMO.
>>  >
>>  > I think the issue is not so much RI as general code quality.
>>  > Sometimes companies, to great PR, donate truckloads of source to the
>>  > OSS world, including to apache, but neglect to include a single line
>>  > of comment on it. Because in the closed source team, there was
>>  > always fred who understood the database module, and sarah who knew
>>  > the networking side of things. Whenever you had a problem, you knew
>>  > who to walk over and ask.
>>  >
>>  > In the OSS ecosystem, any project that is only understood by a group
>>  > of developers who work for a single vendor, is at risk of the vendor
>>  > changing their plans on a whim. I actually think JBoss is different -
>>  > they are committed to Tomcat and their stack- but again, in Axis1.x,
>>  > a lot of the original IBM axis team suddenly got repurposed to deal
>>  > with internal crises, and others had to (eventually) step into the
>>  > gap, but even there there whole swathes of code we were scared of.
>>  >
>>  > At least with a TCK-driven project, you have a test kit that is the
>>  > effective specification.
>>
>>  That's not always the case - there are many instances where tests in
>>  TCKs are challenged because there are implementation assumptions built
>>  in that can conflict with other spec-complaint implementations.

I'm a firm believer in test-driven specifications: your specification is 
your test suite and vice versa. If you build the test suite after the 
spec, there are always inconsistencies.

That said, I dont think junit or testng are good languages for 
specifying the behaviour of distributed systems.


> 
> Glen Daniels would likely find statements that Axis 1.x was dominated
> by IBM to be amusing.

I dont think they dominated it, but they dominated whole swathes of the 
WSDL- to java code that, when the team got reassigned to focus on 
websphere, got pretty much abandonded without a single comment.

> 
> And to back up Geir's point: Axis 1.x did generate a number of
> successful TCK challenges.
> 
> The TCK was effectively a second test suite, an adjunct to the one we
> already had at the time.  It uncovered a number of bugs.  In the
> initial runs, if memory servers, the largest set was simple Axis bugs.
>  Not JAX RPC compliance issues, but bugs of other sorts.  These second
> largest set was JAX RPC issues.  The remainder (and smallest set of
> the three) were TCK issues.  An example of the latter was that SOAP
> does involve HTTP headers, and HTTP headers have a number of options
> in the way that they are expressed (e.g. quoting).  The TCK at the
> time made a few simplifying assumptions in areas such as these in ways
> that weren't warranted.


heh,  java.net.HttpURL makes a few simplifying assumptions about HTTP 
headers that aren't warranted. Like its cookie handling. or its habit of 
patching the content-length header if the response was too short.

> 
> Given how hard it was to challenge the TCK, in some cases we simply
> complied instead.

which is, in a way, an argument against JCP standards, especially those 
whose TCK is meant to be a secret

-- 
Steve Loughran                  http://www.1060.org/blogxter/publish/5
Author: Ant in Action           http://antbook.org/

Mime
View raw message