andrewmcdonagh wrote :

I can see that, except that I have delibrately de-normalized between
use cases. The use cases are pretty well separated from each other.

I can delete a use case without affecting any other use case. Except of
course that that functionality has gone, which may mean that the user
can no longer maintain helper tables. But it will run OK.

Everything else is in a framework. Those classes cannot be removed as
they are used everywhere.

So if an enum is in the framework, then it should NOT know about any
business logic which uses it.

For instance (putting on fire-proof-coat) :-)
----------------
public class Value
{
// these are column IDs which we store in the database
// - do NOT change them, only add new ones
// - they must be unique
private static int LOGIC_AND_ID = 0;
private static int LOGIC_OR_ID  = 1;

// these are column IDs which we store in the database
// - do NOT change them, only add new ones

public static enum Logic
{
 /**
 * All values must return true
 */
 AND(LOGIC_AND_ID),

 /**
 * Any value can be true
 */
 OR(LOGIC_OR_ID);

 private Logic( int databaseID )
 {
  ivDatabaseID = databaseID;
 }

 private int    ivDatabaseID;

 public int getDatabaseID()
 {
  return ivDatabaseID;
 }

 /**
  * Returns the Logic for a given database id number<br><br>
  * Used to find a Logic from a Web page field or database column
  */
 public static Logic getLogic( int databaseID )
     throws EnumNotFoundException
 {
  for (Logic logic : Logic.values())
   if (logic.getDatabaseID() == databaseID)
    return logic;

  throw new EnumNotFoundException( Logic.class.getName() + "(id: " +
       databaseID + ")" );
 }
}

// .. other universal values, such a number of milli-seconds in a
// second, minute, hour, day, and so forth
}
----------------

Mind you this is untested code. But it should work (famous last words).
At least the compiler does not complain :-)

Patricia Shanahan wrote :

And further to this, I can use:
 java.util.HashMap<String,String> x;
or
 HashMap<String,String> x;

Both are acceptable (barring imports). The switch statement is the
first place I have found where you CANNOT use a qualified name.

It's even worse (IMO) if there's another definition of of the enumeration
element's name which would normally be expected to hide the other identifier.
I find the attached code particularly unpleasant.  See how in one case the
compiler /requires/ qualification, in another it /forbids/ it.

   -- chris

=======================
enum Number
{
   ONE,
   TWO
}

public class Test
{
   private static final int
           ONE = 1,
           TWO = 2;

   public static void
   main(String[] args)
   {
       Number n = Number.ONE;
/*      Number nn = ONE;        -- error: incompatible types */

       int m = ONE;
       int mm = Test.ONE;

       switch (n)
       {
       case ONE:
           System.out.println("n is Number.ONE");
           break;
       case TWO:
           System.out.println("n is Number.TWO");
           break;
       }

/* not legal at all....
       switch (n)
       {
       case Number.ONE:
           System.out.println("n is Number.ONE");
           break;
       case Number.TWO:
           System.out.println("n is Number.TWO");
           break;
       }
*/

       switch (m)
       {
       case ONE:
           System.out.println("m is Number.ONE");
           break;
       case TWO:
           System.out.println("m is Number.TWO");
           break;
       }

       switch (m)
       {
       case Test.ONE:
           System.out.println("m is Number.ONE");
           break;
       case Test.TWO:
           System.out.println("m is Number.TWO");
           break;
       }

   }
}
=======================

I smell a reaction to the quarrel over whether "myWidget.widgetCount()"
should have been allowed as an alias of "Widget.widgetCount()".