Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: neutral (herse.apache.org: 216.86.168.178 is neither permitted
 nor denied by domain of geir@pobox.com)
Message-ID: <45671CDA.5080307@pobox.com>
Date: Fri, 24 Nov 2006 11:24:58 -0500
From: "Geir Magnusson Jr." <geir@pobox.com>
Reply-To: geir@pobox.com
User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025)
MIME-Version: 1.0
To: dev@harmony.apache.org
Subject: Re: [classlib] Getting more real JAPI results
References: <45655DE2.6050407@apache.org>
In-Reply-To: <45655DE2.6050407@apache.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


Stefano Mazzocchi wrote:
> There is a simple way to make japi happy and show those nice 100% green
> bars: write a stub method and throw a runtime exception when invoked.
> 
> Unfortunately, it's not going to fool the TCK or, worse, it's not going
> to please our users when they get RuntimeException telling them that
> their app won't run because the method is not implemented.

Why would you want to do this?  Having JAPI tell us what's not done is 
the point of JAPI, right?

(Although I'm a compassionate and caring person, I'll admit I'm not 
worried about making JAPI happy...)

> 
> I've written a script that uses brute force across the entire classlib
> to figure out if a method was not implemented, the result can be found at:
> 
>  http://67.86.14.213:10000/results/latest/notimplemented.html
> 
> as of today, there are 615 methods (mostly in swing, awt, imageio and
> sound) that are not implemented, in 64 different classes

Cool!  But I'm misunderstanding something - why are we fooling JAPI?

.
> 
> There is a wide range of ways that we use to throw the fact that the
> method is not implemented, namely:
> 
> throw new Error("ComponentUI.createUI not implemented");
> throw new Error("getHelpMenu() hasn't been implemented yet");
> throw new Error("not yet implemented");
> throw new Error("Not yet implemented");
> throw new Error("setHelpMenu() hasn't been implemented yet");
> throw new IllegalArgumentException("method is not implemented");
> throw new LoginException();//FIXME not yet implemented
> throw new RuntimeException();//FIXME not implemented yet
> throw new RuntimeException("Is not implemented yet"); //FIXME
> throw new RuntimeException("KerberosErrorMessage encoder is not
> implemented");
> throw new RuntimeException("Method is not implemented");
> throw new RuntimeException("Not implemented");
> throw new SocketException("Unbound server socket: not implemented");
> throw new SocketException("Unbound socket: not implemented");
> throw new UnsupportedOperationException("not implemented");
> throw new UnsupportedOperationException("Not implemented");
> throw new UnsupportedOperationException("Not implemented tag: " + tag);
> throw new UnsupportedOperationException("not implemented yet");
> throw new UnsupportedOperationException("Not implemented yet");
> throw new UnsupportedOperationException("Not yet implemented");
> 
> JAPI is designed to support looking into methods that throw an exception
> that ends with .NotImplementedException. Such an exception actually
> exists in our classlib
> 
> modules/luni/src/main/java/org/apache/harmony/luni/util/NotImplementedException.java
> 
> but the only class that uses it, it's a test that tests the exception
> itself. Not that useful.
> 
> It doesn't help us if we cheat on JAPI results, sooner or later we'll
> have to work on those methods anyway, so it's better to keep them
> visible in our API coverage reports so that it's easier for volunteers
> to know where to donate their work.
> 
> I propose that we change all those exception into
> o.a.h.luni.util.NotImplementeException so that JAPI can pick them up and
> show us real results and we do it sooner rather than later.
> 
> Thoughts?

I don't understand why we're fooling JAPI.  I'll read the rest of this 
thread (was offline yesterday for thanksgiving holiday here in the US...)

geir

>