Brightness adjustment control for multiple UI elements
Why did you assume that only Map will ever want to observe the brightness value? As your code hints, you will possibly have not only multiple maps at one point, but also multiple points from which the brightness could be controlled. Which in return would also want to register with that service to update their displayed state in case of external control.



What you did forget to implement in that specific service, is an oldBrigthness != newBrightness test. If the control is set to the same value again, you don't want to propagate. Even less so if the scenario mentioned above occurs, and the self-adjustment of a brightness control could possibly broadcast another update.



I probably wouldn't use the old Observable and Observer classes, their interface predates the introduction of generics in 1.5, and as you noticed isn't even type safe yet.



You should revise on the API design on your service. You now have the odd situation where the BrightnessService needs to be aware of Map, while on the other side the controlling sites need to be aware of BrightnessService.

This is a rather unfortunate situation, since you now created a dependency chain from BrightnessSlider via BrightnessService to Map. This means a BrightnessSlider can't exist, without Map existing in the same application.

The solution to break this chain, is to make Map instead aware of BrightnessService, respectively define a generic interface in the package of BrightnessService which allows other components to register with this service. Now both the BrightnessSlider and the Map can exist and access the BrightnessService without the other component being part of the same application. As a side effect, this also solves the case where BrightnessSlider wants to observes the currently set brightness as well.



private static final List&lt;Map&gt; OBSERVERS;


Caps lock is for constants, not for mere static class variables. At least not if they can be considered "variable", and not constant.

Well, actually something as a static class variable  shouldn't exist in your application to begin with. You should try to keep your classes always instantiable and free from side effects. This also applies to this service.

If you actually need to ensure that only a single instance of this service can exist, use the Singleton pattern. This is about the only exception to the rule where static final may be used to declare something else than a constant.

There are quite a few reasons for that, among others that the BrightnessSlider and Map classes usually would also want to hold a reference onto the BrightnessService they have been registered with (and be it only to provide a clean shutdown by unsuscribing themselves!).

It also allows you to move freely between Singleton and other techniques, such as dependency injection, should your code base require that later on. As the call sites already work on a specific instance of BrightnessService (with disregard as where they obtained it from!), there is little friction in changing that later on.

Furthermore, static methods should also be free of side effects, by convention.
Performing constant calculations, or returning a constant result/reference? Good.
Mutating some global state directly? Not good.