We must initialize a superclass before a subclass, since Java needs to set everything up from the top down before proceeding with a subclass definition. Consider a simple case of trying to access a superclass-only variable: we must initialize it with a call to super() before trying to use it.

The title and songs fields, and the calculateRuntime() method are used without initialization in the Playlist class. For the code to compile, they must be initialized in a superclass.

These methods and fields should have either a protected or public visibility modifier, so that they can be accessed in subclasses. For fields, this is a concern, since it is the base class’s responsibility to manage its class invariant, and this may not be respected if subclasses have direct access to fields. We should encapsulate the fields with getters and setters.

If we made title final, then this would prevent any undesired updates in subclasses (preserving the invariant) even if they had access to the variable. If we made songs final, while subclasses wouldn’t be able to reassign the value of songs, they could still change the contents of the song array, possibly violating an invariant. This boils down to immutability—since title is an immutable String, once it’s declared as final, it cannot be changed at all, since any changes would need to be reassigns which are disallowed (by final). However, songs is an array, which is not immutable; we can change its state without needing to reassign it.

The methods with @Override are guaranteed to be declared in the superclass, while the other methods should not exist in the superclass. Note the difference between “should be” and “guaranteed”: having @Override isn’t a requirement for existing superclass methods that we want to override (the code will still compile without them), but as good programmers, we include them. On the other hand, you cannot include an @Override tag for a non-overridden method (the code will not compile).

The method with “default” behavior is play()—the default being to play the songs in order. This order behavior is being overridden in the Playlist subclass by shuffling. There is no “default” behavior for the edit() method, since editing actions may vary drastically (or not be allowed) for certain SongCollection subclasses. Therefore edit() is the abstract method in the SongCollection class.

@Override is necessary because we are overriding the Object class’s toString() method, since Object is at the top of Java’s type hierarchy (the “super-est of all classes”).

We need this cast to change the static type of the variable referencing obj. This way, we are allowed to use Playlist methods and fields without compilation errors (the compile-time reference rule). When the method runs, however, we use dynamic dispatch to get the appropriate methods and fields.

The == operator compares the values of the expressions on both sides of it. For the case of comparing two Playlist variables, the values are references to a Playlist object. Hence, == would compare if the reference values are the same (i.e., the Playlists are the same object), but it says nothing about the contents of that object (the songs and playlist length).

(1) You could add a throws clause to the method signature. Specifically, you should add throws PremiumFeatureException, which lets Java know that this method may propagate an exception. (2) Another solution is to swap the RuntimeException for the correct PremiumFeatureException (or a superclass of this exception), which will catch the error if it is thrown from the try block. Since RuntimeException is not a superclass of PremiumFeatureException, the current catch block isn’t catching anything (that we’re aware of). Since the correct catch condition will corral the exception, it does not need to be added to the method signature, as it will never propagate from the method.