Jesse Silverman wrote:Hi Tim:
I am thinking the OP may have used the word "warning" somewhat carelessly.
I definitely have seen this as an actual warning in other languages I need to work in, including when it was like "warning -- this very bad thing you should never do just happened". The code compiled (depending on settings) and you were playing the slot machines to find out what would happen at runtime (also often dependent upon compile settings).
But as far as I recall, this message is always associated with a compile failure in Java since way back.
There are warning class messages, usually about type-unsafe operations or deprecated usages, I don't think this was ever one of those.
Tim Cooke wrote:Giving an example of when you saw this warning might give a bit of context for your question. Otherwise the best I can offer is "it depends".
Campbell Ritchie wrote:Note the above classes are all mutable. It should be possible to envisage a scenario where the classes are immutable.
Sometimes you add new interface elements to a derived type, thus extending the interface. The new type can still substitute for the base type, but the substitution isn’t perfect because your new methods are not accessible from the base type. This can be described as an is-like-a relationship (my term). The new type has the interface of the old type but it also contains other methods, so you can’t really say it’s exactly the same. For example, consider an air conditioner. Suppose your house is wired with all the controls for cooling; that is, it has an interface that to control cooling. Imagine that the air conditioner breaks down and you replace it with a heat pump, which can both heat and cool. The heat pump is-like-an air conditioner, but it can do more.
Because the control system of your house is designed only to control cooling, it is restricted to communication with the cooling part of the new object. The interface of the new object is extended, and the existing system only knows about the original interface. Once you see this design it becomes clear that the base class “cooling system” is not general enough, and should be renamed to “temperature control system” so it can also include heating—at which point the substitution principle will work. However, this diagram shows what can happen with design in the real world.
When you see the substitution principle it’s easy to feel like this approach (pure substitution) is the only way to do things, and in fact it is nice if your design works out that way. But you’ll find there are times when it’s equally clear you must add new methods to the interface of a derived class (extension). With inspection both cases should be reasonably obvious
Campbell Ritchie wrote:A Stream‑based solution might be eminently suitable for beginners, but we shall have to make them do it the hard way with a loop () because these exercises are for teaching people how to use loops.
Campbell Ritchie wrote:You can't iterate a Map. only one of the three sets you can get out of it. You can get access to those three sets via three of the Map's methods. You can use the map() mathod to take the price and count and produce a number. If you have the price as a primitive you may be able to get a Stream of primitives with a method called mapToXYZ() and use its sum() method, otherwise you would have to write a Collector with its three parts yourself, or use the reduce() method which you will find examples of in the package documentation.
Show us what you have tried and tell us how it is going. This is one of the circumstances where it is much easier to use an IDE than the command line.