Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [jdt-core-dev] Suggestion for reorganizing compiler preferences...

I think splitting up the page is a good idea. I wanted to add that this also gives an extra property page on Java projects as the compiler settings can be modified per project. Property pages don't support a hierarchical structure so we probably have to find a good, self-describing name for the problems page.

Martin



"Ed Burnette" <Ed.Burnette@xxxxxxx>
Sent by: jdt-core-dev-admin@xxxxxxxxxxx

08.07.2003 22:00

Please respond to
jdt-core-dev@xxxxxxxxxxx
To
<jdt-ui-dev@xxxxxxxxxxx>
cc
<jdt-core-dev@xxxxxxxxxxx>
Subject
RE: [jdt-core-dev] Suggestion for reorganizing compiler preferences...





Keeping these tabs organized is a great idea. (I think the Java Editor preferences needs a similar treatment.)

May I suggest having an extra preference page level for the compiler to simplify it a little and make it more usable on smaller screens? The current arrangement mixes general compiler options and problem settings in a confusing way. How about separating them like this:

+ Compiler
 |-Problems

The Compiler page would have these tabs:
  Compliance
     (current contents of JDK Compliance group)
  Code Generation
     (current contents of Classfile Generation group)
  Output
     (x Clean output folders on full build
      x Enable using exclusion patterns in source folders
      x Enable using multiple output locations for source folders
      Enter resources...
      Filtered Resources: _____
     )

The Problems page would have these tabs:
  General
  - Local variable is never read (Missing?)
  - Methods with a constructor name
  - Possible accidental boolean assignment
  - Superfluous semicolon                                     NEW
  - Unreachable code (leave since it could still be helpful in rare cases)
  - Unresolvable import statements (leave since it could still be helpful in rare cases)
  - Maximum number of problems reported per compilation unit

  Visibility
  - Access to non-accessible member of an enclosing type
  - Conflict of interface method with protected 'Object' method
  - Field declaration hides another field or variable
  - Hidden catch blocks
  - Local variable declaration hides another field or variable
    +- Include constructor or setter method parameters
  - Methods overriden but not package visible

  Efficiency
  - Assignment has no effect
  - Indirect access to static member                          NEW
  - Non-static access to static member
  - Usage of deprecated API
    +- Signal use of deprecated API inside deprecated code
  - Using a char array in string concatenation

  Unused Code
  - Unused imports
  - Unused local variables
  - Unused parameters
    +- Signal unused parameters when overriding concrete method. MISSING
    +- Signal unused parameters when implementing abstract method.  MISSING
  - Unused private types, methods or fields

  I18N
  - Usage of non-externalized strings
  - String concatenation (next 4 are from bug #38332)
  - Locale sensititive methods
  - Embedded strings
  - Embedded characters

  Build Path
  - Circular dependencies
  - Duplicated resources
  - Incompatible required binaries
  - Incomplete build path
  x Abort building on build path errors

Looking at Iproblem.java it seems like there are a lot of other problems that could be made visible but I didn't have time to go through them all.

Where possible I've suggested sorting the options in alphabetical order (at least for English). This is not a big deal but might make problems easier to find and enable/disable.


> -----Original Message-----
> From: Philippe P Mulet [mailto:philippe_mulet@xxxxxxxxxx]
> Sent: Thursday, July 03, 2003 5:41 AM
> To: jdt-ui-dev@xxxxxxxxxxx
> Cc: jdt-core-dev@xxxxxxxxxxx
> Subject: [jdt-core-dev] Suggestion for reorganizing compiler
> preferences...
>
>
> With recent additions of new compiler options, I noticed that
> our layout is
> reaching its limit again, thus I am proposing the following:
>
> Common Mistakes (i.e. old Style options which are currently
> defaulting to
> WARNING)
> - Methods overriden but not package visible
> - Methods with a constructor name
> - Conflict of interface method with protected 'Object' method
> - Hidden catch blocks
> - Non-static access to static member
> - Assignment has no effect
> - Using a char array in string concatenation
>
> Obsolete Code (i.e. old Problems options with a few moved elsewhere)
>       - Unreachable code                                    
> REMOVE since
> turning off isn't JLS compliant (historical option for VAJ
> migration, no
> longer an issue)
>       - Unresolvable import statements                      
> REMOVE since
> turning off isn't JLS compliant (historical option for VAJ
> migration, no
> longer an issue)
> - Unused local variables
> - Unused parameters
>   +- Signal unused parameters when overriding concrete method.
> MISSING
>   +- Signal unused parameters when implementing abstract
> method.  MISSING
> - Unused imports
> - Unused private types, methods or fields
> - Usage of deprecated API
>   +- Signal use of deprecated API inside deprecated code
>
> Advanced Diagnosis (i.e. old Style options which are
> currently defaulting
> to IGNORE + max number of problems per unit)
> - Superfluous semicolon                                     NEW
> - Indirect access to static member                          NEW
> - Access to non-accessible member of an enclosing type
> - Possible accidental boolean assignment
> - Local variable declaration hides another field or variable
>   +- Include constructor or setter method parameters
> - Field declaration hides another field or variable
> - Usage of non-externalized strings
> - Maximum number of problems reported per compilation unit
>
> Compliance and Classfiles
> - same as current
>
> Build Path
> - same as current
>
>
> _______________________________________________
> jdt-core-dev mailing list
> jdt-core-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/jdt-core-dev
>
_______________________________________________
jdt-core-dev mailing list
jdt-core-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/jdt-core-dev

Back to the top