I vote for "Giving the methods different names" option especially if performance matters.
Don't use method1(int[][])method2(int[][])
Use method(int[][]) and method_transposed(int[][]) for example.
Method name should always help the reader to understand what it does.
Why do you need to extend this class? And why do you need to name your own method the same as showDialog?
In reality your method does something entirely different than what showDialog does. A better name for your method would be showDialogAtLocationAndReturnSelectedFile as your method does more or less these things. Naming it showDialog will only confuse your code users.
Also, without knowing anything else, I'd say you're trying to shove too much in a single method. How do you react on a cancel press? How about an error? Do you return null? If so, you're forcing the user of the code to check the return value yet again. This has the potential of being just another "Leaky Abstraction", and Java APIs already have enough of these.
An important part of API design is making sure that the name of a function/class/method matches what it really does. And that is why in JFileChooser the method's name is showDialog. It just shows the dialog. It doesn't open the file for reading, it doesn't perform a check whether the filename is valid, and honestly, why would it? The user of the code just asked the class to show the dialog.
The creator of Ruby calls this the 'Principle of Least Surprise'*, and while I don't really know Ruby, this is a great line to learn from. Your code should be in the service of its user, and a part of this service is embedding the contract of the method/class in its name.
You might think you're not designing an API, but I doubt you work alone: there's probably someone else in the team, and they will appreciate this. Also, I heartily recommend this lecture on API Design: How To Design A Good API and Why it Matters. It was presented to Googlers by a Java designer, so it kinda matters.
Maybe this is more than you asked for, but I feel you seem to be somewhat missing the point of naming methods.
UPDATE: * I seem to be mistaken, the creator of Ruby has actually stated that he designed Ruby with the "Principle of Least Astonishment", not "Principle of Least Surprise". In any case, what I said still holds.
Best Answer
When the compiler enters a "new scope", new variables within that scope are stored for that scope, and when the scope "disappears", those variables disappears. This is, normally, done in the form of some sort of stack/list type, which in turn holds the variable names and their type.
So, if we have:
the stack will have level 0 with
{x, int}, and level 1 with{x, double}, {y, double}, {a, int}.I've written my own pascal compiler in C++ (using LLVM to do the actual code generation), and here's my "name-stack":
https://github.com/Leporacanthicus/lacsap/blob/master/stack.h
It uses the StackWrapper to keep track of the number of levels.
This should not be confused with the fact that a stack is used for nesting calls to functions, and storing the local variabls - that's a stack in the runtime environment, and whilst both conceptually are similar, the stack in the compiler is there to track different scopes, the one in the runtime keeps track of calls to functions, arguments to functions and local variables.