• Post Reply Bookmark Topic Watch Topic
  • New Topic

StringBuffer .append leads to NullPonter Exception  RSS feed

 
RatiKanta pal
Ranch Hand
Posts: 88
Eclipse IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello Guyz,
I am working in java since 2010 but never face this kind of issue



this is the code .Control entering to if and than throwing NullPointer Exception on StringBuffer.java(Line 130).

Any idea what is going wrong?

Thank you.
 
Stephan van Hulst
Saloon Keeper
Posts: 7993
143
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Either these are not the lines that are throwing the exception, or this is not a StringBuffer.
 
RatiKanta pal
Ranch Hand
Posts: 88
Eclipse IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello Stephan ,

I Have checked the logs several times .It leads to append .

Thanks.
 
Stephan van Hulst
Saloon Keeper
Posts: 7993
143
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Please write us an SSCCE that demonstrates the problem.
 
K. Tsang
Bartender
Posts: 3648
16
Firefox Browser Java Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
RatiKanta pal wrote:Control entering to if and than throwing NullPointer Exception on StringBuffer.java(Line 130).
Any idea what is going wrong?



Just a guess. The NullPointerException may not be in your own programs but in the Java SDK's StringBuffer.java source. Of course unless you wrote a class called StringBuffer.
 
Fred Kleinschmidt
Bartender
Posts: 571
9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Show us the EXACT traceback you are getting
 
Rob Spoor
Sheriff
Posts: 21135
87
Chrome Eclipse IDE Java Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Line 130 of java.lang.StringBuffer cannot cause a NullPointerException, because it's:
  • a blank line in Java 8
  • a line of javadoc in Java 7
  • a method signature in Java 6
  • a blank line in Java 5.0
  • this(str.length() + 16); in a constructor in Java 1.4. Although that could have caused a NullPointerException, it would not be thrown from the provided piece of code.
  • a line of javadoc in Java 1.3

  •  
    Mike Simmons
    Ranch Hand
    Posts: 3090
    14
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    I agree with Stephan and Rob - those lines could not have thrown the exception. I understand that you have double-checked the logs, and that is the line number indicated. I suspect that what has happened is that the code has changed in some way, and the version of the code that you're looking at is not the same as the version that was compiled and is now being executed. I suggest doing a fresh build of the project, run it again, and see what line number you get in the stack trace.
     
    Mike Simmons
    Ranch Hand
    Posts: 3090
    14
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Rob Spoor wrote:Line 130 of java.lang.StringBuffer cannot cause a NullPointerException, because it's:

    [deletia]


    Well, it is possible for them to have minor bug fixes within a major release version - so there may be more than one "line 130" for Java 8, or Java 7, etc. Or maybe it's the OpenJDK rather than the usual Sun/Oracle version.

    I would add two more questions for RatiKanta:

    1. When you refer to StringBuffer.java, is that the class java.lang.StringBuffer? Or do you have your own class called StringBuffer.java somewhere?

    2. What exact version of Java are you using? What is the output if you run "java -version"?
     
    Mike Simmons
    Ranch Hand
    Posts: 3090
    14
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    It seems like in the distant past, there was a version of StringBuffer with this problem:

    https://jira.spring.io/browse/SPR-1462

    https://bz.apache.org/bugzilla/show_bug.cgi?id=2377

    Those are both from more than ten years ago. RatiKanta, you may want to upgrade your Java installation if at all possible...
     
    RatiKanta pal
    Ranch Hand
    Posts: 88
    Eclipse IDE Java
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Hello please find the logs and stacktrace .

    Java Version:

    java version "1.6.0"
    Java(TM) SE Runtime Environment (build pxa6460sr2-20080818_01(SR2))
    IBM J9 VM (build 2.4, J2RE 1.6.0 IBM J9 2.4 Linux amd64-64 jvmxa6460-20080816_22093 (JIT enabled, AOT enabled)
    J9VM - 20080816_022093_LHdSMr
    JIT - r9_20080721_1330ifx2
    GC - 20080724_AA)
    JCL - 20080808_02

    Code:





    Stacktrace:

    java.lang.NullPointerException
    at java.lang.StringBuffer.append(StringBuffer.java:130)
    at ADHOC.BI_TEXT_REPORT_GENERATOR.ADHTCProcessWrapDataMultiRow(BI_TEXT_REPORT_GENERATOR.java:3724)
    at ADHOC.BI_TEXT_REPORT_GENERATOR.ADHTCDisplayDataInText(BI_TEXT_REPORT_GENERATOR.java:3383)
    at ADHOC.BI_TEXT_REPORT_GENERATOR.ADHTCWriteTextReport(BI_TEXT_REPORT_GENERATOR.java:2923)
    at ADHOC.BI_TEXT_REPORT_GENERATOR.ADHTCCreateTextReport(BI_TEXT_REPORT_GENERATOR.java:701)
    at ADHOC.BI_REPORT_GENERATION_CONTROLLER.ADHTOGenerateReport(BI_REPORT_GENERATION_CONTROLLER.java:685)
    at ADHOC.BI_REPORT_GENERATION_CONTROLLER.ADHTCGenerateReport(BI_REPORT_GENERATION_CONTROLLER.java:402)
    at ADHOC.BI_REPORT_QUEUE.ADHPS95032GnrtRprt(BI_REPORT_QUEUE.java:9067)
    at sun.reflect.GeneratedMethodAccessor23.invoke(Unknown Source)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
    at java.lang.reflect.Method.invoke(Method.java:599)
    at org.springframework.util.MethodInvoker.invoke(MethodInvoker.java:269)
    at com.bfsarch.springbatch.tasklet.MethodInvokingDelegator.doInvoke(MethodInvokingDelegator.java:102)
    at com.bfsarch.springbatch.tasklet.MethodInvokingDelegator.invokeDelegateMethod(MethodInvokingDelegator.java:46)
    at com.bfsarch.springbatch.writers.WriterAdapter.process(WriterAdapter.java:147)
    at com.bfsarch.springbatch.writers.WriterAdapter.write(WriterAdapter.java:747)
    at org.springframework.batch.core.step.item.SimpleChunkProcessor.writeItems(SimpleChunkProcessor.java:175)
    at org.springframework.batch.core.step.item.SimpleChunkProcessor.doWrite(SimpleChunkProcessor.java:151)
    at org.springframework.batch.core.step.item.FaultTolerantChunkProcessor$3.doWithRetry(FaultTolerantChunkProcessor.jav
     
    Dave Tolls
    Ranch Foreman
    Posts: 3068
    37
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Is it possible for you to try with a non-IBM JRE?
     
    RatiKanta pal
    Ranch Hand
    Posts: 88
    Eclipse IDE Java
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Hello Dave ,

    Application server runs on Websphere it is not possible change the jre vendor .
     
    Dave Tolls
    Ranch Foreman
    Posts: 3068
    37
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Well, how do you test this code?
    Surely there's a simple test run you can do that mimics this situation?
     
    Stephan van Hulst
    Saloon Keeper
    Posts: 7993
    143
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Is it essential you use a StringBuffer instead of a StringBuilder?
     
    Fred Kleinschmidt
    Bartender
    Posts: 571
    9
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    How do you create the StringBuffer? if you just use then try this instead:
     
    Winston Gutkowski
    Bartender
    Posts: 10575
    66
    Eclipse IDE Hibernate Ubuntu
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    RatiKanta pal wrote:Hello please find the logs and stacktrace .

    OK, so if what you show us is to be believed, it is occurring in StringBuffer.

    But the fact is that it shouldn't...EVER.

    If the Stringbuffer is non-null, then you should be able to append anything you like, any time you like, unless you get an OutOfMemoryError, since it dynamically expands to accommodate new data; so if your analysis is correct, then there's something seriously wrong with that class.

    And I hate to say, but since it's in java.lang, the people to talk to about that are IBM.

    PS: I notice you're on something called "J9". Is that related to Java version 9? (I realise that you're running your code with a 1.6 JRE) And if so, did it happen in "J8"?

    Winston
     
    Mike Simmons
    Ranch Hand
    Posts: 3090
    14
    • Likes 1
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Based on the comments in the two bug report links I gave earlier (which probably *should* be IBM bug reports, but aren't)...

    RatiKana, is it possible that the StringBuffer is initialized as

    where someVariable is actually null in this case? Nowadays that should probably produce a NullPointerException when you first initialize the StringBuffer - however that fact is not explicitly documented. It's possible that IBM's implementation doesn't error until you later append() to the StringBuffer. If that's the case, you need to make sure the StringBuffer is not passed a null in the first place when it's initialized.

    Note that Fred Kleinschmidt's suggestion from yesterday would have also fixed this problem. You haven't said whether you tried it.
     
    • Post Reply Bookmark Topic Watch Topic
    • New Topic
    Boost this thread!