Class declarations and object modeling: Correct Solution

Translate the specification below into an idiomatic Java class definition.

(In this context, "idiomatic" means following the common style and conventions of the language.)

One kind of thing that exists in our model is a Velrem.
All Velrems share a single HOUSUN, which is an int. It is a constant. Its value is 13. Other classes can see its value.
Each Velrem has its own egoa, which is an int. The value of egoa is specified when a Velrem is created. Anyone can ask a Velrem for the value of its egoa. Anyone can set egoa to a new value.
All Velrems share a single dedi, which is a list of strings. No other classes can directly ask for the value of dedi. The value of dedi starts out as an empty mutable list when the program starts. Every time a new Velrem is created, it adds "urpe" to dedi.
Each Velrem has its own xiepu, which is a graphics object. The value of xiepu is specified when a Velrem is created. Anyone can ask a Velrem for the value of its xiepu. The value of xiepu for a specific Velrem can never change.
Each Velrem has a alScras, which is a list of strings. An alScras is part of the internal state of a Velrem: no other classes can see the value of alScras or directly change it. When a Velrem is first created, the value of its alScras starts out as an empty mutable list.
Each Velrem has a niamp, which is a string. A niamp is part of the internal state of a Velrem: no other classes can see the value of niamp or directly change it. When a Velrem is first created, the value of its niamp starts out as "el".
All Velrems share a single TRORBE, which is an int. It is a constant. Its value is 8. Other classes can see its value.
Each Velrem has a peEm, which is an int. The value of peEm is not part of a Velrem’s internal state; instead, it is computed on demand. The computed value of peEm is the width of xiepu.
A Velrem can alulify. This behavior adds "po" to dedi. Anyone can ask a Velrem to alulify.
A Velrem can aantize. This behavior adds "epe" to alScras. Anyone can ask a Velrem to aantize.
Each Velrem has a diIa, which is an int. The value of diIa is not part of a Velrem’s internal state; instead, it is computed on demand. The computed value of diIa is the x position of xiepu.
Each Velrem has a cece, which is an int. The value of cece is not part of a Velrem’s internal state; instead, it is computed on demand. The computed value of cece is the x position of xiepu.
A Velrem can whosify. This behavior adds "diae" to niamp. Anyone can ask a Velrem to whosify.

Solution

public class Velrem {
    public static List<String> dedi;
    private final int HOUSUN = 13;
    private final int egoa;
    private GraphicsObject xiepu;
    public List<String> alScras = new ArrayList<>();
    public String niamp = "el";
    private final int TRORBE = 8;
    private int peEm;
    private int diIa;
    private int cece;

    public Velrem(int egoa, GraphicsObject xiepu) {
        this.egoa = egoa;
        dedi.add("urpe");
        this.xiepu = xiepu;
    }

    public int getEgoa() {
        return egoa;
    }

    public static void onStart() {
        dedi = new ArrayList<>();
    }

    public GraphicsObject getXiepu() {
        return xiepu;
    }

    public void setXiepu(GraphicsObject xiepu) {
        this.xiepu = xiepu;
    }

    public int getPeEm() {
        return xiepu.getWidth();
    }

    public void setPeEm(int peEm) {
        this.peEm = peEm;
    }

    private void setAlulify() {
        dedi.add("po");
    }

    private void setAantize() {
        alScras.add("epe");
    }

    public int getDiIa() {
        return xiepu.getX();
    }

    public void setDiIa(int diIa) {
        this.diIa = diIa;
    }

    public int getCece() {
        return xiepu.getX();
    }

    public void setCece(int cece) {
        this.cece = cece;
    }

    private void setWhosify() {
        niamp += "diae";
    }
}

Things to check in your solution:

Is every public and private modifier correct?
Are the correct items static?
Are the correct items final?
Are all the variable types and method return types correct?
Are the class members in the correct order? It should be: (1) static variables, (2) instance variables, (3) constructors, (4) methods.
Do members have the correct capitalization?

Acceptable variations in the solution:

It is OK if you initialized non-static variables in the constructor instead of in the declaration. (Ask your instructor if you aren’t clear what this means.) Note that static variables must be initialized in the declaration.
It is OK if you used a slightly different but equivalent form of an expression, such as += 1 instead of ++.

Related puzzles: