Re: OT: Stepwise gone
Hi Joe; Most of the articles on there are fairly old, but my WO articles are PDF'ed on my web site if anybody wants them. It's sad to see the site go as it was the main source of news in the NeXT days, but I guess those days are long gone. cheers. > Scott took his site down as noted below. > http://www.stepwise.com/ ___ Andrew Lindesay www.lindesay.co.nz ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
OT: Stepwise gone
Scott took his site down as noted below. http://www.stepwise.com/ Every once in a while there is mention of an article or info that was posted there. He deleted it all. So, someone cache anything relevant, its the right time to move it to the wiki. ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: [OT] Weird Boolean/ Wrapper class bug
On 22/11/2009, at 12:44 PM, Shravan Kumar. M wrote: > Thanks for your example and analysis Mike. When I run your example from a > simple file over command-line everything is fine and when I put this code > this Application.java, even then its fine... > This is why it's important to include the EXACT source that causes the error, not something that looks close enough. > But the error happens from a EO class and when I debug and test this code > snippet in Display view, same error is shown there... so, the problem is > getting more interesting and fuzzy. One thing I can surely say, error is > inconsistent and is reproducible. If so, the error is more than likely in your EO, probably the method call that you didn't show us is returning a boolean instead of a Boolean Something like this in your EO could cause this: private Boolean _blah; public boolean blah() { return _blah; } -- Seeya...Q Quinton Dolan - qdo...@gmail.com Gold Coast, QLD, Australia (GMT+10) ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: [OT] Weird Boolean/ Wrapper class bug
Thanks for your example and analysis Mike. When I run your example from a simple file over command-line everything is fine and when I put this code this Application.java, even then its fine... But the error happens from a EO class and when I debug and test this code snippet in Display view, same error is shown there... so, the problem is getting more interesting and fuzzy. One thing I can surely say, error is inconsistent and is reproducible. My java full version: java full version "1.5.0_16-b06-284" Thank You, Shravan Kumar. M - Re: [OT] Weird Boolean/ Wrapper class bug November 22, 2009 7:39:08 AM GMT+05:30 From: "Mike Schrag" To: "WO Dev Group" Incidentally, boxing/unboxing actually happens at compile time ... Once you run that code and verify if it works or not, then do the same inside of Eclipse and see if it fails (assuming you are compiling this from eclipse not javac). If that fails, run javap -c Test and you can see the decompiled code ... There should be no boxing/unboxing calls (basically, you shouldn't see an invokevirtual except for the println), you should just see an ifnull. ms On Nov 21, 2009, at 9:02 PM, Mike Schrag wrote: I just tested that code under JDK 1.5.0_16-b06-275 on Tiger and it works for me. Incidentally, my rule of thumb is "if you think it's a VM, you're wrong. it's your fault." This rule of thumb has never failed me. > > >In a sample java file: > > >public class Test { >public static void main(String[] args) { >Boolean a = null; >if(a != null) >System.out.println("s"); >else >System.out.println("n"); >} >} > > >emerald:~ local$ java -fullversion >java full version "1.5.0_16-b06-275" >emerald:~ local$ javac Test.java >emerald:~ local$ java Test >n > > >javac that and run it and see if that fails for you. > > >ms > > >On Nov 21, 2009, at 7:55 PM, Shravan Kumar. M wrote: > >Hello Mike, >> >> >>Its the same code I have showed you (except that I changed variable names for >>simplicity), and there is no line of code that is missing. Where "a" is the >>EO property and when I check for it ( if(a != null) JRE throws NPE and when >>I check for if(a == null), JRE enjoys ), its throwing exception as stated. I >>believe this is a bug with JRE, and it seems to be fixed as per David's >>testing in later versions of JRE. >> >> >>I think fix would be JRE shouldn't have unboxed it if its null... and they >>seems to have realized this mistake in later versions of JRE... But its >>wondering how a null & not null check differs in this world and they are not >>same from JRE perspective!!! If its an error it should have thrown error >>always... >> >> >>Thank You, >>Shravan Kumar. M >> >> >> From: Mike Schrag >>To: Shravan Kumar. M >>Cc: WO Dev Group >>Sent: Sat, November 21, 2009 9:26:57 PM >>Subject: Re: [OT] Weird Boolean/ Wrapper class bug >> >>You're not pasting the real code, I don't think. I suspect you're just >>getting screwed by autoboxing in whatever code you're not showing. If you >>have: >> >> >>Boolean a = null; >>boolean b = a; >> >> >>That will result in a NPE as auto-unboxing attempts to unbox a into a >>boolean, which throws a NPE. Somewhere in the code you didn't include is an >>unbox into a boolean (little b) of your null Boolean. >> >> >>So, for instance: >> >> >>Boolean a = null; >>if (a) { >>} >> >> >>will NPE. Look more closely at the exact code, specifically the line of code >>that actually failing, and make sure you're not getting an unbox. >> >> >>ms >> >> >>On Nov 21, 2009, at 10:23 AM, Shravan Kumar. M wrote: >> >>Hello Group, >>> >>> >>>Boolean a = null; >>>if(a != null) >>>System.out.println("s"); >>>else >>>System.out.println("n"); >>>-- >>>Above code block raises NullPointerException, where as below one runs >>>successfully!!! Same is the case with any wrapper class (Integer, Long, ...). >>>*Its wondering what it makes difference in checking (a != null) and (a == >>>null)? Its just an Object check rt!* >>> >>> >>>Exact exception: java.lang.NullPointerException at booleanValue() >>>-- >>>Boolean a = null; >>>if(a == null) >>>System.out.println("s"); >>>else >>>System.out.println("n"); >>> >>> >>>Thank You, >>>Shravan Kumar. M >>> >>>___ >>>Do not post admin requests to the list. They will be ignored. >>>Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) >>>Help/Unsubscribe/Update your Subscription: >>>http://lists.apple.com/mailman/options/webobjects-dev/mschrag%40mdimension.com >>> >>>This email sent to msch...@mdimension.com >> >> >___ >Do not post admin requests to the list. They will be ignored. >Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) >Help/Unsubscribe/Update your Subs
Re: [OT] Weird Boolean/ Wrapper class bug
Incidentally, boxing/unboxing actually happens at compile time ... Once you run that code and verify if it works or not, then do the same inside of Eclipse and see if it fails (assuming you are compiling this from eclipse not javac). If that fails, run javap -c Test and you can see the decompiled code ... There should be no boxing/unboxing calls (basically, you shouldn't see an invokevirtual except for the println), you should just see an ifnull. ms On Nov 21, 2009, at 9:02 PM, Mike Schrag wrote: > I just tested that code under JDK 1.5.0_16-b06-275 on Tiger and it works for > me. Incidentally, my rule of thumb is "if you think it's a VM, you're wrong. > it's your fault." This rule of thumb has never failed me. > > In a sample java file: > > public class Test { > public static void main(String[] args) { > Boolean a = null; > if(a != null) > System.out.println("s"); > else > System.out.println("n"); > } > } > > emerald:~ local$ java -fullversion > java full version "1.5.0_16-b06-275" > emerald:~ local$ javac Test.java > emerald:~ local$ java Test > n > > javac that and run it and see if that fails for you. > > ms > > On Nov 21, 2009, at 7:55 PM, Shravan Kumar. M wrote: > >> Hello Mike, >> >> Its the same code I have showed you (except that I changed variable names >> for simplicity), and there is no line of code that is missing. Where "a" is >> the EO property and when I check for it ( if(a != null) JRE throws NPE and >> when I check for if(a == null), JRE enjoys ), its throwing exception as >> stated. I believe this is a bug with JRE, and it seems to be fixed as per >> David's testing in later versions of JRE. >> >> I think fix would be JRE shouldn't have unboxed it if its null... and they >> seems to have realized this mistake in later versions of JRE... But its >> wondering how a null & not null check differs in this world and they are not >> same from JRE perspective!!! If its an error it should have thrown error >> always... >> >> Thank You, >> Shravan Kumar. M >> >> From: Mike Schrag >> To: Shravan Kumar. M >> Cc: WO Dev Group >> Sent: Sat, November 21, 2009 9:26:57 PM >> Subject: Re: [OT] Weird Boolean/ Wrapper class bug >> >> You're not pasting the real code, I don't think. I suspect you're just >> getting screwed by autoboxing in whatever code you're not showing. If you >> have: >> >> Boolean a = null; >> boolean b = a; >> >> That will result in a NPE as auto-unboxing attempts to unbox a into a >> boolean, which throws a NPE. Somewhere in the code you didn't include is an >> unbox into a boolean (little b) of your null Boolean. >> >> So, for instance: >> >> Boolean a = null; >> if (a) { >> } >> >> will NPE. Look more closely at the exact code, specifically the line of code >> that actually failing, and make sure you're not getting an unbox. >> >> ms >> >> On Nov 21, 2009, at 10:23 AM, Shravan Kumar. M wrote: >> >>> Hello Group, >>> >>> Boolean a = null; >>> if(a != null) >>> System.out.println("s"); >>> else >>> System.out.println("n"); >>> >>> -- >>> Above code block raises NullPointerException, where as below one runs >>> successfully!!! Same is the case with any wrapper class (Integer, Long, >>> ...). >>> *Its wondering what it makes difference in checking (a != null) and (a == >>> null)? Its just an Object check rt!* >>> >>> Exact exception: java.lang.NullPointerException at booleanValue() >>> -- >>> >>> Boolean a = null; >>> if(a == null) >>> System.out.println("s"); >>> else >>> System.out.println("n"); >>> >>> Thank You, >>> Shravan Kumar. M >>> >>> >>> ___ >>> Do not post admin requests to the list. They will be ignored. >>> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) >>> Help/Unsubscribe/Update your Subscription: >>> http://lists.apple.com/mailman/options/webobjects-dev/mschrag%40mdimension.com >>> >>> This email sent to msch...@mdimension.com >> >> >> > > ___ > Do not post admin requests to the list. They will be ignored. > Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) > Help/Unsubscribe/Update your Subscription: > http://lists.apple.com/mailman/options/webobjects-dev/mschrag%40mdimension.com > > This email sent to msch...@mdimension.com ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: [OT] Weird Boolean/ Wrapper class bug
I just tested that code under JDK 1.5.0_16-b06-275 on Tiger and it works for me. Incidentally, my rule of thumb is "if you think it's a VM, you're wrong. it's your fault." This rule of thumb has never failed me. In a sample java file: public class Test { public static void main(String[] args) { Boolean a = null; if(a != null) System.out.println("s"); else System.out.println("n"); } } emerald:~ local$ java -fullversion java full version "1.5.0_16-b06-275" emerald:~ local$ javac Test.java emerald:~ local$ java Test n javac that and run it and see if that fails for you. ms On Nov 21, 2009, at 7:55 PM, Shravan Kumar. M wrote: > Hello Mike, > > Its the same code I have showed you (except that I changed variable names for > simplicity), and there is no line of code that is missing. Where "a" is the > EO property and when I check for it ( if(a != null) JRE throws NPE and when > I check for if(a == null), JRE enjoys ), its throwing exception as stated. I > believe this is a bug with JRE, and it seems to be fixed as per David's > testing in later versions of JRE. > > I think fix would be JRE shouldn't have unboxed it if its null... and they > seems to have realized this mistake in later versions of JRE... But its > wondering how a null & not null check differs in this world and they are not > same from JRE perspective!!! If its an error it should have thrown error > always... > > Thank You, > Shravan Kumar. M > > From: Mike Schrag > To: Shravan Kumar. M > Cc: WO Dev Group > Sent: Sat, November 21, 2009 9:26:57 PM > Subject: Re: [OT] Weird Boolean/ Wrapper class bug > > You're not pasting the real code, I don't think. I suspect you're just > getting screwed by autoboxing in whatever code you're not showing. If you > have: > > Boolean a = null; > boolean b = a; > > That will result in a NPE as auto-unboxing attempts to unbox a into a > boolean, which throws a NPE. Somewhere in the code you didn't include is an > unbox into a boolean (little b) of your null Boolean. > > So, for instance: > > Boolean a = null; > if (a) { > } > > will NPE. Look more closely at the exact code, specifically the line of code > that actually failing, and make sure you're not getting an unbox. > > ms > > On Nov 21, 2009, at 10:23 AM, Shravan Kumar. M wrote: > >> Hello Group, >> >> Boolean a = null; >> if(a != null) >> System.out.println("s"); >> else >> System.out.println("n"); >> >> -- >> Above code block raises NullPointerException, where as below one runs >> successfully!!! Same is the case with any wrapper class (Integer, Long, ...). >> *Its wondering what it makes difference in checking (a != null) and (a == >> null)? Its just an Object check rt!* >> >> Exact exception: java.lang.NullPointerException at booleanValue() >> -- >> >> Boolean a = null; >> if(a == null) >> System.out.println("s"); >> else >> System.out.println("n"); >> >> Thank You, >> Shravan Kumar. M >> >> >> ___ >> Do not post admin requests to the list. They will be ignored. >> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) >> Help/Unsubscribe/Update your Subscription: >> http://lists.apple.com/mailman/options/webobjects-dev/mschrag%40mdimension.com >> >> This email sent to msch...@mdimension.com > > > ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: [OT] Weird Boolean/ Wrapper class bug
Hello Mike, Its the same code I have showed you (except that I changed variable names for simplicity), and there is no line of code that is missing. Where "a" is the EO property and when I check for it ( if(a != null) JRE throws NPE and when I check for if(a == null), JRE enjoys ), its throwing exception as stated. I believe this is a bug with JRE, and it seems to be fixed as per David's testing in later versions of JRE. I think fix would be JRE shouldn't have unboxed it if its null... and they seems to have realized this mistake in later versions of JRE... But its wondering how a null & not null check differs in this world and they are not same from JRE perspective!!! If its an error it should have thrown error always... Thank You, Shravan Kumar. M From: Mike Schrag To: Shravan Kumar. M Cc: WO Dev Group Sent: Sat, November 21, 2009 9:26:57 PM Subject: Re: [OT] Weird Boolean/ Wrapper class bug You're not pasting the real code, I don't think. I suspect you're just getting screwed by autoboxing in whatever code you're not showing. If you have: Boolean a = null; boolean b = a; That will result in a NPE as auto-unboxing attempts to unbox a into a boolean, which throws a NPE. Somewhere in the code you didn't include is an unbox into a boolean (little b) of your null Boolean. So, for instance: Boolean a = null; if (a) { } will NPE. Look more closely at the exact code, specifically the line of code that actually failing, and make sure you're not getting an unbox. ms On Nov 21, 2009, at 10:23 AM, Shravan Kumar. M wrote: Hello Group, > > >Boolean a = null; >if(a != null) >System.out.println("s"); >else >System.out.println("n"); >-- >Above code block raises NullPointerException, where as below one runs >successfully!!! Same is the case with any wrapper class (Integer, Long, ...). >*Its wondering what it makes difference in checking (a != null) and (a == >null)? Its just an Object check rt!* > > >Exact exception: java.lang.NullPointerException at booleanValue() >-- >Boolean a = null; >if(a == null) >System.out.println("s"); >else >System.out.println("n"); > > >Thank You, >Shravan Kumar. M > >___ >Do not post admin requests to the list. They will be ignored. >Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) >Help/Unsubscribe/Update your Subscription: >http://lists.apple.com/mailman/options/webobjects-dev/mschrag%40mdimension.com > >This email sent to msch...@mdimension.com ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Velocity Template Question
Hi; Thanks for that -- works really well. cheers. ___ Andrew Lindesay www.lindesay.co.nz ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: How do I restore the 'previous' page with DirectActions
On Nov 21, 2009, at 10:31 AM, Riccardo De Menna wrote: Hi Chuck, thx for answering, On 20/nov/2009, at 14.08, Chuck Hill wrote: I want to return the same page a user is viewing after he clicks a directAction. Why a direct action? If the page is the result of a component action, why not use a component action. I want external referers to be able to link directly to a specific language of the website. Still... you pointed out an easy workaround for me. I can use the component action to swap the language and leave the direct one in place for external references... those coming from outside won't have a 'previous' page to be restored so I don't have to face the issue at all. I'd look in the headers for the referrer URL and use a WORedirect to that. Yeah but how do I restore the page if I'm missing the contextID? You don't restore the page, you use WORedirect to get the browser to request the URL again. Chuck -- Chuck Hill Senior Consultant / VP Development Practical WebObjects - for developers who want to increase their overall knowledge of WebObjects or who are trying to solve specific problems. http://www.global-village.net/products/practical_webobjects ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: How do I restore the 'previous' page with DirectActions
Hi Chuck, thx for answering, > On 20/nov/2009, at 14.08, Chuck Hill wrote: > >> I want to return the same page a user is viewing after he clicks a >> directAction. > > Why a direct action? If the page is the result of a component action, why > not use a component action. I want external referers to be able to link directly to a specific language of the website. Still... you pointed out an easy workaround for me. I can use the component action to swap the language and leave the direct one in place for external references... those coming from outside won't have a 'previous' page to be restored so I don't have to face the issue at all. > I'd look in the headers for the referrer URL and use a WORedirect to that. Yeah but how do I restore the page if I'm missing the contextID? rdm ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Velocity Template Question
I'm assuming that the 'code' is an EO attribute of an entity. I think you'll have to iterate over the list of attributes, check the name and set a flag manually. Then you can conditionally generate your template code base on the flag. I may be wrong--and I'd love to find an easier way if I am--but this is how I do such a thing in my templates. I haven't actually tested the following code, but I use something similar to check for the presence of not-null class properties. Maybe it will point you in the right direction: #set ($hasCode = 'false') #foreach ($attribute in $entity.classAttributes)#if ($attribute.name == 'code')#set ($hasCode = 'true')#end#end #if ($hasCode == 'true') @SuppressWarnings("unchecked") public static nz.co.orcon.osm.eo.main.OcnDuration fetchByCode(EOEditingContext ec, String code) { } ... #end I haven't yet found an easy way to break out of the foreach loop, so for now my templates always iterate over the entire list of attributes (but only once to set the flag). Hope that helps. Fez On 2009-Nov-20, at 02:46 PM, Andrew Lindesay wrote: > Hi Mike; > > You are right; I'm trying to add a method to the entitys' superclasses for > fetching based on "code" if the "code" attribute is present. I'm trying to > achieve what I had before using velocity. I am doing something like this, > but the #if is not firing; > >> #if ($entity.sortedClassAttributes.containsObject(code)) >> @SuppressWarnings("unchecked") >> public static nz.co.orcon.osm.eo.main.OcnDuration >> fetchByCode(EOEditingContext ec, String code) { >> >> } >> >> ... >> >> #end > > cheers. > > ___ > Andrew Lindesay > www.lindesay.co.nz > > ___ > Do not post admin requests to the list. They will be ignored. > Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) > Help/Unsubscribe/Update your Subscription: > http://lists.apple.com/mailman/options/webobjects-dev/listfez%40dakri.com > > This email sent to list...@dakri.com ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: [OT] Weird Boolean/ Wrapper class bug
You're not pasting the real code, I don't think. I suspect you're just getting screwed by autoboxing in whatever code you're not showing. If you have: Boolean a = null; boolean b = a; That will result in a NPE as auto-unboxing attempts to unbox a into a boolean, which throws a NPE. Somewhere in the code you didn't include is an unbox into a boolean (little b) of your null Boolean. So, for instance: Boolean a = null; if (a) { } will NPE. Look more closely at the exact code, specifically the line of code that actually failing, and make sure you're not getting an unbox. ms On Nov 21, 2009, at 10:23 AM, Shravan Kumar. M wrote: > Hello Group, > > Boolean a = null; > if(a != null) > System.out.println("s"); > else > System.out.println("n"); > > -- > Above code block raises NullPointerException, where as below one runs > successfully!!! Same is the case with any wrapper class (Integer, Long, ...). > *Its wondering what it makes difference in checking (a != null) and (a == > null)? Its just an Object check rt!* > > Exact exception: java.lang.NullPointerException at booleanValue() > -- > > Boolean a = null; > if(a == null) > System.out.println("s"); > else > System.out.println("n"); > > Thank You, > Shravan Kumar. M > > > ___ > Do not post admin requests to the list. They will be ignored. > Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) > Help/Unsubscribe/Update your Subscription: > http://lists.apple.com/mailman/options/webobjects-dev/mschrag%40mdimension.com > > This email sent to msch...@mdimension.com ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: [OT] Weird Boolean/ Wrapper class bug
Mine: java version "1.5.0_16" From: David LeBer To: Shravan Kumar. M Cc: WO Dev Group Sent: Sat, November 21, 2009 9:06:22 PM Subject: Re: [OT] Weird Boolean/ Wrapper class bug On 2009-11-21, at 10:23 AM, Shravan Kumar. M wrote: > Hello Group, > > Boolean a = null; > if(a != null) > System.out.println("s"); > else > System.out.println("n"); > > -- > Above code block raises NullPointerException, where as below one runs > successfully!!! Same is the case with any wrapper class (Integer, Long, ...). > *Its wondering what it makes difference in checking (a != null) and (a == > null)? Its just an Object check rt!* > > Exact exception: java.lang.NullPointerException at booleanValue() > -- > > Boolean a = null; > if(a == null) > System.out.println("s"); > else > System.out.println("n"); That makes no sense. Boolean b = null; if (b != null) { NSLog.out.appendln("not null"); } else { NSLog.out.appendln("is null"); } Runs fine for me. Something is hosed with your JVM? ;david -- David LeBer Codeferous Software 'co-def-er-ous' adj. Literally 'code-bearing' site: http://codeferous.com blog: http://davidleber.net profile:http://www.linkedin.com/in/davidleber twitter:http://twitter.com/rebeld -- Toronto Area Cocoa / WebObjects developers group: http://tacow.org ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: [OT] Weird Boolean/ Wrapper class bug
On 2009-11-21, at 10:23 AM, Shravan Kumar. M wrote: > Hello Group, > > Boolean a = null; > if(a != null) > System.out.println("s"); > else > System.out.println("n"); > > -- > Above code block raises NullPointerException, where as below one runs > successfully!!! Same is the case with any wrapper class (Integer, Long, ...). > *Its wondering what it makes difference in checking (a != null) and (a == > null)? Its just an Object check rt!* > > Exact exception: java.lang.NullPointerException at booleanValue() > -- > > Boolean a = null; > if(a == null) > System.out.println("s"); > else > System.out.println("n"); That makes no sense. Boolean b = null; if (b != null) { NSLog.out.appendln("not null"); } else { NSLog.out.appendln("is null"); } Runs fine for me. Something is hosed with your JVM? ;david -- David LeBer Codeferous Software 'co-def-er-ous' adj. Literally 'code-bearing' site: http://codeferous.com blog: http://davidleber.net profile:http://www.linkedin.com/in/davidleber twitter:http://twitter.com/rebeld -- Toronto Area Cocoa / WebObjects developers group: http://tacow.org ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
[OT] Weird Boolean/ Wrapper class bug
Hello Group, Boolean a = null; if(a != null) System.out.println("s"); else System.out.println("n"); -- Above code block raises NullPointerException, where as below one runs successfully!!! Same is the case with any wrapper class (Integer, Long, ...). *Its wondering what it makes difference in checking (a != null) and (a == null)? Its just an Object check rt!* Exact exception: java.lang.NullPointerException at booleanValue() -- Boolean a = null; if(a == null) System.out.println("s"); else System.out.println("n"); Thank You, Shravan Kumar. M ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com