Object[] x = new Object[] {"Skye", "Eyks", 123}
{
@Override
public String toString()
{
return this[0] + " " + this[1] + " (" + this[3] + ")";
}
};
So that x.toString()
would return "Skye Eyks (123)".
NetBeans says it expects a semi-colon and that it's an Illegal start of expression.
Why I want to use an anonymous array class is to display the data in a combo-box and get all the other data in my array once the user submits the form.
No, this is impossible.
Your code paste strongly suggests an alternate solution:
Java is a statically and nominally typed object oriented language. Java is very very bad at dealing with data stored in a heterogenerous, untyped, and unnamed 'grabbag of unknown mystery' - which is what Object[]
is.
This is presumably what you're looking for:
public class Word {
final String word;
final int score;
public String getWord() {
return word;
}
public String getReverse() {
// ...
}
public int getScore() {
return score;
}
@Override public String toString() {
return word + " " + getReverse() + " (" + score + ")";
}
}
Now, it's got structure (the compiler now knows, and your editor can now help you out): a Word
has properties like getWord()
and getReverse()
; getReverse()
is far more informative than [1]
. You now have a place to add documentation if you want (how do you intend to 'document' new Object[]
?), and you have room for flexibility (for example, getReverse()
could be calculated on the fly instead of passed in at construction).
You can now write methods that take a Word
. This:
public void printWord(Word word) {}
is almost self evident. Compare to this:
/**
* This function requires that you pass a 3-sized object array, with:
* The first argument must be a string - this is the word to print.
* The second argument must be that string, reversed. It will be printed in light grey for a mirror effect.
* The third argument must be a boxed integer, this will be printed in the lower right corner as page number
*/
public void printWord(Object[] o) {}
That's a ton of documentation, and this is considerably worse: This documentation is unstructured - whereas with an actual class, the names of methods can carry most of this meaning and lets you document each fragment independently. You can also farm out any checks and other code to the right place, instead of ending up in a scenario where the code to check if the input array is proper needs to be called in many places, and you need to go out of your way to document, for everything, what happens if you pass invalid input (vs. having to do that only once, in Word's constructors).
If you end up with an Object[]
due to external forces, such as, say, the arguments passed along to your main function, then the general aim is to convert that to a proper object once, and as soon as possible, so that your java code remains as uninfected by this heterogenous, untyped and unnamed mysterymeat as possible.
NB: Yes, that means you need to make a ton of classes, for everything you can think of, so you end up with clean code. Lombok's @Value
can help with this, as can java15's records.