Here is a proposed fix for this bug:
Use the AS_JAVA variable that can be defined in asenv.conf (or asenv.bat) to indicate whether the version has been checked. The asadmin command already reads this file and branches based on whether the value is there. The code could be modified in the case of it not being there to do a version check based on the java that is in the PATH, and if is a suitable version store AS_JAVA in the file for future use, if not print a good error message.
This solution has the following drawbacks:
1) The asenv.conf might not be writable. In that case, the code can just skip writing the file and asadmin will do the version check everytime, thereby making it slower. This case will probably happen rarely, so this drawback is probably acceptable.
2) When the PATH is updated to point to a new java, asadmin will not pick it up. For example, on Windows each Java update is put into a new directory, such as C:\Program Files\Java\jdk1.7.0_11. When you install a new update, and delete the old version, your PATH now points to the new directory. However, the asenv.* file will still point to the old version. If the old version has been deleted, asadmin will fail. And the user has to now edit a config file that they may not even know is there. If the old version is still there, asadmin will not be using the version that the user intends (since they didn't set the AS_JAVA variable in the first place).
So to fix (2), a solution may be to keep the AS_JAVA value and a "FROM_PATH" flag if it was set from the PATH. Then, if FROM_PATH is set, the script can compare the value of AS_JAVA and the current value of java from the PATH, and if they are different, the check would be redone and the new AS_JAVA would be stored. So this would handle the case if the PATH was changed.