113 processInput();
114 }
115 } else if (s.equals("economy")) {
116 Boolean seatCreatable = true;117 while (seatCreatable) {
118 for (String passengerName : gns) {
119 EconomySeat
89 String s = in.nextLine().trim().toLowerCase();
90 if (s.equals("first")) {
91
92 Boolean seatCreatable = true; 93 while (seatCreatable) {
94 for (String passengerName : gns) {
95 seatCreatable = FirstSeat
Java's objects inherently add some overhead in terms of CPU and memory usage, and this overhead extends to boxed primitive types as well.
Avoid using the boxed object versions of primitives where they are not necessary.
When working with Java's primitives, treating them as objects can be useful at times (when using them as generic type arguments, for example). Boxed primitive types like Integer
and Byte
exist for this reason. These types combine the semantics of both objects and primitives; Arithmetic and logical operators apply to them as they do to primitives, but these object types also have methods such as equals()
and hashCode()
defined on them. They can also be null
; raw primitive types can never be null.
Most boxed types have very similar names to primitives (just capitalize the first letter), and while they are convenient, they come with a number of object related overheads:
Only create variables with boxed types if you require primitives to be nullable; they have little utility elsewhere.
Integer i = 3; // i could have just been an int instead.
i += 1;
// ...
In the majority of cases, there is no need for boxed primitive types.
int i = 3;
i += 1;
// ...
Boxed types are quite necessary if there is a chance that a primitive value may need to be nullable:
String query = "SELECT someBool from someTable;";
PreparedStatement ps = dbConnection.prepareStatement(query);
ResultSet rs = ps.executeQuery();
while (rs.next()) {
Boolean nullable = rs.getBoolean("someBool");
if (nullable != null) {
// ...
}
}
This issue is not raised for generic collections where boxed types are used as type parameters.