Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #10554 > unrolled thread

Question re testing constructor

Back to article view | Back to comp.lang.java.programmer

Contents

  Question re testing constructor Novice <novice@example..com> - 2011-12-06 15:14 +0000
    Re: Question re testing constructor markspace <-@.> - 2011-12-06 07:23 -0800
      Re: Question re testing constructor Novice <novice@example..com> - 2011-12-06 17:17 +0000
      Re: Question re testing constructor Tom Anderson <twic@urchin.earth.li> - 2011-12-06 21:25 +0000
      Re: Question re testing constructor Ian Shef <invalid@avoiding.spam> - 2011-12-07 00:29 +0000
        Re: Question re testing constructor Patricia Shanahan <pats@acm.org> - 2011-12-06 19:28 -0800
        Re: Question re testing constructor Joshua Cranmer <Pidgeot18@verizon.invalid> - 2011-12-06 22:57 -0600
        Re: Question re testing constructor Lew <lewbloch@gmail.com> - 2011-12-07 07:12 -0800
        Re: Question re testing constructor Lew <lewbloch@gmail.com> - 2011-12-07 07:14 -0800
          Re: Question re testing constructor Ian Shef <invalid@avoiding.spam> - 2011-12-07 15:59 +0000
            Re: Question re testing constructor Ian Shef <invalid@avoiding.spam> - 2011-12-08 19:19 +0000
        Re: Question re testing constructor ilAn <idonot@wantspam.net> - 2011-12-07 20:41 +0200
    Re: Question re testing constructor Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2011-12-06 07:34 -0800
      Re: Question re testing constructor Novice <novice@example..com> - 2011-12-06 17:15 +0000
    Re: Question re testing constructor Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2011-12-06 09:49 -0800
    Re: Question re testing constructor Roedy Green <see_website@mindprod.com.invalid> - 2011-12-06 16:40 -0800
    Re: Question re testing constructor Henk van Voorthuijsen <voorth@xs4all.nl> - 2011-12-07 00:33 -0800

#10554 — Question re testing constructor

I'm writing JUnit test cases for a constructor but have hit a bit of a 
snag. I hope someone here can help.

I've satisfied myself via googling that it makes sense to test constructors 
if they do something that might fail or if they can throw exceptions. The 
constructor in question can throw exceptions so I'm trying to write some 
test cases for it. I've got cases that cause each of the exceptions to be 
thrown but I'm having a bit of a problem with what seemed like the easiest 
test of all: existence.

It seems to me - correct me if I'm wrong - that I can easily test to make 
sure the constructor actually built SOMETHING by testing the object against 
null. That won't prove it created exactly the right object but it will 
prove that something got created. Testing the objects OTHER methods will 
verify that the correct object got created.  

If that is right, then it seems that this should test the existence of the 
object well enough:

    	Set<String> testValues = new HashSet<String>();
    	testValues.add("FF0000");
    	testValues.add("66CC99");
    	
    	for (String key : testValues) {
    		HexColor hexColor = new HexColor(key);
    		if (hexColor == null) {
    			assertTrue("The HexColor has been created for input value, 
" + key + ", but has been found to be null.", false);
    		}
    	}

Unfortunately, the assertTrue() statement gets flagged by the compiler as 
being dead code. Am I right in assuming that it is essentially looking at 
the instantiation of the HexColor class and reasoning that it will 
inevitably create SOMETHING so that hexColor can't possibly be null, 
therefore the assertTrue() can't ever be executed? 

If so, I don't have a problem with that but it leaves me a bit baffled 
about how to test that the constructor created something when I gave it 
good input values. 

Can someone enlighten me on a better way to test this aspect of the 
constructor? Or can I simply assume that the constructor worked as long as 
it didn't actually throw an exception and omit any existence tests?

-- 
Novice

[toc] | [next] | [standalone]

#10555

On 12/6/2011 7:14 AM, Novice wrote:
> Unfortunately, the assertTrue() statement gets flagged by the compiler as
> being dead code. Am I right in assuming that it is essentially looking at
> the instantiation of the HexColor class and reasoning that it will
> inevitably create SOMETHING so that hexColor can't possibly be null,
> therefore the assertTrue() can't ever be executed?

I'm pretty sure, yes.  The "new" operator always has to return an 
object, or throw an error.  Factory methods are just methods, and can 
return null, but new *must* return an object if it completes.

P.S. Don't use assertTrue just to print something.  Just use 
System.out.println, it works fine, and makes your intent more clear.

[toc] | [prev] | [next] | [standalone]

#10562

markspace <-@.> wrote in news:jblc1i$n6u$1@dont-email.me:

> On 12/6/2011 7:14 AM, Novice wrote:
>> Unfortunately, the assertTrue() statement gets flagged by the
>> compiler as being dead code. Am I right in assuming that it is
>> essentially looking at the instantiation of the HexColor class and
>> reasoning that it will inevitably create SOMETHING so that hexColor
>> can't possibly be null, therefore the assertTrue() can't ever be
>> executed? 
> 
> I'm pretty sure, yes.  The "new" operator always has to return an 
> object, or throw an error.  Factory methods are just methods, and can 
> return null, but new *must* return an object if it completes.
> 
Thanks Mark! Pete confirms your understanding in his reply to my question.

> P.S. Don't use assertTrue just to print something.  Just use 
> System.out.println, it works fine, and makes your intent more clear.
> 

No problem. I'd just gotten into the habit of using assertTrue() in my 
tests and didn't think through whether it was actually necessary in this 
case. 



-- 
Novice

[toc] | [prev] | [next] | [standalone]

#10571

On Tue, 6 Dec 2011, markspace wrote:

> On 12/6/2011 7:14 AM, Novice wrote:
>
>> Unfortunately, the assertTrue() statement gets flagged by the compiler 
>> as being dead code.
>
> P.S. Don't use assertTrue just to print something.  Just use 
> System.out.println, it works fine, and makes your intent more clear.

What? No. He's not printing something, he's throwing an AssertionError. 
He wrote:

  assertTrue("The HexColor has been created for input value," + key + ", but has been found to be null.", false);

"assertTrue(s, false)" boils down to "throw new AssertionError(s)". With a 
console-based JUnit runner, that will probably lead to something being 
printed, but it's by no means the same thing as System.out.println. For 
starters, one will lead to the test failing, and the other will not!

The standard idiom for this situation is:

Assert.fail("your message here");

That doesn't do anything more than throw an AssertionError, but it's the 
conventional style.

I imagine you knew this, and were concentrating on the substantive matter 
of the question. I hope you don't mind me pointing it out.

tom

-- 
non, scarecrow, forensics, rituals, bacteria, scientific instruments, ..

[toc] | [prev] | [next] | [standalone]

#10575

ram@zedat.fu-berlin.de (Stefan Ram) wrote in news:null-20111206201830
@ram.dialup.fu-berlin.de:

> markspace <-@.> writes:
>>On 12/6/2011 7:14 AM, Novice wrote:
>>>Unfortunately, the assertTrue() statement gets flagged by the compiler as
>>>being dead code. Am I right in assuming that it is essentially looking at
>>>the instantiation of the HexColor class and reasoning that it will
>>>inevitably create SOMETHING so that hexColor can't possibly be null,
>>>therefore the assertTrue() can't ever be executed?
>>I'm pretty sure, yes. 
> 
>   If the Java compiler is so smart at detecting null values,
>   why does he not also give an error on code like:
> 
> (( java.io.PrintStream )null ).println()
> 
>   ?
> 
> 
Short answer:  Because the JLS says so.  (see the third edition, paragraph 
15.16 where it is explained that most casts are handled at run time).

Aside:  If the method being called (e.g. println()) is static, this is ugly 
but not an error.

Discussion:  The JLS seems to treat casting separately from the operations 
(such as calling a method) that would follow a cast.  It "feels like" this 
doesn't need to be the case.  Thus I agree with Stefan that it "feels like" 
the compiler or an IDE could catch this at compile time (Eclipse does not) if 
the JLS permitted or required it.  Perhaps someone can explain why this is 
not the case.

[toc] | [prev] | [next] | [standalone]

#10579

On 12/6/2011 6:24 PM, Stefan Ram wrote:
> Ian Shef<invalid@avoiding.spam>  writes:
>> ram@zedat.fu-berlin.de (Stefan Ram) wrote in news:null-20111206201830
>> @ram.dialup.fu-berlin.de:
>>> If the Java compiler is so smart at detecting null values,
>>> why does he not also give an error on code like:
>>> (( java.io.PrintStream )null ).println()
>>> ?
>> Short answer:  Because the JLS says so.  (see the third edition, paragraph
>> 15.16 where it is explained that most casts are handled at run time).
>
>    Something similar:
>
>    It is difficult for me to forecast an »unreachable statement« error.
>    For example, I would have expected such an error for
>
> public class Main
> { public static void main( final java.lang.String[] args )
>    { java.lang.System.out.println( "alpha3" );
>      if( true )return;
>      java.lang.System.out.println( "beta3" ); }}
>
>    , but did *not* get one, however, the compiler knows that the
>    beta3 statement *is* unreachable, because he does not care to
>    compile it.
>
>    Omitting the »if( true )« will give an »unreachable statement«
>    error.
>

I think the unreachable statement rules, as well as the definite
assignment rules, juggle three considerations:

1. Have a single definition of what is a compilable Java program,
regardless of what compiler is doing the compiling.

2. Limit the sophistication of the flow analysis the compiler is
required to do.

3. Keep the rules reasonably simple.

There are a lot of special cases that could be detected at compile time,
but that would add to the rules. It could be left up to the compiler,
but then compilers could disagree about whether a given Java program is
valid without any of the compilers involved having an error.

Patricia

[toc] | [prev] | [next] | [standalone]

#10580

On 12/6/2011 8:24 PM, Stefan Ram wrote:
> Ian Shef<invalid@avoiding.spam>  writes:
>> ram@zedat.fu-berlin.de (Stefan Ram) wrote in news:null-20111206201830
>> @ram.dialup.fu-berlin.de:
>>> If the Java compiler is so smart at detecting null values,
>>> why does he not also give an error on code like:
>>> (( java.io.PrintStream )null ).println()
>>> ?
>> Short answer:  Because the JLS says so.  (see the third edition, paragraph
>> 15.16 where it is explained that most casts are handled at run time).
>
>    Something similar:
>
>    It is difficult for me to forecast an »unreachable statement« error.
>    For example, I would have expected such an error for
>
> public class Main
> { public static void main( final java.lang.String[] args )
>    { java.lang.System.out.println( "alpha3" );
>      if( true )return;
>      java.lang.System.out.println( "beta3" ); }}
>
>    , but did *not* get one, however, the compiler knows that the
>    beta3 statement *is* unreachable, because he does not care to
>    compile it.

IIRC, the JLS actually describes why this case does not generate an 
unreachable code exception. The idea is to permit what is, in essence, 
conditional compilation:

class Foo {
   public final static bool DEBUG = false;

   public void frozinate() {
     if (DEBUG)
       log("Frozinating...");
     // ... do real work ...
   }
}

By handling this case, you could switch the value of DEBUG to select or 
unselect some code to be run at runtime; you shouldn't have to eradicate 
all if(DEBUG) code whenever you throw the switch to false.

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth

[toc] | [prev] | [next] | [standalone]

#10593

Stefan Ram wrote:
>   Something similar:
> 
>   It is difficult for me to forecast an �unreachable statement� error.
>   For example, I would have expected such an error for
> 
> public class Main
> { public static void main( final java.lang.String[] args )
>   { java.lang.System.out.println( "alpha3" );
>     if( true )return;
>     java.lang.System.out.println( "beta3" ); }}
> 
>   , but did *not* get one, however, the compiler knows that the
>   beta3 statement *is* unreachable, because he does not care to
>   compile it.
> 
>   Omitting the �if( true )� will give an �unreachable statement�
>   error.

You should read the JLS, 14.21:
"The if statement, whether or not it has an else part, is handled in an unusual 
manner. For this reason, it is discussed separately at the end of this section."

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#10594

Ian Shef wrote:
> Discussion:  The JLS seems to treat casting separately from the operations 
> (such as calling a method) that would follow a cast.  It "feels like" this 
> doesn't need to be the case.  Thus I agree with Stefan that it "feels like" 
> the compiler or an IDE could catch this at compile time (Eclipse does not) if 
> the JLS permitted or required it.  Perhaps someone can explain why this is 
> not the case.

Short answer: Because despite its best efforts, the compiler cannot cure 
stupidity.

The compiler likely sees this as not different from 
'((PrintStream)variable).println()', i.e., as a candidate for a 
'NullPointerException' rather than a compiler error.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#10595

Lew <lewbloch@gmail.com> wrote in
news:26281492.354.1323270874867.JavaMail.geo-discussion-forums@pret21: 

> Ian Shef wrote:
>> Discussion:  The JLS seems to treat casting separately from the
>> operations (such as calling a method) that would follow a cast.  It
>> "feels like" this doesn't need to be the case.  Thus I agree with
>> Stefan that it "feels like" the compiler or an IDE could catch this at
>> compile time (Eclipse does not) if the JLS permitted or required it. 
>> Perhaps someone can explain why this is not the case.
> 
> Short answer: Because despite its best efforts, the compiler cannot cure
> stupidity.

Agreed.

> 
> The compiler likely sees this as not different from 
> '((PrintStream)variable).println()', i.e., as a candidate for a 
> 'NullPointerException' rather than a compiler error.

That would seem to be the intent of the JLS.  The compiler follows the rules 
laid down by the JLS.

On the other hand, there are many places in the JLS where constants or 
literals are treated specially, and where responsibility is shared between 
the compiler and the JVM.  Casts are not treated this way and are the 
responsibility of the JVM (with some minor exceptions, such as when the 
compiler can guarantee that a cast is unnecessary e.g., a widening reference 
conversion).

My preference is to find such errors as early as possible.  However, the 
compiler can't save programmers from all folly.  _Java Puzzlers_ by Joshua 
Bloch and Neal Gafter has other examples where a cast is "obviously" an error  
but it won't be caught until run time.  [My copy of the book is currently 25 
miles away, so I can't provide a more precise reference.] 

[toc] | [prev] | [next] | [standalone]

#10611

Ian Shef <invalid@avoiding.spam> wrote in
news:Xns9FB45B83313A1vaj4088ianshef@138.125.254.103: 

> Lew <lewbloch@gmail.com> wrote in
> news:26281492.354.1323270874867.JavaMail.geo-discussion-forums@pret21: 
> 
>> Ian Shef wrote:
>>> Discussion:  The JLS seems to treat casting separately from the
>>> operations (such as calling a method) that would follow a cast.  It
>>> "feels like" this doesn't need to be the case.  Thus I agree with
>>> Stefan that it "feels like" the compiler or an IDE could catch this at
>>> compile time (Eclipse does not) if the JLS permitted or required it. 
>>> Perhaps someone can explain why this is not the case.
>> 
>> Short answer: Because despite its best efforts, the compiler cannot
>> cure stupidity.
> 
> Agreed.
> 
>> 
>> The compiler likely sees this as not different from 
>> '((PrintStream)variable).println()', i.e., as a candidate for a 
>> 'NullPointerException' rather than a compiler error.
> 
> That would seem to be the intent of the JLS.  The compiler follows the
> rules laid down by the JLS.
> 
> On the other hand, there are many places in the JLS where constants or 
> literals are treated specially, and where responsibility is shared
> between the compiler and the JVM.  Casts are not treated this way and
> are the responsibility of the JVM (with some minor exceptions, such as
> when the compiler can guarantee that a cast is unnecessary e.g., a
> widening reference conversion).
> 
> My preference is to find such errors as early as possible.  However, the
> compiler can't save programmers from all folly.  _Java Puzzlers_ by
> Joshua Bloch and Neal Gafter has other examples where a cast is
> "obviously" an error  but it won't be caught until run time.  [My copy
> of the book is currently 25 miles away, so I can't provide a more
> precise reference.] 
> 

I now have the book in my hands (5th Printing  June 2008).  The third 
program in "Puzzle 50: Not Your Type" looks like this:

public class Type3 {
    public static void main(String args[]) {
        Type3 t3 = (Type3) new Object();
    }
}

Any typos are mine, not the authors'.

SPOILER ALERT










This program compiles but fails at run time.  The compiler (per the JLS) 
requires that Object be a subtype of Type3, or vice versa.

The authors write "Although it is obvious to us that this cast will fail, 
the type system is not powerful enough to know that the run-time type of 
the expression  new Object()  cannot be a subtype of Type3.  Therefore, the 
program throws a  ClassCastException  at run time."

The first and second programs of this puzzle involve instanceof, which has 
behavior which is closely related to that of the cast operator.  Although 
the programs are quite simple, the results are counterintuitive (but in 
accordance with the JLS).

[toc] | [prev] | [next] | [standalone]

#10596

ram@zedat.fu-berlin.de (Stefan Ram) writes:

> Ian Shef <invalid@avoiding.spam> writes:
>>ram@zedat.fu-berlin.de (Stefan Ram) wrote in news:null-20111206201830
>>@ram.dialup.fu-berlin.de:
>>>If the Java compiler is so smart at detecting null values,
>>>why does he not also give an error on code like:
>>>(( java.io.PrintStream )null ).println()
>>>?
>>Short answer:  Because the JLS says so.  (see the third edition, paragraph 
>>15.16 where it is explained that most casts are handled at run time).
>
>   Something similar:
>
>   It is difficult for me to forecast an »unreachable statement« error.
>   For example, I would have expected such an error for
>
> public class Main
> { public static void main( final java.lang.String[] args )
>   { java.lang.System.out.println( "alpha3" );
>     if( true )return;
>     java.lang.System.out.println( "beta3" ); }}
>
>   , but did *not* get one, however, the compiler knows that the
>   beta3 statement *is* unreachable, because he does not care to
>   compile it.
>
>   Omitting the »if( true )« will give an »unreachable statement«
>   error.

I find that quite useful, when I am debugging and want to exclude a
bunch of code.. and still compile it.

--
ilAn

[toc] | [prev] | [next] | [standalone]

#10557

On 12/6/11 7:14 AM, Novice wrote:
> [...]
> I've satisfied myself via googling that it makes sense to test constructors
> if they do something that might fail or if they can throw exceptions. The
> constructor in question can throw exceptions so I'm trying to write some
> test cases for it. I've got cases that cause each of the exceptions to be
> thrown but I'm having a bit of a problem with what seemed like the easiest
> test of all: existence.
>
> It seems to me - correct me if I'm wrong - that I can easily test to make
> sure the constructor actually built SOMETHING by testing the object against
> null. [...]

Sorry.  You're wrong.  :)  Simply executing the next statement following 
the use of "new" is all the confirmation you need "to make sure the 
constructor actually built SOMETHING".  Testing against "null" yields no 
additional information.

As "markspace" says, the "new" operator always returns a new object. 
The only way for it to fail is to throw an exception, in which case the 
"new" operator never actually returns per se (and so any code that 
follows it is reachable only the case where it returns a non-null value).

So you don't need to test for existence.  Checking for a "null" return 
value will needlessly verify that "new" succeeded, but cannot detect 
failure because that's not how "new" reports a failure.  Just test the 
exceptions as you're already doing.

Pete

[toc] | [prev] | [next] | [standalone]

#10561

Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> wrote in
news:s8adnYgtFe-Nq0PTnZ2dnUVZ_oGdnZ2d@posted.palinacquisition: 

> On 12/6/11 7:14 AM, Novice wrote:
>> [...]
>> I've satisfied myself via googling that it makes sense to test
>> constructors if they do something that might fail or if they can
>> throw exceptions. The constructor in question can throw exceptions so
>> I'm trying to write some test cases for it. I've got cases that cause
>> each of the exceptions to be thrown but I'm having a bit of a problem
>> with what seemed like the easiest test of all: existence.
>>
>> It seems to me - correct me if I'm wrong - that I can easily test to
>> make sure the constructor actually built SOMETHING by testing the
>> object against null. [...]
> 
> Sorry.  You're wrong.  :)  Simply executing the next statement
> following the use of "new" is all the confirmation you need "to make
> sure the constructor actually built SOMETHING".  Testing against
> "null" yields no additional information.
> 
> As "markspace" says, the "new" operator always returns a new object. 
> The only way for it to fail is to throw an exception, in which case
> the "new" operator never actually returns per se (and so any code that
> follows it is reachable only the case where it returns a non-null
> value). 
> 
> So you don't need to test for existence.  Checking for a "null" return
> value will needlessly verify that "new" succeeded, but cannot detect 
> failure because that's not how "new" reports a failure.  Just test the
> exceptions as you're already doing.
> 

Thanks Pete! You and markspace have clarified things for me and saved me 
some work to boot since I can now delete the existence tests.


-- 
Novice

[toc] | [prev] | [next] | [standalone]

#10565

On 12/6/11 7:14 AM, Novice wrote:
> I'm writing JUnit test cases for a constructor but have hit a bit of a
> snag. I hope someone here can help.
>
> I've satisfied myself via googling that it makes sense to test constructors
> if they do something that might fail or if they can throw exceptions. The
> constructor in question can throw exceptions so I'm trying to write some
> test cases for it. I've got cases that cause each of the exceptions to be
> thrown but I'm having a bit of a problem with what seemed like the easiest
> test of all: existence.
>
> It seems to me - correct me if I'm wrong - that I can easily test to make
> sure the constructor actually built SOMETHING by testing the object against
> null. That won't prove it created exactly the right object but it will
> prove that something got created. Testing the objects OTHER methods will
> verify that the correct object got created.
>
> If that is right, then it seems that this should test the existence of the
> object well enough:
>
>      	Set<String>  testValues = new HashSet<String>();
>      	testValues.add("FF0000");
>      	testValues.add("66CC99");
>      	
>      	for (String key : testValues) {
>      		HexColor hexColor = new HexColor(key);
>      		if (hexColor == null) {
>      			assertTrue("The HexColor has been created for input value,
> " + key + ", but has been found to be null.", false);
>      		}
>      	}
>
> Unfortunately, the assertTrue() statement gets flagged by the compiler as
> being dead code. Am I right in assuming that it is essentially looking at
> the instantiation of the HexColor class and reasoning that it will
> inevitably create SOMETHING so that hexColor can't possibly be null,
> therefore the assertTrue() can't ever be executed?
>
> If so, I don't have a problem with that but it leaves me a bit baffled
> about how to test that the constructor created something when I gave it
> good input values.
>
> Can someone enlighten me on a better way to test this aspect of the
> constructor? Or can I simply assume that the constructor worked as long as
> it didn't actually throw an exception and omit any existence tests?
>

Tests work best if you think about pre-conditions and post-conditions.

Test 1:
Pre condition: I pass these objects to a constructor...
Expected post conditions: I have an object with these state/behavior.

Test 2:
Pre condition: I pass these other objects to a constructor...
Expected post condition: Constructor throws NullPointerException.


Etc...

So, if your constructor is non-trivial, you should be able to interact 
with the object to verify the constructor did its job.

[toc] | [prev] | [next] | [standalone]

#10576

On Tue, 6 Dec 2011 15:14:18 +0000 (UTC), Novice <novice@example..com>
wrote, quoted or indirectly quoted someone who said :

>
>It seems to me - correct me if I'm wrong - that I can easily test to make 
>sure the constructor actually built SOMETHING by testing the object against 
>null. 

The idea is to test YOUR code not Sun/Oracle's .  Constructors never
produce null and never produce objects of the wrong type.  Factories
might, but not constructors.  

What you might want is an assert that makes sure you remembered to
init all necessary fields in the object.
-- 
Roedy Green Canadian Mind Products
http://mindprod.com
For me, the appeal of computer programming is that
even though I am quite a klutz,
I can still produce something, in a sense
perfect, because the computer gives me as many
chances as I please to get it right.
 

[toc] | [prev] | [next] | [standalone]

#10581

On Dec 6, 4:14 pm, Novice <novice@example..com> wrote:

>
> If that is right, then it seems that this should test the existence of the
> object well enough:
>
>         Set<String> testValues = new HashSet<String>();
>         testValues.add("FF0000");
>         testValues.add("66CC99");
>
>         for (String key : testValues) {
>                 HexColor hexColor = new HexColor(key);
>                 if (hexColor == null) {
>                         assertTrue("The HexColor has been created for input value,
> " + key + ", but has been found to be null.", false);
>                 }
>         }

To assert an objects existence, use assertNotNull().

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web