Custom Findbugs Rule

Findbugs plugin architecture

You can create custom findbugs rules by creating a jar file in "plugins" directory of findbugs home (folder available when you extract findbugs).

Findbugs.xml file
At startup, each of those jar files is checked for a "findbugs.xml" file.
The XML file registers instances of
1. Detectors &
2. bug patterns that the detector reports.

At startup, FindBugs loads all plugin Jar files.  At analysis time, all detectors named in the findbugs.xml files from those plugins are instantiated and applied to analyzed class files.

Example findbugs.xml file

<DetectorPlugin>
  <Detector class="org.foobar.findbugs.FindUnreleasedLocks" speed="slow" />
  <Detector class="org.foobar.findbugs.ExperimentalDetector" speed="fast" disabled="true" />

  <!-- More Detector elements would go here... -->

  <BugPattern type="UBL_UNRELEASED_LOCK" abbrev="UL" category="MT_CORRECTNESS" />

  <!-- More BugPattern elements would go here... -->

</DetectorPlugin>

1.    <Detector> specifies a class which implements the edu.umd.cs.findbugs.Detector  interface and has a constructor that takes a single parameter of type edu.umd.cs.findbugs.BugReporter.  This element has three possible attributes:
a.     The required "class" attribute specifies the Detector class.
b.     The optional "disabled" attribute, if set to "true", means that by default, the detector will be disabled at runtime.
c.    The required "speed" attribute supplies a value to be shown in the "Settings->Configure Detectors" dialog.  It gives the user an idea of how expensive the analysis will be to perform.  The value of this  attribute should be one of "fast", "moderate", or "slow".
2.     <BugPattern> specifies a kind of bug that will be reported.  It has three required attributes:
a.    "type" is a unique code identifying the bug.  Only one BugPattern  can have a a particular type.
b.    "abbrev" is a short alphanumeric code for the bug.
c.    "category" can be one of categories defined in the core plugin's messages.xml:

1.    CORRECTNESS - code that was probably not what the developer intended
2.    BAD_PRACTICE - violations of recommended and essential coding practice
3.    STYLE - code that is confusing, anomalous, or written in a way that that leads itself to errors
4.    MT_CORRECTNESS - multithreaded correctness issues
5.    MALICIOUS_CODE - a potential vulnerability if exposed to malicious code
6.    PERFORMANCE - a performance issue
7.    I18N - internationalization and locale
or you may create your own category, in which case you should define it in a <BugCategory> element in _your_ messages.xml file.

Messages.xml file

<MessageCollection>

  <Detector class="org.foobar.findbugs.FindUnreleasedLocks" >
    <Details>
      <![CDATA[
        <p> This detector looks for JSR-166 locks that are not released on all paths
        out of a method.  Because it performs dataflow analysis, it is fairly slow.
      ]]>
    </Details>
  </Detector>

  <!-- More Detector nodes would go here... -->

  <BugPattern type="UBL_UNRELEASED_LOCK">
    <ShortDescription>Lock not released on all paths out of method</ShortDescription>

    <LongDescription>{1} does not release lock on all paths out of method</LongDescription>

    <Details>
      <![CDATA[
        <p> A JSR-166 lock acquired in this method is not released on all paths
        out of the method. This could result in a deadlock if another thread
        tries to acquire the lock.  Generally, you should use a finally
        block to ensure that acquired locks are always released.
      ]]>
    </Details>
  </BugPattern>

  <!-- More BugPattern nodes would go here... -->

  <BugCode abbrev="UL">Unreleased locks</BugCode>

  <!-- More BugCode nodes would go here... -->

</MessageCollection>


1.    <MessageCollection> is the top level element
2.    <BugCategory> elements optionally describe any categories you may have created for your bug patterns. You can skip these if you are using only the categories defined by the core plugin.
a.    <Description> child element has a brief (a word or three) description of the category.
b.    <Abbreviation> child element is typically a single capital latter.
c.     <Details> optional child element may describe it in more detail (but no markup).
3.    <Detector> holds meta-information about a Detector in the plugin.
a.    The required "class" attribute specifies the Detector class.
4.    Detector elements much have the following child elements:
a.    The <Details> child element has a brief HTML description of the Detector.
b.    It should have HTML markup that would be valid in a BODY element.
c.    It should be specified in a CDATA section so that the HTML tags are not misinterpreted as XML.
5.    <BugPattern> holds all of the human-readable messages for the bug pattern identified by the "type" attribute.  The type corresponds to the type attribute of the BugPattern elements described in findbugs.xml.
6.    BugPattern elements must have the following child elements:
a.    <ShortDescription> this is used for when "View->Full Descriptions" is turned off in the GUI, and it's also used as the title for descriptions in the Details window.
b.    <LongDescription> this is used for when "View->Full Descriptions" is turned on in the GUI, and for output using the command line UI.
7.    The placeholders in the long description ({0}, {1}, etc.) refer to BugAnnotations attached to the BugInstances reported by the detector for this bug pattern. You may also use constructs like {1.name} or {1.returnType}.

8.    <Details> this is the descriptive text to be used in the Details window.  It consists of HTML markup to appear in the BODY element of an HTML document.  It should be specified in a CDATA section so that the HTML tags are not misinterpreted as XML.
9.    <BugCode> is the text which describes the common characteristic of all of the BugPatterns which share an abbreviation.  In the example above, the abbreviation "UL" is for bugs in which a lock is not released. The text of a BugCode element is shown for tree nodes in the GUI which group bug instances by "bug type".

Writing hello world findbugs rule.

The rule will show an error on all static methods that you write in a class. This could help you start writing your own findbugs plugin.
1.    Extract the attached zip.
2.    Modify the build.xml to change the findbugs.home property to the directory where you have downloaded findbugs.
3.    Go to the extracted directory run ant plugin
4.    This would create a plugin.jar and copy it to findbugs.home/plugin directory
5.    Run ant test
6.    Check the html report in examples directory.

Thread.sleep

A thread is a thread of execution in a program. The Java Virtual Machine allows an application to have multiple threads of execution running concurrently.

Yes thats the kind of explanation they give in javadocs... Couldn't gather much from this.
So here's what it is in common mans language
A thread is like a process(Java gurus pls forgive me), the way we start each process on our machine like a firefox browser, a wordpad, media player etc... Now each of this process appears to be occuring simultaneously. Similar is the case of a thread in java.

You could have multiple threads and each of the threads would execute simultaneously or so it appears to be because of the time sharing it does.

Now getting to the topic of discussion what is Thread.sleep and other questions like isn't it a static method?

It is a static method but it gets the thread that is currently executing to sleep for the specified number of milli seconds.

How does it do it?
Using the concept of TLS or thread local storage. Each thread has a global memory which stores information corresponding to itself. So when Thread.sleep is called the stack which is running the thread is suspended and it waits for the time to complete or for some other method to interrupt it so that it can throw and interrupted exception and continue execution.

Difference between Thread.sleep and Thread.currentThread().sleep()
None. There is no difference between the two. Thread.currentThread returns the current thread that is executing don't confuse it with "this" this refers to object, Thread.currentThread refers to the thread being executed currently.

some more on it will come soon... but currently i'm feeling thread.sleeepy...

Reliance Netconnect Usage

I have been using reliance netconnect night unlimited(so they say with a 10gb limit) plan for some time now.

The most irritating part of using it is that there is no way to find out how much you have used. They have a usage tab wherein they give you the kbs you have used, but do they expect us to add the usage depending on the time we used it and seperate it into night and day usage.

Here is the link where you can calculate the usage by just giving your mobile number and the dates.
It will give you a day and night split of your usage.