Java – Best approach to selecting programming languages and 3D graphics API for simulating physics experiments

General Comments

I am a great believer in comments are for why (not how). When you start adding comments about how you fall into the problem that nothing is enforcing that comments be maintained in relation to the code (the why will usually not change (the why explanation may be enhanced some over time)).

In the same way date/authorInfo does not gain you anything in terms of why the code was done this way; just like the how it can degenerate over time because there is no enforcement by any tools. Also the same information is already stored in the source control system (so you are duplicating effort (but in a less reliable way)).

Going through the arguments:

I say for maintenance reasons, it's important to know when and who did a change (even this information is in the SCM).

Why. Neither of these things strike me as important to maintaining the code. If you need to talk to the author it is relatively simple to find this information from source control.

The code has life for that reason had an history.

History is stored in source control.
Also do you trust that the comment was written by that person. How comments tend to degrade over time so this kind of history becomes unreliable. Source control systems on the other hand will maintain a very accurate history and you can accurately see when comments were added/removed.

Because without the change date it's impossible to know when a change was introduced without open the SCM tool and search in the long object history.

If you trust the data in a comment.
One of the problems with this kind of things is that the comments become incorrect in relation to the code. Back to the correct tool for the job. The source control system will do this correctly without need for intervention from the user. If your source control system is a pain then maybe you need to either learn how to use it more appropriately (as that functionality is usually easy) or if does not support it find a better source control system.

because the author is very important, a change of authorx is more credible than a change of authory

All authors (apart from yourself) are equally credible.

Agility reasons, no need to open an navigate the SCM tool

If your source control tool are that burdensome you are wither using it incorrectly or (it is more likely) you are using the wrong set of tools to access the source control system.

people would be afraid of change something that someone did 15 years ago, than someting that was receantly made ...

If code has lasted 15 years then it is more likely to be more solid then code that has only lasted 6 months without needing review. Stable code tends to stay stable, buggy code tends to get more complex over time (as the reason it is buggy is the problem is not as simple as first thought).

Even more reason to use source control to get information.

The history is in the SCM

Yes. Best reason yet.

Developers must not be aware of history of the code directly in the code

If I really need this information I will look it up in source control.
Otherwise it is not relevant.

Packages gets 15k lines long and unstructured comments this packages harder to understand

Comments should be a description of why you are doing something anyway.
Comments should NOT be describing how the code works (unless the algorithm is not obvious).

I would approach this problem as I would approach any localization issue: ResourceBundle. I use a class called I18n that has a static method called getMessage that takes a key and optionally a list of arguments. The key gets looked up in a ResourceBundle configured to use the default Locale or whatever you prefer (specifics here aren't important, so long as the caller to I18n doesn't have to know about what the Locale is).

The I18n class is as follows:

public final class I18n {
    private I18n() {
    }

    private static ResourceBundle bundle;

    public static String getMessage(String key) {
        if(bundle == null) {
            bundle = ResourceBundle.getBundle("path.to.i18n.messages");
        }
        return bundle.getString(key);
    }

    public static String getMessage(String key, Object ... arguments) {
        return MessageFormat.format(getMessage(key), arguments);
    }
}

In your project, you would have in package path.to.i18n, files containing messages.properties (default), messages_en.properties (Locale en), messages_it.properties (Locale it), etc.

When you need to translate an enum value, you shouldn't have to treat it any differently than any other key, except the key is the enum term.

In other words, you have:

public enum AccountStatusEnum {
  Active,
  Inactive,
  Pending
}

When you call I18n.getMessage, you pass with AccountStatusEnum.Active.toString() and the translation will be found in a property file with key "Active". If you're like me, and you prefer to use lower-case keys, then you should perform toLowerCase() on the string. Better still, you create a new I18n.getMessage that takes an Enum rather than a key, and that method calls the String version of I18n.getMessage with the enum value converted to string and in lowercase.

So you'd then add this to the I18n class:

    public static String getMessage(Enum<?> enumVal) {
        return getMessage(enumVal.toString().toLowerCase());
    }

I prefer to use this method because it incorporates the same translation logic in the same part of the program without impacting your design. You may even want to differentiate enum keys from your other keys, in which case you can begin each enum key with "enum.", so you would prepend "enum." when calling getMessage. Just remember to name your keys in your properties files accordingly.

I hope that helps!