Eclipse Community Forums: Java Development Tools (JDT) » Pattern for annotation based null analysis and GUI programming

Home » Language IDEs » Java Development Tools (JDT) » Pattern for annotation based null analysis and GUI programming

Show: Today's Messages :: Show Polls :: Message Navigator

Pattern for annotation based null analysis and GUI programming [message #1749750]

Sat, 10 December 2016 23:15

Frank Benoit

Messages: 179
Registered: July 2009

Senior Member

Hi

in GUI, the initialization is often done over a sequence of called overridden methods.

E.g. if you implement a org.eclipse.jface.dialogs.TitleAreaDialog
Then the buttons and all the widgets created not in the ctor of the class, instead it needed to do it in createDialogArea() and friends.

This means, all those widgets, that need to be accessed later, must be fields with @Nullable.

What i try to achieve, is to have the object's fields as @NonNull, intialized in the ctor.

I create an inner class "Gui" that is instantiated in the createDialogArea, passes the args to Gui, and Gui has all those widgets as fields. Now initialized in its ctor.
All other overrides in my dialog class, need once to check the Gui instance to be non-null and then delegate to it.

This will not work, if there are 2 or more overrides that are used to create widgets. Not sure if i will encounter this. But before i start to work on my code base....

Are there better patterns?

Report message to a moderator

Re: Pattern for annotation based null analysis and GUI programming [message #1749761 is a reply to message #1749750]

Sun, 11 December 2016 16:06

Frank Benoit

Messages: 179
Registered: July 2009

Senior Member

Here i try to summarize my learning, I had in the last weeks with the null analysis.

https://fbenoit.blogspot.de/

Report message to a moderator

Re: Pattern for annotation based null analysis and GUI programming [message #1749763 is a reply to message #1749761]

Sun, 11 December 2016 21:29

Stephan Herrmann

Messages: 1853
Registered: July 2009

Senior Member

In one application I used a similar approach, viz. using an inner class for fields whose initialization is deferred. In my case I actually made the inner a subclass of the outer. In a way these are approximations of what theory calls "type state" (e.g. [1]).
Ideally, one may polymorphically replace the initial references to an uninitialized instance by reference to the fully initialized inner. But actively delegating from outer to inner sounds fair, if this isn't needed in too many locations.

Thanks for blogging about your experience.
Stephan

[1] http://www.cs.cmu.edu/~aldrich/papers/onward2009-state.pdf

Report message to a moderator

Re: Pattern for annotation based null analysis and GUI programming [message #1749764 is a reply to message #1749763]

Sun, 11 December 2016 21:50

Stephan Herrmann

Messages: 1853
Registered: July 2009

Senior Member

I tried to comment on your blog, not sure it was accepted, so repeating here:
- if SonarLint wants you to mix type annotations with declaration annotations that would be a bug in SonarLint. Type annotations should be placed next to the type they are annotating.

Also:
- as you are starting your own utilities: have you checked org.eclipse.jdt.annotation.Checks?

Stephan

Report message to a moderator

Re: Pattern for annotation based null analysis and GUI programming [message #1749765 is a reply to message #1749763]

Sun, 11 December 2016 22:24

Frank Benoit

Messages: 179
Registered: July 2009

Senior Member

Hello Stephan,

thanks for this link.
An inner (non static?) class derived from the outer. I would have never thought about this.
I was not even sure if this is legal, i had to try it to be convinced.
Does that mean you have all fields doubled, once for the outer and inner instance?
Probably best done with a static inner class.

In that link, they are making use of an own language to support this state types feature.

Using this in Java with a GUI library, i have doubts.

1. you need to copy all exising fields from the previous state class (the not-fully-initialized one).
If I understand correctly, i cannot do this e.g. with TitleAreaDialog, i cannot expect to find a copy constructor or such. This would mean, to cancel the TitleAreaDialog build up procedure in the middle (when i am called in createDialogArea()) and to continue in my newly created state instance. Challenging, hehe

2. The user of the class must know, to exchange his references with an newly returned one?
So the user needs now somehow to handle state transition actively. If the reference to that class is hold in multiple places this gets ugly.

Or do I miss the point and it can be done in Java in a good way?

About the annotation order, the SonarLint rule is this:
https://dev.eclipse.org/sonar/rules/show/squid:ModifiersOrderCheck
Are the places technically equivalent?
private @Nullable Listener getListener();
@Nullable private Listener getListener();

Report message to a moderator

Re: Pattern for annotation based null analysis and GUI programming [message #1749779 is a reply to message #1749764]

Mon, 12 December 2016 07:26

Ed Willink

Messages: 7670
Registered: July 2009

Senior Member

Stephan Herrmann wrote on Sun, 11 December 2016 16:50

org.eclipse.jdt.annotation.Checks?

Thanks for the reminder. I just took a quick look and was surprised that neither of my favourites are there.

public static @NonNull <T> T nonNullState(@Nullable T aT) {
if (aT == null) {
throw new IllegalStateException();
}
return aT;
}

@SuppressWarnings("null")
public static <T> @NonNull List<@NonNull T> nullFree(@Nullable List<T> nullFreeList) {
return nullFreeList != null ? nullFreeList : Collections.emptyList();
}

Since I am upgrading pre-@NonNull code, I am not prepared to make an unjustified @NonNullByDefault assertion. So everything is explicit. nonNullState is necessary for those many occasions where legacy typically platform/EMF code provides unannotated 99% confidence non-null values.

nullFree is useful for EMFs 100% confidence collections without null content. Unfortunately, I cannot solve the overload problem for Iterable/EList/Collection return type preservation.

---

It would seem that Checks could provide facilities that are subject to a debug option. With debug, checks are performed. Without debug, the functions are optimized away avoiding all the run-time overheads on safe code.

Regards

Ed Willink

Report message to a moderator

Re: Pattern for annotation based null analysis and GUI programming [message #1750081 is a reply to message #1749779]

Thu, 15 December 2016 21:31

Stephan Herrmann

Messages: 1853
Registered: July 2009

Senior Member

Ed Willink wrote on Mon, 12 December 2016 08:26

Stephan Herrmann wrote on Sun, 11 December 2016 16:50

org.eclipse.jdt.annotation.Checks?

Thanks for the reminder. I just took a quick look and was surprised that neither of my favourites are there.

public static @NonNull <T> T nonNullState(@Nullable T aT) {
if (aT == null) {
throw new IllegalStateException();
}
return aT;
}

What's wrong with:

	public static <T> @NonNull T requireNonNull(@Nullable T value) {
		if (value == null)
			throw new NullPointerException();
		return value;
	}

Stephan

Report message to a moderator

Re: Pattern for annotation based null analysis and GUI programming [message #1750129 is a reply to message #1750081]

Fri, 16 December 2016 09:59

Ed Willink

Messages: 7670
Registered: July 2009

Senior Member

Hi Stephan

Nothing. Apart from my failure to recognize the name prefix.

Regards

Ed Willink

Report message to a moderator

Previous Topic:	Help about JST
Next Topic:	Java search (was Re: jEdit/Eclipse Interface Tools)

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Tue Sep 24 22:49:49 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter