On the method and member access modifiers of official widgets



I would like to present the following dilemma:

Let’s say one needs to use a Scroll as a main component of a Page. Everything goes well until the programmer needs to know the current scroll position of the Scroll (e.g. the viewport of the Scrollable it contains). The programmer already notices that there is a scrollTo() position, but there is no getScrollPosition() or similar.

The programmer then takes a look at the reference implementation of the Scroll and notices it can obtain the position of the scroll by hooking into Scroll's updateViewport(int x, int y, int width, int height). Problem is… that method is private.

Upon further inspection, it can be noticed that every member of the Scroll that provides its functionality is actually private, making extension by subclassing impossible. Thus, a third party programmer is unable to add any additional functionality by simply extending Scroll, which makes the widget pretty inflexible when more complex behaviors are needed.

The only solution to this problem I can think of is to create a 1:1 copy of the Scroll class, extending StyledComposite instead. Of course, creating a complete duplicate of a widget in order to add new functionality is not the best solution because it violates the DRY principle and future updates to the Scroll class would not reflect into the own implementation.

I would like to both ask for an alternative on how to solve this particular dilemma and suggest a possible improvement of the MicroEJ UI subsystem:

ej.widget.* could use more protected members, rather than private members in order to improve extensibility through inheritance. As they are currently implemented, they might as well be declared as final. This improvement would allow developing widgets which are based upon the vanilla ones, without having to recreate their behavior.

Thank you for your time,
Elian D.


Hi Elian,

You are right, the implementation of the Scroll class needs to be duplicated to get back the current scroll position.

Moreover we are aware of the ‘extensibility through inheritance’ issue, our engineers are working hard at improving the MicroUI, MWT and Widgets. As-is we agree with your statement, ‘extensibility through inheritance’ is a cool feature to have in a library. However the choice is not so black and white, as in ‘extensibility through inheritance’ is always the way to go, allowing the fields to be manipulated by a subclass involves a design of the library that takes into account the use of the field outside its own logic and this can have an impact on performance especially concerning UI libraries where animations are common. So we are in the never-ending debate performance versus design.

I think maybe the way to go here is to provide the missing API getScrollPosition in the widget.

Thank you for your feedback, we’ll discuss it with the team.

Gaëtan for MicroEJ