JAVA OOP concept issue
The basic structure isn't bad, but is more structured programming in the C or PASCAL tradition than OOP.
OOP discussion
You currently have three types of expressions that need different evaluation behaviour, but use only one class Expression. You implement this differing behaviour in your main class, using a switch on a type code.
Instead, make Expression an interface (or a super class if you aren't comfortable yet with interfaces) with an evaluate() method, and three classes implementing that interface: NumberExpression, SumExpression, and ProductExpression, each with its own way of doing the evaluate() method, with its own fields, and its own constructor (using only the parameters necessary to that type of expression).
Then, there's no need for a type code any more. The Java OOP system does the switch for you. The evaluation of an expression happens where it should happen, in the expression's own class, and you can eliminate the main evaluate() method. And it's totally easy to create additional expression types like difference, quotient or power. You just add another class.
The main idea of OOP is that an object's behaviour should be implemented in the corresponding class, especially if the behaviour depends on something you'd call a type.
Minor points
The type code you are currently using (if it weren't made obsolete by the OOP refactoring) should not be a list of integer constants, but become an enum.
Avoid public fields, make them private, and if really needed, create getter and setter methods. Fields represent some internal state of an object, and nobody outside should manipulate that state, or even have any assumptions on the inner workings of a class. Communication should only happen by calling public methods. (Fields can be viewed as private sticky notes of some clerk, they're not meant to be seen or modified by anybody else, and even asking this clerk about one of these notes seems like bad habit.)
If you have distinct cases how to create instances of a class, create multiple constructors. Your single Expression constructor is a &quot;one-size-fits-all&quot; one. When creating a constant number, you still have to supply two irrelevant Expressions (given as null in your example), and when creating a sum or a product, you are forced to provide an equally irrelevant value parameter.