Surprisingly, both. It’s also dynamically typed. Let’s try to explain:

When you create a MeshObject, it initially does not have a type. That means it can’t have properties and cannot participate in most relationships. Only once you bless it with a type (or several types) does it carry properties.

Over the life of a MeshObject, it can be blessed and unblessed many times. This means that almost by definition, application code using the MeshObject cannot, a-priori, know what type(s) it has. It also means that most application code working with the MeshObject simply treats it as a MeshObject, and nothing more specific. That is clearly weak typing in action.

However, if you know what type a MeshObject has (e.g. because you asked it), you can move over into strongly typed mode.

For an example, let’s assume there is an EntityType com.example.model.CustomerModel.Customer.Then you can do this:

import com.example.model.CustomerModel.CustomerModelSubjectArea;
import com.example.model.CustomerModel.Customer;
...
MeshObject weakly = ...;
if( weakly.isBlessedBy( CustomerModelSubjectArea.CUSTOMER )) {
    Customer strongly = (Customer) weakly.getTypedMeshObjectFacade( CustomerModelSubjectArea.CUSTOMER );
    strongly.setFirstName( ... );
    strongly.setOutstandingBalance( ... );
    ...

The instance called strongly is now a strongly typed MeshObject. It is valid for as along as the MeshObject exists and is blessed with the Customer type. (Internally, the strongly typed instance is a different Java instance than the MeshObject instance; this is necessary due to the limitations of Java. But semantically they are the same, e.g. their property values are always the same.)

InfoGrid V1.x was only strongly (and statically) typed, like Java itself. Dynamic typing and this ability to choose between strong and weakly typed access, depending on what makes more sense for any particular piece of application code, is clearly a great improvement.