First, fix any compilation errors.

Assiduously avoid use of reflection.

You should indent code (using spaces, not TABs) that you post, to enhance
readability.

...

This only works in Java 5 +. You might have made the intent clearer by
declaring the variable as Integer.

Why the throwaway initialization anyway?

Java programming convention is that variable and method names begin with a
lower-case letter, and that each subsequent "word" component begin with an
upper-case letter: "functionsTest'.

...

So "Mult1" is a parameter of Integer.TYPE.

You've already declared "Functionstest[0][0]" to be an Integer.TYPE parameter,
despite that its value does not parse to an integer. It should not also be a
method name.

Kaboom!

You should not ignore Exceptions. The error messages probably would have led
you to a solution by now.

"myRes".

If this is an exercise to learn reflection, it's useful. Otherwise there are
better ways to accomplish the task.

- Lew

I don't know what's wrong here, but I do have some advice: don't use
reflection, unless you really, really, really need to low-level-hack
code that isn't known until runtime, which tends to be only if you're
writing code-grokking tools like debuggers or profilers or coverage
tools or automated testing systems that use reflection and annotations
to save people the bother of writing separate unit test classes or whatever.

Most often, when you want to call a method that is determined
dynamically at run-time, or reflectively inspect and change the
properties of an object, what you want is a) polymorphism and b) a class
with built-in support for programmatic property discovery and
manipulation. And then you want to use interfaces.

In the case of invoking the method of some user's choice at runtime, you
use code like this:

public void myMethod (FooDoer f, other args) {
    ...
    f.doFoo(args)
    ...
}

and write an interface like this:

/**
 * Explain what this interface is for
 */
public interface FooDoer {
    /**
    * Explain what this should do and who calls it when and why
    */
    public void doFoo (args);
}

Now the callers of your code can supply their own FooDoer implementation
and their own version of the doFoo method gets called by your code in
myMethod.

For the property-inspectable thing you expand on this theme:

public interface PropertyInspectable extends Serializable, Cloneable {
    public Set<String> getPropertyNames();
    public Object getProperty (String name)
        throws PropertyException;
    public void setProperty (String name, Object value)
        throws PropertyException;
}

public class PropertyException extends Exception ...

and create things like PropertyParseException, NoSuchPropertyException,
and so forth for the latter two to throw as needed. Users of your code
can do things like getPropertyNames() on your PropertyInspectables to
discover property names, and getProperty(name) to get particular
properties. Ones with their own nested properties can be found with

Object o = foo.getProperty(name);
if (o instanceof PropertyInspectable) doSomething((PropertyInspectable)o);

and the rest might be assumed to be a mix of Strings and one of a few
boxed-primitive types like Integer and Double, maybe also BigInteger and
BigDecimal. And, of course, you can expand on that notion and throw in a
whole meta-level scripting interface in a "public interface Scriptable"
or whatever, or extract o.getClass() and do something with that ...

Or, of course,

public interface DirectlyUserEditable {
    public JFrame getViewerInstance();
    public JFrame getEditorInstance();
}

public class MyFoobar implements DirectlyUserEditable {
    private int ivar1;

    public JFrame getViewerInstance () {
        return new Editor(true);
    }
    public JFrame getEditorInstance () {
        return new Editor(false);
    }
    public class Editor extends JFrame ...
    ...
    ... public Editor (boolean readOnly) { ...
    ...
    ...     ivar1 = Integer.valueOf(area.getText()) ...
    ...
}