I've recreated your problem with 2.4.6.1; you should make sure that the object exists outside of the transaction that you're running in.
For instance, creating a user with a normal form and then running the java action on it will work, because the User object exists in the database.
On the other hand, if you create a User object in a microflow and then run the java action on it in the same microflow, the User object won't exist in the database, and the SystemSession won't have any access to it. This results in an error that bubbles up to the browser level, but I think you might be running from a different context (on change, scheduled?) You can view the stacktrace by placing a try/catch around the commit, and printing the exception:
Core.getLogNode("Customer.ActivateUser").info("Try commit the user object");
try {
Core.commit(sudoContext, currentCustomer.getMendixObject());
}
catch (Exception e) {
e.printStackTrace();
}
Core.getLogNode("Customer.ActivateUser").info("After commintting");
There are two solutions to this problem: 1 - create and then change the object using one sudocontext. See below for example 2 - create the user, make sure it's in the database and that the transaction has been committed, then run the java action. You can keep your code as-is.
Example sudocreate/change:
IContext sudoContext = Core.getSystemSession().getContext();
User currentCustomer = User.create(sudoContext);
currentCustomer.setName("henk");
currentCustomer.setPassword("mynewpassword");
currentCustomer.setActive(true);
Core.commit(sudoContext, currentCustomer.getMendixObject());