Java 8 will have built-in support for passing methods as arguments.

Aha!  Brilliant thanks!

http://en.wikipedia.org/wiki/Command_pattern#Java

Command is a better name the functionPointer

Well Lambda Expressions are nothing new, although incorporating them into Java will be interesting.

Your "functionpointer" interface already exists in the forms of Runnable and Callable, both of which will benefit from some syntax sugar in 1.8.  But if you have a fixed set of commands, you're better off using an Enum.  There's nothing stopping you from making your enum implement an interface itself if you think you might need custom implementations, which is how I did BlendMode in JCOD

I've never seen the error you are talking about. Are you using enums as a singleton with a state? You want the enum to represent the method to perform on the data and not to store data itself. Pass the data as a parameter. It should work, otherwise you would not be able to use enum's equals method. Enum has very strange syntax, it's possible you made a mistake. Post the code if you want.

Edit:

Did you make the enum an inner class of something else? You won't be able to use it with other classes if you make it non-static and if you make it static it will give you the same error that a static inner class accessing an outer class. (There is no OuterClass.this reference for static classes while there is for non-static inner classes. Static inner classes require a reference since it is not implicit.)

I don't recommend using innner classes for this purpose.

You could, but it creates more than one object (which is more than zero), there is no parameter type checking on invoke, it's slower, and method.invoke() is less clear than interface.method().

Hmm... Computer programs consist of two basic units; data and code. Data is accessed statically via named variables and named functions and dynamically through pointers and function pointers. In object oriented programming, the things called objects are bundles of data with operations associated with them. Objects combine data and code into one variable or pointer.

If you have N objects and 1 effect but the effect require extra state data which is not stored in the original objects, you still need N places to store the extra state data even though there is only 1 effect. Function pointers are stateless.
There are three ways to fix it.
1) Take the state data out of the effect and put it into the object it affects. (Use one object and one function pointer.)
2) Leave the effect state data in the Effect object. Reference the affected object int the effect object and vica versa. (Use one additional object per effect/entity pair.)
3) Merge the state data for all effects into the super class of the class it affects. (Use one object and bad design practices.)

To simplify the following definitions, assume that static variables are not used. (Mutable global variables are bad practice anyways.)
Data variables store values and do nothing on their own.
Functions represent code. They do nothing without data to work on.
Objects store both of the above.

Objects have an implicit this reference. If you rely on having that reference as your code does, you are using your class as an object not a "function pointer".