We Keep Coding

Using enums as List elements in Java possible?

I have a state which could be parametrized by a some variables which are discret. So each variable could be described with a few enum values. But the number of variables may vary.
The following code is impossible:
public enum Var0 {
LEFT, RIGHT;
}
public enum Var1 {
TOP, BOTTOM;
}
// somewhere
List<enum> vars = new ArrayList<>(); // this is not working
vars.set(0,Var0); // put the whole enum in a list element
vars.set(1, Var1);
// somewhere else I want something like this
for (int i = 0; i < vars.get(i).values().length; i++) {
vars.get(i).
for (Enum var : vars.get(i).values()) {
System.out.println(var.name())
..
}
}
// or this ??
System.out.println(vars.get(1).values()[1]) //
...
Any suggestions if/ how one could use enums in such scenario are welcome

Var0 and Var1 are classes, so it is a compile-time error to write vars.set(0, Var0) where an expression is expected. It's also a syntax error to write List<enum> because enum is not a type; Enum is.
However, what you want to do is possible using a list of arrays of Enum values:
List<Enum[]> vars = new ArrayList<>();
vars.add(Var0.values());
vars.add(Var1.values());
for(Enum[] e : vars) {
for(Enum v : e) {
System.out.println(v.name());
}
}

Not exactly what you were asking, but you can actually flatten the list and get rid of the arrays if you really want to:
public class EnumsWithInterface {
public interface VarIf {
String name();
}
public enum Var0 implements VarIf {
LEFT, RIGHT;
}
public enum Var1 implements VarIf {
TOP, BOTTOM;
}
public static void main(String[] args) {
List<VarIf>vars = new ArrayList<VarIf>();
vars.addAll(Arrays.asList(Var0.values()));
vars.addAll(Arrays.asList(Var1.values()));
for (VarIf var : vars) {
System.out.println(var.name());
}
}
}
Making a Set out of it would make even more sense I suppose. Note that you have to check / cast if you want to have an enum variable again, as that's lost during compile time.

How should I refactor code using Optional and ifPresent(...) to... not?

I'm very new to Java. I'm faced with two classes, FooRequest and BarRequest. (Simplified for this question, of course.)
public class FooRequest {
private String a;
private String b;
private String c;
private DateTime x;
private DateTime y;
private BigDecimal z;
// ... and more members
// ... getters and setters for each member
}
And the other class:
public class BarRequest {
private Optional<DateTime> x;
private Optional<DateTime> y;
private Optional<BigDecimal> z;
// ... getters and setters for each member
}
These were written by different people, one preferring null checks upon use, the other preferring Optional. But because FooRequest has many more members, is in widespread use, and completely covers all of BarRequest's members, I'm tasked with getting rid of BarRequest, using the more popular FooRequest instead.
Now, at first I thought I might just "upgrade" FooRequest's members (at least the 3 used by BarRequest) to Optional<>. However, this caused numerous compilation issues (basically, everywhere FooRequest was returned or used). I learned Optional<T> cannot drop-in replace T.
My team-lead confirmed it was not practical to keep Optional<>. To minimize changes, we'd want to rewrite any code previously using Optional<>. For example,
request.getDateBegin().ifPresent((dateBegin) -> {
if (!dateBegin.equals(ad.startDate())) {
// ...
}
}
Here's my attempt at converting this:
if (request.getDateBegin() != null) {
DateTime dateBegin = request.getDateBegin();
if (!dateBegin.equals(ad.startDate())) {
// ...
}
}
Is this correct? Am I missing something by simply doing a null comparison? Is there any way to use a lambda expression inside and avoid creating a DateTime temporary?

Yes, it seems to be that your attempt to convert the optional code into the typical imperative code is correct in terms of functionality. However, calling request.getDateBegin() twice is sub-optimal even if the call is not expensive it can be avoided.
Thus, I'd cache the result of request.getDateBegin() into a variable and operate on that.
If you're going to do this type of logic many times then you can put it into a method as such:
public boolean someMethodName(DateTime date, DateTime another){
if(date != null && !date.equals(another)){
// do logic
return true; // successful
}
return false; // not successful
}
the return type of the method is arguable so I'll leave that to you to decide.

if (request.getDateBegin() != null) {
DateTime dateBegin = request.getDateBegin();
if (!dateBegin.equals(ad.startDate())) {
// ...
}
}
can be replaced with
Optional.ofNullable(request.getDateBegin())
.filter(date -> !date.equals(ad.startDate()))
.ifPresent(date -> {
// ... whatever
});

What's the best way to implement `next` and `previous` on an enum type?

Suppose I have an enum:
enum E {
A, B, C;
}
As shown in this answer by lucasmo, enum values are stored in a static array in the order that they are initialized, and you can later retrieve (a clone of) this array with E.values().
Now suppose I want to implement E#getNext and E#getPrevious such that all of the following expressions evaluate to true:
E.A.getNext() == E.B
E.B.getNext() == E.C
E.C.getNext() == E.A
E.A.getPrevious() == E.C
E.B.getPrevious() == E.A
E.C.getPrevious() == E.B
My current implementation for getNext is the following:
public E getNext() {
E[] e = E.values();
int i = 0;
for (; e[i] != this; i++)
;
i++;
i %= e.length;
return e[i];
}
and a similar method for getPrevious.
However, this code seems cumbersome at best (e.g., "empty" for loop, arguable abuse of a counter variable, and potentially erroneous at worst (thinking reflection, possibly).
What would be the best way to implement getNext and getPrevious methods for enum types in Java 7?
NOTE: I do not intend this question to be subjective. My request for the "best" implementation is shorthand for asking for the implementation that is the fastest, cleanest, and most maintainable.

Try this:
public enum A {
X, Y, Z;
private static final A[] vals = values();
public A next() {
return vals[(this.ordinal() + 1) % vals.length];
}
}
Implementation of previous() is left as an exercise, but recall that in Java, the modulo a % b can return a negative number.
EDIT: As suggested, make a private static copy of the values() array to avoid array copying each time next() or previous() is called.

Alternatively, one can go somehow along the lines of the following idea:
public enum SomeEnum {
A, B, C;
public Optional<SomeEnum> next() {
switch (this) {
case A: return Optional.of(B);
case B: return Optional.of(C);
// any other case can NOT be mapped!
default: return Optional.empty();
}
}
Notes:
In contrast to the other answer, this way does some implicit mapping; instead of relying on ordinal(). Of course that means more code; but it also forces the author to consider what it means to add new constants or remove existing ones. When relying on ordinal, your implicit assumption is that the order is based on the order used for the enum constant declaration. So when somebody comes back 6 months later and has to add a new constant, he has to understand that the new constant Y needs X, Y, Z ... instead of just appending X, Z, Y!
There might be situations where it doesn't make any sense for the "last" enum constant to have the "first" as successor. Think of T-Shirt sizes for examples. XXL.next() is for sure not XS. For such situations, using Optional is the more appropriate answer.

public enum Three
{
One, Two, Three;
static
public final Three[] values = values();
public Three prev() {
return values[(ordinal() - 1 + values.length) % values.length];
}
public Three next() {
return values[(ordinal() + 1) % values.length];
}
}

Here's another take at the problem:
public enum Planet {
MERCURY, VENUS, EARTH, MARS, JUPITER, SATURN, URANUS, NEPTUNE;
private Planet prevPlanet = null;
private Planet nextPlanet = null;
static {
for (int i = 1; i <= values.length; i++) {
Planet current = values[i % values.length];
current.prevPlanet = values[i - 1];
current.nextPlanet = values[(i + 1) % values.length];
}
}
public Planet prev() {
return prevPlanet;
}
public Planet next() {
return nextPlanet;
}
}
With this approach, all calculations are done during static initialization and the actual methods directly return the result from a member variable.
However, I would argue that for this enum (and for most enums in general), wrapping around doesn't make sense, so I would rather do it this way:
import java.util.Optional;
public enum Planet {
MERCURY, VENUS, EARTH, MARS, JUPITER, SATURN, URANUS, NEPTUNE;
private Planet prevPlanet = null;
private Planet nextPlanet = null;
static {
Planet[] values = Planet.values();
for (int i = 1; i < values.length; i++) {
values[i].prevPlanet = values[i - 1];
}
for (int i = 0; i < values.length - 1; i++) {
values[i].nextPlanet = values[i + 1];
}
}
public Optional<Planet> prev() {
return Optional.ofNullable(prevPlanet);
}
public Optional<Planet> next() {
return Optional.ofNullable(nextPlanet);
}
}
Here, the first planet does not have a previous one and the last one does not have a next one. Optional is used to make it even more explicit that callers of the code need to be prepared that not every planet has a next/previous one. Whether you want to use Optional is up to you, the code works just as well with the getters of the first implementation, in which case a null would be returned directly instead of as an empty Optional.
Another thing to consider is that the desired ordering may not match the enumeration of the values. There could also be special values in the enum that do not fit in the ordering. Or you could just want to make the specification of the ordering explicit so that one can not accidentally break the logic by adding a new value to the enum out of order. Then you can do this:
import java.util.Optional;
public enum Planet {
MERCURY, VENUS(MERCURY), EARTH(VENUS), MARS(EARTH), JUPITER(MARS),
SATURN(JUPITER), URANUS(SATURN), NEPTUNE(URANUS);
private Planet prevPlanet = null;
private Planet nextPlanet = null;
Planet() {}
Planet(Planet prev) {
this.prevPlanet = prev;
prev.nextPlanet = this;
}
public Optional<Planet> prev() {
return Optional.ofNullable(prevPlanet);
}
public Optional<Planet> next() {
return Optional.ofNullable(nextPlanet);
}
}

This doesn't allow for wraparounds, but you could use this as a low-impact way to check adjacency:
enum Phase {
ONE, TWO, THREE;
public final Phase previous;
Phase() {
previous = Data.last;
Data.last = this
}
private static class Data {
private static Phase last = null;
}
}
class Example {
Phase currentPhase = Phase.ONE;
void advanceToPhase(Phase nextPhase) {
if (nextPhase.previous == currentPhase)
currentPhase = nextPhase;
}
}
It has to use an auxiliary static class to store a variable for the static initializer, but it has the advantage of being extremely low-cost at startup.

Same approach as #Zoltan but without optional :
public enum Planet {
MERCURY, VENUS(MERCURY), EARTH(VENUS), MARS(EARTH), JUPITER(MARS),
SATURN(JUPITER), URANUS(SATURN), NEPTUNE(URANUS);
private Planet prevPlanet = null;
private Planet nextPlanet = null;
Planet() {
// required for Mercury
}
Planet(Planet prev) {
prevPlanet = prev;
prev.nextPlanet = this;
}
public Planet prev() {
return this == MERCURY ? this : prevPlanet;
}
public Planet next() {
return this == NEPTUNE ? this : nextPlanet;
}
}

TreeSet-based implementation
We can implement an enum capable of retrieving next and previous members via instance methods next() and previous() by using TreeSet, which maintains a Red-black tree under the hood, and offers methods for traversing the tree like higher() and lower().
The implementation below would in a way similar to a circular list, retrieving the fist enum-constant when next() is invoked on the very last constant, and vice versa returning the last when previous() is called on the very first constant.
Instead of hard-coding the fist and the last enum-members inside the next() and previous() when we hit edge-cases, we can use methods first() and last(). By doing so, we're eliminating the possibility of introducing a bug, if someone would decide to add a few more constants or reorder them.
public enum Enum {
A, B, C, D, E, F, G;
private static final NavigableSet<Enum> set =
new TreeSet<>(EnumSet.allOf(Enum.class)); // EnumSet.allOf() generates a set of enum-constants of the specified type
public Enum next() {
return Objects.requireNonNullElseGet(
set.higher(this), set::first
);
}
public Enum previous() {
return Objects.requireNonNullElseGet(
set.lower(this), set::last
);
}
}
Note: both higher() and lower() would return null if the requested element doesn't exist. To dial with the edge-cases I've used Java 11 utility method Objects.requireNonNullElseGet() which expects a nullable value and a Supplier that would be used only if provided value is null (reminder: Java 8 functions are lazy).
main()
public static void main(String[] args) {
EnumSet.allOf(Enum.class).forEach(e ->
System.out.println(e + " -> " + " next: " + e.next() + " prev: " + e.previous())
);
}
Output:
A -> next: B prev: G
B -> next: C prev: A
C -> next: D prev: B
D -> next: E prev: C
E -> next: F prev: D
F -> next: G prev: E
G -> next: A prev: F
Performance Note
All the methods of the TreeSet used above have logarithmic time complexity O(log n), which in most of the real life scenarios would result in only a couple of steps through the tree, since the waste majority of enums have fewer than ten constants. Therefore, we can call it acceptable, but it can't beat constant time the performance of the straightforward solution provided in the answer by Jim Garrison.
That said, the code above is meant to serve educational purposes by illustrating how a TreeSet can be utilized.

Enumeration help/advice - java

Is it possible to use an enumeration in the following circumstance:
Let’s say you have a certain amount of predefined 'read types'. Example read types could be: Diagnostic, KWH, MaxDemand, OnPeak, etc. And for each of these read types, there’s a ‘TIMTagNumber’ which is essientally a protocol for retrieving each predefined read type.
For example, TIMTagNumber 1100 would retrieve the read type Diagnostic
TIMTagNumber 1300 would retrieve the read type KWH.
The problem is that a predefined read type can sometimes be retrieved by more than one TIMTagNumber.
I want to create an enumeration ReadType that would define each read type and all TIMTagNumbers that can be used to retrieve that read.
Can you use an enumeration in this way?
public enum ReadType{
KWH(1300)
Diagnostic(1100)
ReadType3(1400, 1401) // This read can be retrieved by both 1400 and 1401
}
If an enumeration is not the way to go, is there an elegant or efficient way to define these read types? The overall desired outcome of all this essientally is being recognizing what type of read it is based on the TIMTagNumbers.
I.E. Given 1400 OR 1401 you would know that it's 'ReadType3'.

Can you do this? Yes. Whether it's the right decision will depend on whether you want to couple these TIMTagNumbers to the read type. If not, a simple Map<Integer, ReadType> will probably suffice.
Here's how you could do it:
public static enum MyEnum {
KWH(1300),
Diagnostic(1100),
ReadType3(1400, 1401);
private Set<Integer> timTagNumbers;
MyEnum(Integer... timTagNumbers) {
this.timTagNumbers = new HashSet<Integer>(Arrays.asList(timTagNumbers));
//add check to make sure that values are unique across all instances
}
public static MyEnum forTIMTagNumber(int num) {
for ( MyEnum readType : values() ) {
if ( readType.timTagNumbers.contains(num) ) {
return readType;
}
}
throw new NoSuchElementException("No ReadType matching TIMTagNumber " + num);
}
}
//...
int timTagNumber = 1400;
ReadType readType = ReadType.forTIMTagNumber(timTagNumber);
As I said above, this style works well when the data and the enum types are intrinsically coupled already. It would not be good for when the enum type is decoupled from the mapped values (e.g. the values are used for one of many ways of serializing the enum) or if the values are configuration-specific or even dynamic (e.g. if they were prices on an item). In these cases it is usually best to externalize this mapping in an EnumMap or Map.

public enum ReadType {
KWH(1300),
Diagnostic(1100),
ReadType3(1400, 1401);
private int[] timTagNumbers;
private ReadType(int ... numbers) {
this.timTagNumbers = numbers;
}
public int[] getTimTagNumbers() {
return timTagNumbers;
}
public static ReadType forTimTagNumber(int n) {
for (ReadType type : values()) {
if (Arrays.binarySearch(type.timTagNumbers, n) != -1) {
return type;
}
}
throw new NoSucheElementException(); // if not found
}
With this you can do
int[] timTagNumbers = ReadType.Diagnostic.getTimTagNumbers(); // [ 1100 ]
and
ReadType type3 = ReadType.forTimTagNumber(1401); // ReadType.ReadType3

You can indeed use enumerations in that way, but your example is missing a private field and a constructor.
Something like:
public enum Bla{
CASE1(100),CASE2(200);
private int amount;
private Bla(int amount) {
this.amount = amount;
}
public Bla getByValue(int value){
switch (value) {
case 100: return CASE1;
case 200: return CASE2;
}
return null;
}
}
I've included a "reverse lookup" method that returns an Enum given the value.
The main advantage is that you can have the rest of your code using "Bla" instead of int's which will guarantee type-safety on your operations, basically, it'll make impossible to pass an invalid int value as a method parameter (and you can use switch statements over enums too, and that's pretty awesome in some usage scenarios).
EDIT: I noticed after I posted that you need more then one int to specify the Enum, but the same logic applies, with the due changes in the methods, of course.

You could do something like the following, when you supply values in the parentheses where the enum variable is declared, it is calling the constructor of the enum. You need to create a different method in the enum itself to get the enum type from the integer value. See below.
public enum ReadType {
KWH(), DIAGNOSTIC(), READTYPE3();
public ReadType getReadType(int num) {
ReadType toReturn = KWH;
switch (num) {
case 1300:
toReturn = KWH;
break;
case 1100:
toReturn = DIAGNOSTIC;
break;
case 1400:
toReturn = READTYPE3;
break;
case 1401:
toReturn = READTYPE3;
break;
}
return toReturn;
}

If you can impose some restrictions like no more than 2 tags can be associated with a read type and each tag is no greater than 2^15, then you can store the two numbers into 1 integer. See this S/O post for more details.

Is it possible to loop setters and getters?

I'm fairly confident that there's no way this could work, but I wanted to ask anyway just in case I'm wrong:
I've heard many times that whenever you have a certain number of lines of very similar code in one batch, you should always loop through them.
So say I have something like the following.
setPos1(getCard1());
setPos2(getCard2());
setPos3(getCard3());
setPos4(getCard4());
setPos5(getCard5());
setPos6(getCard6());
setPos7(getCard7());
setPos8(getCard8());
setPos9(getCard9());
setPos10(getCard10());
setPos11(getCard11());
setPos12(getCard12());
There is no way to cut down on lines of code as, e.g., below, right?
for (i = 0; i < 12; i++) {
setPos + i(getCard + i)());
}
I'm sure this will have been asked before somewhere, but neither Google nor SO Search turned up with a negative proof.
Thanks for quickly confirming this!

No way to do that specifically in Java without reflection, and I don't think it would be worth it. This looks more like a cue that you should refactor your getcard function to take an integer argument. Then you could loop.

This is a simple snippet that shows how to loop through the getters of a certain object to check if the returned values are null, using reflection:
for (Method m : myObj.getClass().getMethods()) {
// The getter should start with "get"
// I ignore getClass() method because it never returns null
if (m.getName().startsWith("get") && !m.getName().equals("getClass")) {
// These getters have no arguments
if (m.invoke(myObj) == null) {
// Do something
}
}
}
Like the others stated, probably it's not an elegant implementation. It's just for the sake of completeness.

You could do it via reflection, but it would be cumbersome. A better approach might be to make generic setPos() and getCard() methods into which you could pass the index of the current item.

You need to ditch the getter/setter pairs, and use a List to store your objects rather then trying to stuff everything into one God object.
Here's a contrived example:
import java.util.ArrayList;
import java.util.Arrays;
import java.util.List;
public class Foo {
public static class Card {
int val;
public Card(int val) {
this.val = val;
}
public int getVal() {
return val;
}
}
public static class Position {
int value;
public Position(Card card) {
this.value = card.getVal();
}
}
public static void main(String[] args) {
List<Card> cards = new ArrayList<Card>(Arrays.asList(new Card(1), new Card(2), new Card(3)));
List<Position> positions = new ArrayList<Position>();
for (Card card : cards) {
positions.add(new Position(card));
}
}
}

You can't dynamically construct a method name and then invoke it (without reflection). Even with reflection it would be a bit brittle.
One option is to lump all those operations into one method like setAllPositions and just call that method.
Alternatively, you could have an array of positions, and then just loop over the array, setting the value at each index.
Card[] cardsAtPosition = new Card[12];
and then something like
public void setCardsAtEachPosition(Card[] valuesToSet) {
// check to make sure valuesToSet has the required number of cards
for (i = 0; i < cardsAtPosition.length; i++) {
cardsAtPosition[i] = valuesToSet[i];
}
}

Reflection would be your only option for your example case.