Python got array comparison.
Erlang got list and/or tuple comparison.
Even old plain C has memcmp() to compare arrays of bytes.

But for java, you can as well get lost to compare two arrays of basic types, like char, or int.

Or you reimplement your own Comparable objects, encapsulating the array... Well, seems like it's the only option.

Did you ever encountered projects where low-level functions launched different sorts of Java exceptions so that any high-level method threw Exception? I did. Not only the treatment of errors was kind of a guesswork, but I also thought it pretty much killed the principle of having a distinction between Exception and RuntimeException.

At that time, i just had discovered the principle of fail-fast when attempting to modify a list i was reading. It struck me that, in the context of small, exploratory, student project software, it was often more efficient to let the program crash instead of trying to recover from the error.

From that, I came up with the following guidelines:

• If a failure is a normal outcome, use special return values. Example: there is no solution to the equation given to the symbolic solver class, return a NaN or a null. Even better, return a pair ["error", "description of the error"] instead of the normal ["ok", 42]. However this is not always practical in java.
  
• Only throw normal exceptions you want to deal with at the level right above: they will be meaningless at higher levels.
• Throw RuntimeExceptions when there is an obvious programmer error: just slap your teammate in the face with a good exception when he's too lazy to glance at the sentence "x >= 0" you wrote in the documentation. Besides, it will help yourself to debug during those project sprints when you don't remember anymore how you wrote this class three months ago.
• Throw RuntimeExceptions when there are errors you don't want to bother with, at least when the project is small. That is, you know your file exists, is readable/writable because you dealt with the FileNotFoundException and the IOException on the opening of the file, but you are reading it further in your code. In my humble opinion, if the user disconnects his external drive while you read a file on it, he can as well go fuck himself.
  

This should be coupled with the declaration of the RuntimeExceptions a function manually throws, so that if the level right above really wants to deal with it, it can, and don't have to fight ghosts.

Crashing a program on error might be shocking. However, failing like this is better for the overall reliability of the system: bugs are detected faster and a module does not try to continue operation in a messed up state. This also allows the module to fail and be restarted if the system has to be highly fault-tolerant.

Seems like closures have chances to make their appearance in java 8... I hope it becomes true :)

I found it while searching the web for an implementation of the filter() function on a list. My own using a generic "Predicate" interface failed badly :(

sources:
http://javac.info/
http://stackoverflow.com/questions/3007563/java-7-closure-syntax#3007667

Java was my first programming language. With time, however, i came to criticize it.... Despite this, i conceded to do my master thesis in java with my pal since we are two students for the subject.

So, i encountered multiple cases where python's "in" operator (see in the table here) would have been perfect. After generic reimplementation (see below), i still found myself caged in java's verbose syntax.

For example, if i wanted to check whether a value in a list of arguments was false, i still had to do things like:

Which is still rather verbose.

Wasting my time in the documentation as i like to do, i came to search for "java varargs" and "java import a single function from class". This gave me the following code:

/**
 * some utilities
 * @author bernard paulus
 * public domain
 */
public class Utils {
    /**
     * python's 'in' operator -- first attempt
     * @param elem
     * @param list
     * @return true if elem is in list
     */
    public static <T> boolean in_list(T elem, T[] list) {
        // should be named "in" but results in the same erasure when compiled
        // https://www.ibm.com/developerworks/java/library/j-jtp01255/index.html
        // so this method is named "in_list"
        if (elem == null) {
            for (T e : list) {
                if (e == null) {
                    return true;
                }
            }
        } else {
            for (T e : list) {
                if (elem.equals(e)) {
                    return true;
                }
            }
        }
        return false;
    }
    
    /**
     * python's 'in' operator
     *
     * <br/><br/>
     * Tip: <code>import static Utils.in;</code>
     * @param elem
     * @param elems
     * @return true if elem in list, false otherwise
     */
    public static <T> boolean in(T elem, T ... elems){
        return in_list(elem, elems);
    }
}

This code allows

when we import the function like this:

Finally, the code shone clearly in my eyes...


As you see, i'm still far from being a java guru... so if you have any interesting pointer or reflection about this (humm... another interesting subject :D ), feel free to post!

the references:
- java varargs
- java static import

I was shocked by the comportment of python:

One would expect that the value of B is fixed after the declaration of the lambda function (like in functional languages).
It isn't, however.

EDIT: this doesn't work with full-fledged functions. Guess it's logical since the lambda doesn't creates a new scope, except, maybe, for it's arguments.