We Keep Coding

Identify record that is culprit - coding practices

Is method chaining good?
I am not against functional programming that uses method chaining a lot, but against a herd mentality where people mindlessly run behind something that is new.
The example, if I am processing a list of items using stream programming and need to find out the exact row that resulted into throwing NullPointerException.
private void test() {
List<User> aList = new ArrayList<>();
// fill aList with some data
aList.stream().forEach(x -> doSomethingMeaningFul(x.getAddress()));
}
private void doSomethingMeaningFul(Address x) {
// Do something
}
So in the example above if any object in list is null, it will lead to NullPointerException while calling x.getAddress() and come out, without giving us a hook to identify a User record which has this problem.
I may be missing something that offers this feature in stream programming, any help is appreciated.
Edit 1:
NPE is just an example, but there are several other RuntimeExceptions that could occur. Writing filter would essentially mean checking for every RTE condition based on the operation I am performing. And checking for every operation will become a pain.
To give a better idea about what I mean following is the snippet using older methods; I couldn't find any equivalent with streams / functional programming methods.
List<User> aList = new ArrayList<>();
// Fill list with some data
int counter = 0;
User u = null;
try {
for (;counter < aList.size(); counter++) {
u = aList.get(counter);
u.doSomething();
int result = u.getX() / u.getY();
}
} catch(Exception e) {
System.out.println("Error processing at index:" + counter + " with User record:" + u);
System.out.println("Exception:" + e);
}
This will be a boon during the maintenance phase(longest phase) pointing exact data related issues which are difficult to reproduce.
**Benefits:**
- Find exact index causing issue, pointing to data
- Any RTE is recorded and analyzed against the user record
- Smaller stacktrace to look at

Is method chaining good?
As so often, the simple answer is: it depends.
When you
know what you are doing
are be very sure that elements will never be null, thus the chance for an NPE in such a construct is (close to) 0
and the chaining of calls leads to improved readability
then sure, chain calls.
If any of the above criteria isn't clearly fulfilled, then consider not doing that.
In any case, it might be helpful to distribute your method calls on new lines. Tools like IntelliJ actually give you advanced type information for each line, when you do that (well, not always, see my own question ;)
From a different perspective: to the compiler, it doesn't matter much if you chain call. That really only matters to humans. Either for readability, or during debugging.

There are a few aspects to this.
1) Nulls
It's best to avoid the problem of checking for nulls, by never assigning null. This applies whether you're doing functional programming or not. Unfortunately a lot of library code does expose the possibility of a null return value, but try to limit exposure to this by handling it in one place.
Regardless of whether you're doing FP or not, you'll find you get a lot less frustrated if you never have to write null checks when calling your own methods, because your own methods can never return null.
An alternative to variables that might be null, is to use Java 8's Optional class.
Instead of:
public String myMethod(int i) {
if(i>0) {
return "Hello";
} else {
return null;
}
}
Do:
public Optional<String> myMethod(int i) {
if(i>0) {
return Optional.of("Hello");
} else {
return Optional.empty();
}
Look at Optional Javadoc to see how this forces the caller to think about the possibility of an Optional.empty() response.
As a bridge between the worlds of "null represents absent" and "Optional.empty() represents absent", you can use Optional.ofNullable(val) which returns Empty when val == null. But do bear in mind that Optional.empty() and Optional.of(null) are different values.
2) Exceptions
It's true that throwing an exception in a stream handler doesn't work very well. Exceptions aren't a very FP-friendly mechanism. The FP-friendly alternative is Either -- which isn't a standard part of Java but is easy to write yourself or find in third party libraries: Is there an equivalent of Scala's Either in Java 8?
public Either<Exception, Result> meaningfulMethod(Value val) {
try {
return Either.right(methodThatMightThrow(val));
} catch (Exception e) {
return Either.left(e);
}
}
... then:
List<Either<Exception, Result>> results = listOfValues.stream().map(meaningfulMethod).collect(Collectors.toList());
3) Indexes
You want to know the index of the stream element, when you're using a stream made from a List? See Is there a concise way to iterate over a stream with indices in Java 8?

In your test() function you are creating an emptylist List<User> aList = new ArrayList<>();
And doing for each on it. First add some element to
aList
If you want to handle null values you can add .filter(x-> x != null) this before foreach it will filter out all null value
Below is code
private void test() {
List<User> aList = new ArrayList<>();
aList.stream().filter(x-> x != null).forEach(x -> doSomethingMeaningFul(x.getAddress()));
}
private void doSomethingMeaningFul(Address x) {
// Do something
}

You can write a black of code in streams. And you can find out the list item which might result in NullPointerException. I hope this code might help
private void test() {
List<User> aList = new ArrayList<>();
aList.stream().forEach(x -> {
if(x.getAddress() != null)
return doSomethingMeaningFul(x.getAddress())
else
system.out.println(x+ "doesn't have address");
});
}
private void doSomethingMeaningFul(Address x) {
// Do something
}
If you want you can throw NullPointerException or custom excption like AddressNotFoundException in the else part

How to design a model to allow apply or cancel updates?

Is there a design or development pattern where we deal with making updates to a copy of the actual data and applying the diff to the original reference if needed?
If not, what is the best way of designing such models?
What I think I should do:
I should probably use an enum mode to indicate whether the model is being used in 'Update direct reference mode' OR 'Update only a copy mode'
Update the setters and getters of data to reference the actualState or the temporaryState as per what mode is the model being used in.
Have the setter method for mode to create a copy of the actual data and store it in a temporary state. If the mode is updated to update direct reference, clear out the temporaryState
Create a method for applying the changes from temporaryState to the actualState. This method shall also clear out the temporary state from memory.
In code:
enum InsertionMode {
UPDATE_DIRECT, UPDATE_COPY
}
class Store {
private Data actualState;
private Data temporaryState;
private InsertionMode mode;
private void resetTemporaryState() {
....
}
private void initTemporaryState() {
this.temporaryState = copy(actualState);
}
private commitTemporaryState() {
this.actualState = this.temporaryState;
this.resetTemporaryState();
}
public Data setInsertionMode(InsertionMode mode) {
if (this.mode != mode) {
InsertionMode previousMode = this.mode;
this.mode = mode;
if (previousMode == InsertionMode.UPDATE_COPY) {
this.resetTemporaryState();
}
if (this.mode == InsertionMode.UPDATE_COPY) {
this.initTemporaryState();
}
}
}
public void commit() {
if (this.mode == InsertionMode.UPDATE_COPY) {
this.commitTemporaryState();
}
}
public void abort() {
if (this.mode == InsertionMode.UPDATE_COPY) {
this.resetTemporaryState();
this.setInsertionMode(InsertionMode.UPDATE_DIRECT);
}
}
...
}

The given code is "okay", as it will support your requirements.
But: updating objects is a simple approach, and is easy to implement. But depending on your context, you do things really differently in 2017.
Instead of having one mutable object that changes state, you could instead go for immutable objects. State becomes a sequence of such objects.
Reaching a new state means adding a newly created object at the end of the sequence, cancel means to go with the old, unchanged sequence. This approach is the base for blockchain applications; but it can be scaled down to a smaller context as well - just by looking at its core aspect: you never change state by changing existing objects, but by creating new objects. Of course, this needs a lot of thought; you don't want to blindly duplicate everything; you might more be looking having "delta" objects (that represent individual changes) and "views" that show aggregations of deltas.
Beyond that: you might want to read about CQRS versus CRUD (for example this).

Method reference and boolean

So I have been having a go with using the method reference in Java 8 (Object::Method). What I am attempting to do, which I have done before but have forgotten (last time I used this method reference was about 4 months ago), is find the amount of players that != online using the Method Reference.
public static Set<Friend> getOnlineFriends(UUID playerUUID)
{
Set<Friend> friends = new HashSet<>(Arrays.asList(ZMFriends.getFriends(playerUUID)));
return friends.stream().filter(Friend::isOnline).collect(Collectors.toSet());
}
public static Set<Friend> getOfflineFriends(UUID playerUUID)
{
Set<Friend> friends = new HashSet<>(Arrays.asList(ZMFriends.getFriends(playerUUID)));
return friends.stream().filter(Friend::isOnline).collect(Collectors.toSet());
As you can see I managed to so it when the player (friend) is online but I cannot figure out how to filter though the Set and collect the offline players. I'm missing something obvious, but what is it?!?!
Thanks,
Duke.

In you code
public static Set<Friend> getOnlineFriends(UUID playerUUID)
{
Set<Friend> friends = new HashSet<>(Arrays.asList(ZMFriends.getFriends(playerUUID)));
return friends.stream().filter(Friend::isOnline).collect(Collectors.toSet());
}
you are creating a List view to the array returned by ZMFriends.getFriends(playerUUID), copy its contents to a HashSet, just to call stream() on it.
That’s a waste of resources, as the source type is irrelevant to the subsequent stream operation. You don’t need to have a Set source to get a Set result. So you can implement your operation simply as
public static Set<Friend> getOnlineFriends(UUID playerUUID)
{
return Arrays.stream(ZMFriends.getFriends(playerUUID))
.filter(Friend::isOnline).collect(Collectors.toSet());
}
Further, you should consider whether you really need both, getOnlineFriends and getOfflineFriends in your actual implementation. Creating utility methods in advance, just because you might need them, rarely pays off. See also “You aren’t gonna need it”.
But if you really need both operations, it’s still an unnecessary code duplication. Just consider:
public static Set<Friend> getFriends(UUID playerUUID, boolean online)
{
return Arrays.stream(ZMFriends.getFriends(playerUUID))
.filter(f -> f.isOnline()==online).collect(Collectors.toSet());
}
solving both tasks. It still wastes resource, if the application really needs both Sets, as the application still has to perform the same operation twice to get both Sets. Consider:
public static Map<Boolean,Set<Friend>> getOnlineFriends(UUID playerUUID)
{
return Arrays.stream(ZMFriends.getFriends(playerUUID))
.collect(Collectors.partitioningBy(Friend::isOnline, Collectors.toSet()));
}
This provides you both Sets at once, the online friends being associated to true, the offline friends being associated to false.

There are 2 ways I can think of:
friends.stream().filter(i -> !i.isOnline()).collect(Collectors.toSet());
But I guess that's not what you want, since it's not using a method reference. So maybe something like this:
public static <T> Predicate<T> negation(Predicate<T> predicate) {
return predicate.negate();
}
...
friends.stream().filter(negation(Friend::isOnline)).collect(Collectors.toSet());

Is MemcacheService fundamentally a singleton

The answer to this question seems obvious, but I need to be completely sure. So if answer can provide authoritative reference with clear non-ambiguous statements, that would be great.
Say I have the following two methods
public CollectionResponse<Dog> getDogs(Identification request){
MemcacheService syncCacheDog = MemcacheServiceFactory.getMemcacheService();
syncCacheDog.setErrorHandler(ErrorHandlers.getConsistentLogAndContinue(Level.INFO));
// ........
value = (byte[]) syncCacheDog.get(key); // read from cache
if (value == null) {
// get value from other source
// ........
syncCacheDog.put(key, value); // populate cache
}
// ........
}
public CollectionResponse<Cat> getCats(Identification request){
MemcacheService syncCacheCat = MemcacheServiceFactory.getMemcacheService();
syncCacheCat.setErrorHandler(ErrorHandlers.getConsistentLogAndContinue(Level.INFO));
// ........
value = (byte[]) syncCacheCat.get(key); // read from cache
if (value == null) {
// get value from other source
// ........
syncCacheCat.put(key, value); // populate cache
}
// ........
}
Are syncCacheDog and syncCacheCat pointing to the same map? Or if I want them to be pointing to the same map, do I have to create
static MemcacheService syncCache = MemcacheServiceFactory.getMemcacheService();
and then use syncCache inside both methods?
On the other hand, if it is a singleton, how do I maintain two different caches? I.e. can someone please copy and paste one of my methods and show it written with a namespace and instead of dealing with generic byte to deal with a specific object such as Dog?

Yes, from my experience with GAE and its documentation, Memcache service is a singleton. Even more, different versions of the application all see the same cache.
In order to maintain different caches do the usual: use a prefix. Maintaining a unique set of prefixes for different classes should be relatively easy - have an enum somewhere, keeping track of the maximum prefix. And never reuse the old prefix numbers.
public enum MemcachePrefix {
DOGS(1),
CATS(2);
// Max: 2.
public final int value;
private MemcachePrefix (int value) {this.value = value;}
};
public class Dog {
static final MemcachePrefix MEMCACHE_PREFIX = MemcachePrefix.DOGS;
};
class Main {
public static void main (String[] args) {
Dog dog = new Dog();
System.out.println (dog.MEMCACHE_PREFIX);
}
}
There is also Namespaces. Instead of manually adding the prefix to the cache key you can use it as a namespace, letting GAE do the key manipulations for you.

Best approach to refactor this java snippet

I was told it is not a good style to call potentially costly methods for boolean expressions (getSupercategories()).
private final SuperCategoriesResolver<ProductModel> catResolver = new SuperCategoriesResolver<ProductModel>() {
#Override
public Set<CategoryModel> getSuperCategories(final CategoryModel item) {
return item == null || item.getSupercategories() == null ? Collections.EMPTY_SET
: new LinkedHashSet<CategoryModel>(
item.getSupercategories());
}
};
As well that getSupercategories() is potentially dangerous since it's backed by a relation attribute which might not be coming from local data members (item is sent as a parameter to a public method in this class and after wards is sent to getSuperCategories() which is overriden in the same class when declaring catResolver).
Is this a better approach to tackle the argument above?
private final SuperCategoriesResolver<ProductModel> catResolver = new SuperCategoriesResolver<ProductModel>() {
#Override
public Set<CategoryModel> getSuperCategories(final ProductModel item) {
if (item != null) {
Set<CategoryModel> superCategories = (Set<CategoryModel>) item
.getSupercategories();
if (superCategories != null)
return superCategories;
}
return Collections.EMPTY_SET;
}
};
Where I first verify that item is not null. if it is, then a return empy_set if not then I called the costly method and get the collection and just if it is not null return the collection with elements.
Thank u very much for your advice.

It is likely to get more efficient to call getSupercategories() once instead of twice if it does any computation.
Do you need to return a copy of this set? You do in the first example but not the second.

Second approach is indeed faster because there is only one call to the getSupercategories method if item is not null. However, in your second approach, you no longer create a LinkedHashSet instance -- which means it will behave differently (though faster).
This sounds more like performance optimization as opposed to refactoring. Usually when you refactor something, there is a "factor" in there somwhere, that trims the code down by eliminating redundancies.

Nulls are your problem. Can you make a refactoring to push nulls away?
For example, you could refactor your code to make item.getSuperCategories never return null? Or do you need to distinguish between the empty set and null?
Similarly, why are you passing null into this method? If you can eliminate that scenario then the code just becomes a one liner.