Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-4128179

# Add a lint-like facility to javac



    • Type: Enhancement
    • Status: Closed
    • Priority: P5
    • Resolution: Won't Fix
    • Affects Version/s: 1.0, 1.1, 1.1.3, 1.1.4, 1.1.5, 1.1.6, 1.1.7, 1.2.0, 1.2.2, 1.3.0, 1.4.0
    • Fix Version/s: None
    • Component/s: tools
    • Subcomponent:
    • CPU:
      generic, x86, sparc
    • OS:
      generic, solaris_2.4, solaris_2.5, solaris_2.5.1, windows_95, windows_nt, windows_2000


      Many RFE's have been submitted against javac requesting warnings
      of the sort that lint would give for C. Because of the importance of
      comformance and the role that javac plays in establishing it, it
      is our policy is to not give warnings by default. However, an optional
      mode that is not the default would be fine.

      Name: tb29552 Date: 02/22/99

      I'd like you to add a "variable never used" warning.
      Eg. in C++ this is a standard compiler feature.
      It's quite hard to find variables manually that are
      no longer in use (forgotten). And it should be
      very easy for the compiler, at least to find local variables
      or private class/instance variables without any accesses
      from the currently compiled class.

      Name: tb29552 Date: 07/12/99

      Often we write a class and for some unknown reason it doesn't do,
      what we aspect it to do.
      After searching for hours a bug in the codes logic, we find it to be
      a simple semantically error.
      Take the following simple class as an example:

      import javax.swing.JFrame;
      import javax.swing.JTextField;

      import java.awt.event.WindowEvent;
      import java.awt.event.WindowAdapter;

      public class Test extends JFrame
      private int txtColumns;

      public Test(int txtColums)
      this.txtColumns = txtColumns;

      public void init()
      JTextField tf = new JTextField(txtColumns);

      public static void main(String[] args)
      Test test = new Test(150);
      test.addWindowListener(new WindowAdapter() {
      public void windowClosing(WindowEvent e)

      It's a frame containing a TextField, in the constructor we set a member
      which will be used as the columns count for the text fields constructor.
      In the main method we create the frame passing to it's constructor
      a very big columns count. After that we call init(), which creates
      the text field with the giving columns.
      After this we call pack() to size the frame and at least we show
      the frame.

      We aspect the frame to have a very big width, but no, it's just the minimal
      with a frame can have, why?

      We can find the error in the frames constructor, where
      public Test(int txtColums)
      should be
      public Test(int txtColumns)
      you can see we just wrote txtColumns wrong, as txtColums, we forgot the n

      This has the consequence that the line

      this.txtColumns = txtColumns;

      in the constructor becomes like

      this.txtColumns = this.txtColumns;

      A really unlogical assignment and for no use at all.

      If the compiler would warn when he comes across to an assignment like this,
      we would find the semantic error in just a second and not spend hours to analyze
      the logic of our code.

      Please enhance the compiler to help us, thanks
      (Review ID: 85465)

      Name: krT82822 Date: 09/30/99

      Take this example:

      byte b;
      if (b == 0x90)
          System.err.println("You will never see this output! ;-)");

      The variable b is converted to an int, but b will never contain 0x90,
      because it's out from it's valueable range. For silly comparisions
      like this javac should warn!
      Now javac could easely analize comparitions between a variable and a constant
      and analize if the constant is a valid value for the variables range,
      of course this check has to be performed before the byte gets converted
      to an int.

      Now I send this as a separate rfe to u, because I have the suspect
      that just adding it to the lint bug collection #4128179 would
      lead to never been read ;-) So I let you to add it there or open
      a new one.

      (Review ID: 95949)

      Name: tb29552 Date: 03/16/2000

      java version "1.2.2"
      Classic VM (build JDK-1.2.2-W, native threads, symcjit)

      When I was working with Servlet I found this bug. My sample
      code is as follows.

      import java.io.*;
      import javax.servlet.*;
      import javax.servlet.http.*;

      public class ServletName extends HttpServlet
        public void dofet(HttpServletRequest req, HttpServletResponse res)
        throws ServletException, IOException
             /* [...additional statements in method body deleted...] */

      If I compile this code with javac, no errors will be reported.

      Actually I should get an error, or at least a warning that
      no methods were overridden in the derived class.
      Because ServletName is a derived class from HttpServlet.
      At least one method of HttpServlet should get override.

      (Review ID: 102521)

      Name: krC82822 Date: 01/18/2001

      18 Jan 2001, eval1127@eng -- see also #'s 4113193, 4128179, 4041247, etc.
      One potential error that trips everyone up sooner or later is to add an
      extraneous semicolon to an if, for, or while as in:

      while( condition );

      The semicolon of course makes the body of the while a null statement and is
      legal code, but probably not what was intended.

      It would be nice if the compiler issued a warning when it found a null
      statement for an if, for, or while and the next token was an opening brace.
      Chances are the semicolon was unintentional. It should not give a warning if
      the statement is not empty.

      I, for one, in my early days of C programming wasted over a week trying to
      track down this type of bug, before giving up and going back to the drawing
      board. Only to find the problem after several days of rewriting.
      (Review ID: 115331)

      From: "WEST, Peter" <###@###.###>
      Subject: suggestion for java compiler feature
      Date: Fri, 2 Mar 2001 12:18:30 -0000


      I just thought of a rather useful feature you could put on the javac

      example syntax would be:-

      javac -w customWarnings.xml file.java

      the customWarnings.xml would be a file any user can define in order to ask
      the java compiler to provide additional warnings in specific cases defined
      in the xml file.


      javac could be defined to give a warning when it finds the word "flase"
      pointing out it could be a typo of "false"
      or a warning when a case statement does not end in a return or break

      This would allow the user to create their own custom parsing requirements
      for errors or mistakers that they repeatedly perform which are not obvious
      with normal compilation errors (e.g the switch case statements that do not
      break or return, are not an error but can be a repeated cause of strange
      program behaviour)

      No doubt such an option could be used for far more purposes than this simple
      Just a suggestion,

      Pete West,
      Java Developer.
      Sema Telecoms R&D

      From: "WEST, Peter" <###@###.###>
      Subject: follow on suggestion for javac
      Date: Fri, 2 Mar 2001 14:16:34 -0000

      following from my email this morning relating to allowing an xml file to
      define custom warning rules for javac to apply.
      Another use for this would be enforcing /encouraging coding standards.

      e.g sunCodingStandards.xml and randomCompanyCodingStandards.xml

      javac could then use this file to report warnings for any parts of the code
      that do not comply to these standards.

      javac -w sunCodingstandards.xml (syntax made up for example purposes)

      Sun coding standrads warning: line 382;
      variable A_Daft_Variable begins with an uppercase letter and uses
      underscores but is not defined as a constant.

      these xml warning definition files would allow companies to apply their own
      standards globally for consistant code.
      Businesses would like that. It would also save a great deal of time on
      project managers reviewing other developers code by letting them perform a
      first level review themselves compiling with the option indicated.

      iris.garcia@eng 2001-03-02


          Issue Links



              gafter Neal Gafter
              dstoutamsunw David Stoutamire (Inactive)
              0 Vote for this issue
              0 Start watching this issue