Hi
if u see u are giving object.a, but object is an instance
variable...its just stores the address. Similarly if u keep a string
in a switch case...it will give u a compilation error...because switch
doesnot allow instance variables...in ur code u declared c as int and
gave a value as 2 which is a primitive datatype..but in "case" u are
refering to an instance..so it wont take ur code...

The purpose of the JLS is not expository, it's to be precise and unambiguous.
 In particular, it specifies how a Java compiler must behave.

It is useful when one wants to know exactly what's what in the language, less
so for learning the concepts until you get used to it.  Then it's priceless.

The specific example you showed, repeated here for clarity:

 public final int a = 1;

...
 switch (someInt) {
  case object.a:
...

does not meet the definition of the phrase "constant expression" as
defined in the JLS, even though in theory you could determine
statically that a is always going to be 1 at that point in the code.
The JLS doesn't demand that level of sophistication from the compiler:
'object' is not a constant expression, therefore no expression
containing it can be a constant expression.[0]

Unless there's some wild deviation between your example and your real
problem, I don't see why you can't make 'a' static final and refer to
it as SwitchTest.a or some similar form.  What're you working on?
Maybe someone has a better suggestion than an if ladder.

[0] It's probably worth mentioning here that the ONLY reference type
allowed in a constant expression is String.  No other class can have
constant values according to the JLS.  Since String is the only class
that can be instantiated without a 'new', this makes some sense.

nope.

 SwitchTest object = new SwitchTest();

    int choice = 2;

    switch(choice){
    case object.a:

The address of object is not known until the program runs.  The
object.a does not exist at compile time.

had you written:

public static final int a = 1;
  public static  final int b = 2;
  public static  final int c = 3;
...
switch(choice){
    case a:
or
case SwitchTest.a:

then the value would be known at compile time.

Had you left out the static, I don't know what would happen. The
compiler might say NO on the grounds it does not know the value of any
fields in an object at compile time.  The compiler might say OK, on
the grounds, it can deduce the values, even at compile time.  

From a practical point of view, there is no point in leaving out the
static when the value is known at compile time.  The only point in an
instance constant is when the value differs for each instance of the
object, or its value cannot be determined until the object is
instantiated.

Java literature does not make as clean a distinction between the seven
flavours of constant as I would like.

It is presented as a vague soup.  You figure it out on your own by
discovering what the compiler will eat.

If you follow these rules of thumb, you will get by without having to
fully understand constants:

Avoid literals other than 0 and 1. Use static finals instead.

If a value can be known at compile or load time, mark it static final.
If a value does not change after you compute it, mark it final. This
applies to static variables, instance variables, local variables and
parameters.

If in doubt whether a value is ok for a case, try it. If the compiler
does not complain, it was ok.

If your constants need to be computed in some special order, put that
initialisation in a static {} or an instance intialisation {} block
where the order won't be meddled with. Don't trust the order of
declarations. Some tidying program such as IntelliJ Idea Rearranger
will eventually disturb the variable declaration order leaving you or
someone else baffled why the initialisation no longer works.

If you change the value of a static final, do a clean recompile of all
places it is used to propagate the new value.

The JLS is the authoritative description of the language, and as such
has to be extremely precise. It is often very difficult, if not
impossible, to explain things both precisely and simply.

I think the quote may relate to optimizations that the compiler can
choose to do without changing the language. Your code would require a
change in the Java language, away from what the JLS specifies.

I don't understand why you did that. Your original code would have
worked fine if you had added "static" to each of the declarations:

  public static final int a = 1;
  public static final int b = 2;
  public static final int c = 3;

Given the "final" and the constant initializer, I don't see any benefit
to having a separate copy of each variable for each object of your
class, rather than a single copy shared by all objects.

There is a subset of switch situations that every compiler can implement
faster or more compactly than their if-then-else equivalent. The Java
designers choose to limit the switch syntax to those situations.

However, I would have preferred it if they had allowed unrestricted
switch, allowing any expressions and any type, using == comparison for
primitives and equals() method for references.

At the worst, the compiler would generate a sequential if-then-else
stack, the same code as you converted to. The other implementations
would be optimizations relative to that code.

Patricia

Just a note, have you considered using enums or even use a polymorphic
object instead of switch?

<http://virtualinfinity.net/wordpress/program-design/2007/10/22/using-enums-as-a-
flyweight-pattern/>

In Object Oriented design, its considered a likely problem if you have a
switch statement (or a switch like construct).  While there are *some*
times when a switch is appropriate, I've found that I haven't used a
switch statement once I understood the State, Strategy, and Flyweight
patterns.

As an aside more direct to your original post, is there a good reason to
make them *not* static final int?