Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Language IDEs » Java Development Tools (JDT) » Pattern for annotation based null analysis and GUI programming
Pattern for annotation based null analysis and GUI programming [message #1749750] Sat, 10 December 2016 23:15 Go to next message
Frank Benoit is currently offline Frank BenoitFriend
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?

Re: Pattern for annotation based null analysis and GUI programming [message #1749761 is a reply to message #1749750] Sun, 11 December 2016 16:06 Go to previous messageGo to next message
Frank Benoit is currently offline Frank BenoitFriend
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/

Re: Pattern for annotation based null analysis and GUI programming [message #1749763 is a reply to message #1749761] Sun, 11 December 2016 21:29 Go to previous messageGo to next message
Stephan Herrmann is currently offline Stephan HerrmannFriend
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
Re: Pattern for annotation based null analysis and GUI programming [message #1749764 is a reply to message #1749763] Sun, 11 December 2016 21:50 Go to previous messageGo to next message
Stephan Herrmann is currently offline Stephan HerrmannFriend
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
Re: Pattern for annotation based null analysis and GUI programming [message #1749765 is a reply to message #1749763] Sun, 11 December 2016 22:24 Go to previous messageGo to next message
Frank Benoit is currently offline Frank BenoitFriend
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();
Re: Pattern for annotation based null analysis and GUI programming [message #1749779 is a reply to message #1749764] Mon, 12 December 2016 07:26 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7679
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

Re: Pattern for annotation based null analysis and GUI programming [message #1750081 is a reply to message #1749779] Thu, 15 December 2016 21:31 Go to previous messageGo to next message
Stephan Herrmann is currently offline Stephan HerrmannFriend
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;
	}

?
Smile

Stephan
Re: Pattern for annotation based null analysis and GUI programming [message #1750129 is a reply to message #1750081] Fri, 16 December 2016 09:59 Go to previous message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7679
Registered: July 2009
Senior Member
Hi Stephan

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

Regards

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


Current Time: Tue Nov 12 08:45:48 GMT 2024

Powered by FUDForum. Page generated in 0.04743 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top