Related
I have a project where I use enum class with 128 values in it and I want to allow end user to select only few of values for his usage (say 20 out of 128) For that I created javafx tableview with checkbotablecell which works nicely but then I would need to make boolean field in enum to define visibility of each value but all enum fields are final and I will not be able to change it dynamically. So, the question is how to dynamically define visibility of each enum value?
You can create a Map of Enum to Boolean inside Enum class.
Eg : static final EnumMap<EnumType , Boolean> visibilityMap.
And add getter and setter methods to access visibility.
You want an EnumSet to be stored.
The enum class of yours defines 128 singleton objects, one cannot have several objects "being" the same enum object. The solution would be to have a class containing the enum object. Or having an EnumSet of several enum constants.
EnumSet is a Set implementation havily optimized for enums, and providing building methods.
In the constructor on passes the actual enum class itself so with type erasure the class can still function.
EnumSet<Weekday> weekend = EnumSet.of(Weekday.SATURDAY, Weekday.SUNDAY);
Looked at a lot of postings associated with passing different Enum types to a method but do not believe my specific situation/issue was resolved.
Following is my established Enum Type class (modified to hide classified information):
public class ProjectA_Enums{
private ProjectA_Enums(){
}
public enum TableA_Filter_Sort_Options{
TIMESTAMP ("TIMESTAMP", "tbla_timestamp"),
USER ("USER", "tbla_user"),
SHARE ("SHARE", "tbla_share"),
CONDITION ("CONDITION", "tbla_condition",
TERMINAL ("TERMINAL", "tbla_terminal");
private final String filter_name;
private final String database_column_name;
private TableA_Filter_Sort_Options(String filter_name,
String database_column_name){
this.filter_name = filter_name;
this.database_column_name = database_column_name;
}
public String getFilter_name(){
return filter_name;
}
public String getDatabase_column_name(){
return database_column_name;
}
}
public enum TableB_Filter_Sort_Options{
TIMESTAMP ("TIMESTAMP", "tblb_timestamp"),
ERROR_CODE ("ERROR CODE", "tblb_errcode"),
ERROR_MESSAGE ("ERROR MESSAGE", "tblb_errmsg");
private final String filter_name;
private final String database_column_name;
private TableA_Filter_Sort_Options(String filter_name,
String database_column_name){
this.filter_name = filter_name;
this.database_column_name = database_column_name;
}
public String getFilter_name(){
return filter_name;
}
public String getDatabase_column_name(){
return database_column_name;
}
}
}
Now here is the situation :
I want to call the class FilterSortDialogDisplay and pass either Enum type TableA_Filter_Sort_Options or TableB_Filter_Sort_Options to build and display a dialog GUI showing the applicable filters in a scroll pane.
This class would allow the user to select the applicable filters to perform a database query on and the desired sort order.
For Enum type TableA_Filter_Sort_Options the displayed filters would be TIMESTAMP, USER, SHARE, CONDITION, TERMINAL and for TableB_Filter_Sort_Options the displayed filters would be TIMESTAMP, ERROR CODE, ERROR MESSAGE.
The second attribute associated with each Enum type value is associated database table column to use in the resulting database query SQL. I saw in another post that one must define the input parameter of the receiving method as Class. Due to a lack of Java knowledge I am not sure how to write the code to use the passed in Enum type.
Since I have set up both Enum types with the same exact attributes and methods, I was hoping to be able to cast an attribute in the FilterSortDialogDisplay class to the appropriate Enum type and just call these methods.
Hopefully Enum types are the correct construct to be used to perform the defined functionality, because there will be additional Enum types with different number and filter values for which the Filter Sort Dialog needs to be generated and displayed without the need for redundant code based on the Enum type.
Thanks ahead of time for any assistance you can provide.
I would recommend you not use enums for this. From your description it sounds as though you want to pass an object that contains enough information for the dialog to display filter information and generate the query. I would suggest you define an interface and then create implementations for your various tables.
A solution might look something like:
public interface FilterSortOption {
Stream<Criteria> getFilterCriteria();
String generateQuery(Map<Criteria, Value> values);
}
void showDialogAndRunQuery(FilterSortOption option) {
....
}
Then you can define several implementations of this. If they share code (as they are likely to) then that code could go into a separate class that each of the implementation delegate to. It's possible that that delegate class might use an enum to contain column and criteria information. I can provide pointers on how to do that if you need it.
Your problem is not articulated very concisely. I admit that after all that, I'm not certain what help it is that you need. I would say that if your filter options are a fixed set of constants that are known at compile time, then using enums is a good practice.
Since I have set up both Enum types with the same exact attributes and
methods, I was hoping to be able to cast an attribute in the
FilterSortDialogDisplay class to the appropriate Enum type and just
call these methods.
I am going to assume that what you want to do is call a method that takes, as an argument, a parameter that can be the member of a family of enum types. Is this accurate?
There is a pattern that can be used to address this situation, the extensible enum pattern. In this pattern, each enum class in your family of enums implements a common interface. For example:
public enum TableA_FilterSortOptions implements FilterOptions {
:
:
}
public enum TableB_FilterSortOptions implements FilterOptions {
:
:
}
public interface FilterOptions { ... }
Here, all of the enum classes in your family share a common type, FilterOptions. If you define your filtering methods to accept a parameter of type FilterOptions, you can pass any constant from any of your implementing enum classes to those methods.
The restriction here is that the interface must describe all the functionality of your enum classes and each enum class must implement that functionality. When you pass an enum constant using its interface type, inside the method to which the constant was passed, the constant will "lose" its status as an enum constant, so only the interface methods will be available.
So what can you do if you need your enum constants to function as enums within the method bodies to which they are passed using the FilterOptions type (for example, you wanted to be able to add the constants to an EnumSet in your filtering method)? There is a solution. You can define generic methods that employ an intersection type. For example:
public static <E extends Enum<E> & FilterOptions> void applyFilter(E option) {
:
:
}
This method is defined to accept a single argument that must be an enum constant and which must come from an enum class that implements the FilterOptions type. Inside the body of this method, the E type can be added to an instance of EnumSet<E> and all the methods of FilterOptions will also be available.
I am very familiar with C# but starting to work more in Java. I expected to learn that enums in Java were basically equivalent to those in C# but apparently this is not the case. Initially I was excited to learn that Java enums could contain multiple pieces of data which seems very advantageous (http://docs.oracle.com/javase/tutorial/java/javaOO/enum.html). However, since then I have found a lot of features missing that are trivial in C#, such as the ability to easily assign an enum element a certain value, and consequently the ability to convert an integer to an enum without a decent amount of effort (i.e. Convert integer value to matching Java Enum).
So my question is this: is there any benefit to Java enums over a class with a bunch of public static final fields? Or does it just provide more compact syntax?
EDIT: Let me be more clear. What is the benefit of Java enums over a class with a bunch of public static final fields of the same type? For example, in the planets example at the first link, what is the advantage of an enum over a class with these public constants:
public static final Planet MERCURY = new Planet(3.303e+23, 2.4397e6);
public static final Planet VENUS = new Planet(4.869e+24, 6.0518e6);
public static final Planet EARTH = new Planet(5.976e+24, 6.37814e6);
public static final Planet MARS = new Planet(6.421e+23, 3.3972e6);
public static final Planet JUPITER = new Planet(1.9e+27, 7.1492e7);
public static final Planet SATURN = new Planet(5.688e+26, 6.0268e7);
public static final Planet URANUS = new Planet(8.686e+25, 2.5559e7);
public static final Planet NEPTUNE = new Planet(1.024e+26, 2.4746e7);
As far as I can tell, casablanca's answer is the only one that satisfies this.
Type safety and value safety.
Guaranteed singleton.
Ability to define and override methods.
Ability to use values in switch statement case statements without qualification.
Built-in sequentialization of values via ordinal().
Serialization by name not by value, which offers a degree of future-proofing.
EnumSet and EnumMap classes.
Technically one could indeed view enums as a class with a bunch of typed constants, and this is in fact how enum constants are implemented internally. Using an enum however gives you useful methods (Enum javadoc) that you would otherwise have to implement yourself, such as Enum.valueOf.
Nobody mentioned the ability to use them in switch statements; I'll throw that in as well.
This allows arbitrarily complex enums to be used in a clean way without using instanceof, potentially confusing if sequences, or non-string/int switching values. The canonical example is a state machine.
The primary advantage is type safety. With a set of constants, any value of the same intrinsic type could be used, introducing errors. With an enum only the applicable values can be used.
For example
public static final int SIZE_SMALL = 1;
public static final int SIZE_MEDIUM = 2;
public static final int SIZE_LARGE = 3;
public void setSize(int newSize) { ... }
obj.setSize(15); // Compiles but likely to fail later
vs
public enum Size { SMALL, MEDIUM, LARGE };
public void setSize(Size s) { ... }
obj.setSize( ? ); // Can't even express the above example with an enum
There is less confusion. Take Font for instance. It has a constructor that takes the name of the Font you want, its size and its style (new Font(String, int, int)). To this day I cannot remember if style or size goes first. If Font had used an enum for all of its different styles (PLAIN, BOLD, ITALIC, BOLD_ITALIC), its constructor would look like Font(String, Style, int), preventing any confusion. Unfortunately, enums weren't around when the Font class was created, and since Java has to maintain reverse compatibility, we will always be plagued by this ambiguity.
Of course, this is just an argument for using an enum instead of public static final constants. Enums are also perfect for singletons and implementing default behavior while allowing for later customization (I.E. the strategy pattern). An example of the latter is java.nio.file's OpenOption and StandardOpenOption: if a developer wanted to create his own non-standard OpenOption, he could.
There are many good answers here, but none mentiones that there are highly optimized implementations of the Collection API classes/interfaces specifically for enums:
EnumSet
EnumMap
These enum specific classes only accept Enum instances (the EnumMap only accept Enums only as keys), and whenever possible, they revert to compact representation and bit manipulation in their implementation.
What does this mean?
If our Enum type has no more that 64 elements (most of real-life Enum examples will qualify for this), the implementations store the elements in a single long value, each Enum instance in question will be associated with a bit of this 64-bit long long. Adding an element to an EnumSet is simply just setting the proper bit to 1, removing it is just setting that bit to 0. Testing if an element is in the Set is just one bitmask test! Now you gotta love Enums for this!
example:
public class CurrencyDenom {
public static final int PENNY = 1;
public static final int NICKLE = 5;
public static final int DIME = 10;
public static final int QUARTER = 25;}
Limitation of java Constants
1) No Type-Safety: First of all it’s not type-safe; you can assign any valid int value to int e.g. 99 though there is no coin to represent that value.
2) No Meaningful Printing: printing value of any of these constant will print its numeric value instead of meaningful name of coin e.g. when you print NICKLE it will print "5" instead of "NICKLE"
3) No namespace: to access the currencyDenom constant we need to prefix class name e.g. CurrencyDenom.PENNY instead of just using PENNY though this can also be achieved by using static import in JDK 1.5
Advantage of enum
1) Enums in Java are type-safe and has there own name-space. It means your enum will have a type for example "Currency" in below example and you can not assign any value other than specified in Enum Constants.
public enum Currency {PENNY, NICKLE, DIME, QUARTER};
Currency coin = Currency.PENNY;
coin = 1; //compilation error
2) Enum in Java are reference type like class or interface and you can define constructor, methods and variables inside java Enum which makes it more powerful than Enum in C and C++ as shown in next example of Java Enum type.
3) You can specify values of enum constants at the creation time as shown in below example:
public enum Currency {PENNY(1), NICKLE(5), DIME(10), QUARTER(25)};
But for this to work you need to define a member variable and a constructor because PENNY (1) is actually calling a constructor which accepts int value , see below example.
public enum Currency {
PENNY(1), NICKLE(5), DIME(10), QUARTER(25);
private int value;
private Currency(int value) {
this.value = value;
}
};
Reference: https://javarevisited.blogspot.com/2011/08/enum-in-java-example-tutorial.html
The first benefit of enums, as you have already noticed, is syntax simplicity. But the main point of enums is to provide a well-known set of constants which, by default, form a range and help to perform more comprehensive code analysis through type & value safety checks.
Those attributes of enums help both a programmer and a compiler. For example, let's say you see a function that accepts an integer. What that integer could mean? What kind of values can you pass in? You don't really know right away. But if you see a function that accepts enum, you know very well all possible values you can pass in.
For the compiler, enums help to determine a range of values and unless you assign special values to enum members, they are well ranges from 0 and up. This helps to automatically track down errors in the code through type safety checks and more. For example, compiler may warn you that you don't handle all possible enum values in your switch statement (i.e. when you don't have default case and handle only one out of N enum values). It also warns you when you convert an arbitrary integer into enum because enum's range of values is less than integer's and that in turn may trigger errors in the function that doesn't really accept an integer. Also, generating a jump table for the switch becomes easier when values are from 0 and up.
This is not only true for Java, but for other languages with a strict type-checking as well. C, C++, D, C# are good examples.
An enum is implictly final, with a private constructors, all its values are of the same type or a sub-type, you can obtain all its values using values(), gets its name() or ordinal() value or you can look up an enum by number or name.
You can also define subclasses (even though notionally final, something you can't do any other way)
enum Runner implements Runnable {
HI {
public void run() {
System.out.println("Hello");
}
}, BYE {
public void run() {
System.out.println("Sayonara");
}
public String toString() {
return "good-bye";
}
}
}
class MYRunner extends Runner // won't compile.
enum Benefits:
Enums are type-safe, static fields are not
There is a finite number of values (it is not possible to pass non-existing enum value. If you have static class fields, you can make that mistake)
Each enum can have multiple properties (fields/getters) assigned - encapsulation. Also some simple methods: YEAR.toSeconds() or similar. Compare: Colors.RED.getHex() with Colors.toHex(Colors.RED)
"such as the ability to easily assign an enum element a certain value"
enum EnumX{
VAL_1(1),
VAL_200(200);
public final int certainValue;
private X(int certainValue){this.certainValue = certainValue;}
}
"and consequently the ability to convert an integer to an enum without a decent amount of effort"
Add a method converting int to enum which does that. Just add static HashMap<Integer, EnumX> containing the mapping.
If you really want to convert ord=VAL_200.ordinal() back to val_200 just use: EnumX.values()[ord]
You get compile time checking of valid values when you use an enum. Look at this question.
The biggest advantage is enum Singletons are easy to write and thread-safe :
public enum EasySingleton{
INSTANCE;
}
and
/**
* Singleton pattern example with Double checked Locking
*/
public class DoubleCheckedLockingSingleton{
private volatile DoubleCheckedLockingSingleton INSTANCE;
private DoubleCheckedLockingSingleton(){}
public DoubleCheckedLockingSingleton getInstance(){
if(INSTANCE == null){
synchronized(DoubleCheckedLockingSingleton.class){
//double checking Singleton instance
if(INSTANCE == null){
INSTANCE = new DoubleCheckedLockingSingleton();
}
}
}
return INSTANCE;
}
}
both are similar and it handled Serialization by themselves by implementing
//readResolve to prevent another instance of Singleton
private Object readResolve(){
return INSTANCE;
}
more
Another important difference is that java compiler treats static final fields of primitive types and String as literals. It means these constants become inline. It's similar to C/C++ #define preprocessor. See this SO question. This is not the case with enums.
Enums can be local
As of Java 16, an enum can be defined locally (within a method). This scope is in addition to being able to define an enum as nested or as separate class.
This new local definition scope came along with the new records feature. See JEP 395: Records for details. Enums, interfaces, and records can all be defined locally in Java 16+.
In contrast, public static final fields always have global scope.
I think an enum can't be final, because under the hood compiler generates subclasses for each enum entry.
More information From source
There are many advantages of enums that are posted here, and I am creating such enums right now as asked in the question.
But I have an enum with 5-6 fields.
enum Planet{
EARTH(1000000, 312312321,31232131, "some text", "", 12),
....
other planets
....
In these kinds of cases, when you have multiple fields in enums, it is much difficult to understand which value belongs to which field as you need to see constructor and eye-ball.
Class with static final constants and using Builder pattern to create such objects makes it more readable. But, you would lose all other advantages of using an enum, if you need them.
One disadvantage of such classes is, you need to add the Planet objects manually to the list/set of Planets.
I still prefer enum over such class, as values() comes in handy and you never know if you need them to use in switch or EnumSet or EnumMap in future :)
Main reason: Enums help you to write well-structured code where the semantic meaning of parameters is clear and strongly-typed at compile time - for all the reasons other answers have given.
Quid pro quo: in Java out of the box, an Enum's array of members is final. That's normally good as it helps value safety and testing, but in some situations it could be a drawback, for example if you are extending existing base code perhaps from a library. In contrast, if the same data is in a class with static fields you can easily add new instances of that class at runtime (you might also need to write code to add these to any Iterable you have for that class). But this behaviour of Enums can be changed: using reflection you can add new members at runtime or replace existing members, though this should probably only be done in specialised situations where there is no alternative: i.e. it's a hacky solution and may produce unexpected issues, see my answer on Can I add and remove elements of enumeration at runtime in Java.
You can do :
public enum Size { SMALL(1), MEDIUM(2), LARGE(3) };
private int sizeValue;
Size(sizeValue) {this.sizeValue = value; }
So with this you can get size value like this SMALL.getSizeValue();
If you want to set sizes Enums are not for you, if you will be only define constants and fixed values are fine.
Check this link maybe can help you
If I have a class like that:
public class MyObject {
private int myField = 2;
public void setMyField(int f) {
this.myField = f;
}
}
Will objects of this class be mutable?
Thanks!
Of course - if you want it to be immutable, then you need something like:
public class MyObject {
private final int myField;
public MyObject(int f) {
myfield = f;
}
public int getMyField() {
return myField;
}
}
yes
Mutable objects have fields that can be changed, immutable objects
have no fields that can be changed after the object is created.
You already have several answers with a "Yes".
I would like to add a "but" (if I would be bold, I would say "No" ;-)
Yes, an object of this class appears to be mutable, since it provides a setter to change the field. However, since it does not have a getter for that field, neither any other getter depending on that field, and since the field is private, it is currently not possible to read that state.
Put differently: The object has state, but it does not expose any state to the outside.
I would call that object "effectively immutable".
There are some design patterns, where objects are "effectively immutable", for example "Lazy Initialization" of an "Immutable Object".
Note: The concept of being "effectively immutable" is discussed in Section 3.5.4 of Java Concurrency in Practice by Brian Goetz.
Yes, objects of this class are mutable. The designer of the class can't prohibit by any technical means (in real existing Java) consumers of the objects to observe and modify the contents of the field.
private is an explicitly declared contract regarding intended usage of the field - this contract can be broken, e.g. with reflection.
Not providing any methods that change the data of an object after creation can also be a (implicitly declared) contract about intended use and mutability - this contract, too, can be broken, like any contract that needs two conforming parties.
Edit: Unless there is another party that has the means to enforce - like in Java the SecurityManager stopping you from changing a final field at runtime.
Yes, your object is mutable as the value of myField can be changed after the instance is created using the setter.
Immutability can be achieved using final fields, as it will not allow you to change the value of a variable once it is initialized.
Answer by #JakubK points out how you can make your class Immutable.
But declaring reference final wont make the object being pointed by it final.
For example:
class MyObject{
private final List<Integer> list = new ArrayList<Integer>();
public List<Integer> getList(){
return list;
}
}
I can change add a new element to the list from outside by doing something like this
instance.getList().add(1); //mutates the list
This example is not immutable, as the List can be changed by someone else.
To define whether something is mutable, one has to define what state is encapsulated thereby. If MyObject specifies that its state includes the value which Reflection will report for myField, then it is mutable. If that field is not specified as being part of the object's observable state, then it may be most purposes regarded as immutable.
To be more specific, I would regard a class as being immutable only if one could perform any combination of documented operations upon the class, in any sequence and with any timing (even on multiple threads), and not have any documented behavioral aspects of of any of them affected by any other. The fact that a method might change the contents of a private field is relevant if and only if that change would affect some documented behavioral aspect of another method call (to the same or different method). For example, I would say that the fact that String.hashCode() modifies the hash field does not make String mutable, because the value returned by hashCode() is not affected by whether or not the field had been written previously. If a class had a hashCode method which would, if a field was blank, generate a random number and store it in that field, and otherwise return the value directly, such a class would be mutable unless it ensured that the field was tested and set as an atomic operation. In the absence of such assurance, it would be possible for near-simultaneous calls to hashCode() to yield different values, and thus for future calls to differ values that would differ from at least one of them (implying that the object's state had changed between the call that returned the odd-ball value and the later call).
This question already has answers here:
In Java, are enum types inside a class static?
(2 answers)
Closed 7 years ago.
public enum Operations {
SINGLE,
MULTIPLE;
private Type operation;
public void setOperation(Type operation) {
this.operation = operation;
}
public Type getOperation() {
return operation;
}
public static void main(String[] args) {
Operations oper1 = Operations.SINGLE;
oper1.setOperation(Type.GET);
Operations oper2 = Operations.SINGLE;
oper2.setOperation(Type.POST);
System.out.println(oper1.getOperation());
System.out.println(oper2.getOperation());
}
}
enum Type {
POST,
GET;
}
In the above code, the value of operation changes for both the Operations. How can I have two instances of Operations.SINGLE with different operation type?
Yes, instances are implicitly static and final. This means that the code is unwise. Imagine two threads both calling SINGLE.setOperation(Type); you will have no confidence in what you are calling.
From the Java Language Specification, Section 8.9:
Enum types (§8.9) must not be declared abstract; doing so will result in a compile-time error.
An enum type is implicitly final unless it contains at least one enum constant that has a class body.
It is a compile-time error to explicitly declare an enum type to be final.
Nested enum types are implicitly static. It is permissible to explicitly declare a nested enum type to be static.
And in the next section:
The body of an enum type may contain enum constants. An enum constant defines an instance of the enum type.
Because there is only one instance of each enum constant, it is permissible to use the == operator in place of the equals method when comparing two object references if it is known that at least one of them refers to an enum constant.
How can I have two instances of Operations.SINGLE with different operation type?
The fundamental idea behind an enum is that there is one, and only one, instance of each of its members. This is what lets you safely compare them for equality, without fear that there's another SINGLE or MULTIPLE created in some other place.
If you want multiple instances of SINGLE, make it a class, not an enum. The fact that you made your enum mutable indirectly points in the same direction: using enum is a wrong choice in your situation.
Enum instances are "static" (ie behave like static variables), but are not immutable.
All threads see the same object referred to by the enum name - they are like singletons, with an iron-clad guarantee from the JVM that there is only ever one instance of an enum. Changing a field of an enum changes it for everyone.
It is good practice to make your fields final in an enum and to make them immutable.
I'm one year and a half too late. But I see the question was not really answered.
The solution would be using a class instead of enum, that has those two enums as its fields:
class Operation {
Quantity quantity;
Type type;
Operation(Quantity quantity, Type type) {
this.quantity = quantity;
this.type = type;
}
}
You can, of course, use enum instead of class. Then you'll have to enumerate all combinations:
enum Operation {
SINGLE_GET(Quantity.SINGLE, Type.GET)
SINGLE_POST(Quantity.SINGLE, Type.POST)
MULTIPLE_GET(Quantity.MULTIPLE, Type.GET)
// ... more options
// contents same as in class Operation, constructor private by default
}
Both approaches are valid, sometimes you really want to enumerate all the combinations, most of the time, however, you should probably stick with the class approach.
For brevity, I didn't define the enums Quantity and Type, they are just simple enums.
Yes, all elements of enum are static final constant.
However as mentioned in another answer by darijan, there is a logical mistake in your program.
There is an error in fourth line of main method
oper1.setOperation(Type.POST);
should be
oper2.setOperation(Type.POST);