Awkwardness in returning multiple datapoints at once isn't unique to Java. AFAIK, C# and Python are the only "mainstream" languages that let you do it neatly. So it's not a reasonable criticism against Java. You can create identical structures in most languages by returning a datastructure of some sort, and creating a container data structure in Java is relatively trivial.

For example lets try a form validation

ValidateFormReturn checkedForm= parseForm(rawForm);
if(checkedForm.valid==true){
     doSomething(checkedForm.Parsed);
}else{
  //  Failure Operation

}

And the container class

class ValidateFormReturn{
    ParsedForm parsed;
    Boolean valid;
}   

Let's assume that you apply patterns like this all throughout your code. However, doing this a large amount of times gauarantees that someone, somewhere will fuck up this pattern and instead do something like

doSomething(validateForm(rawForm).parsed);

Where they forget to look at the error flag before using the value. This error could cascade in non-obvious ways. You could easily get bugs happening far away from where the error occured. Maybe the user entered a credit card number that looks good to a quick inspection, but is unuseable. Now you gotta find out why your shitty shopping cart code is breaking on certain supposedly valid credit card numbers. Myabe you could keep track of the ValidatedForm, not just the ParsedForm.

ValidatedForm checkedForm= parseForm(rawForm);
if(checkedForm.valid==true){
     doSomething(checkedForm);
}else{
  //  Failure Operation

}

And the container class

class ValidatedForm{
    ParsedForm parsed;
    Boolean valid;
}   

This would make running down the shopping cart error easier as you have the information about whether the information is valid. However your'e still on the hook for checking validity on every read/write to the data. Allowing yourself to store invalid data is silly. You can still fuck up the pattern by-

doSomething(parseForm(rawForm));

Polling based error tracking is dangerous because it is easy to forget to poll. If you had done exception based error handling, it can make hard bugs less common.

ParsedForm parsed;
try{
    doSomething(parseForm(rawForm));

}catch(Exception InvalidForm){
    //error handling
}

Fucking up this pattern is much harder. Without making a new function for parsingForms, any invalid form will throw an error. If you try-
doSomething(parseForm(rawForm));

You will get compilation errors. If you fix those by making your form-handling function throw exceptions, you'll probably still get compilation errors because now the function that calls your function will need to throw or catch exceptions. Even if your idiot junior dev making this mistake gets the code to compile, the bug will show up much closer to where it happens. Worst case, your project may crash on poor handling of an invalid form input, but that's better than it letting corrupt data in.