370843 – AssertableDiagnostics class leaks protected Pred class

Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 370843 - AssertableDiagnostics class leaks protected Pred class

Summary: AssertableDiagnostics class leaks protected Pred class

Status:	CLOSED FIXED

Alias:	None

Product:	TMF
Classification:	Modeling
Component:	Xtext (show other bugs)
Version:	2.3.0
Hardware:	All All

Importance:	P3 normal (vote)
Target Milestone:	M7
Assignee:	Project Inbox
QA Contact:

URL:
Whiteboard:
Keywords:

Depends on:
Blocks:

Reported:	2012-02-07 10:37 EST by Zoltan Ujhelyi
Modified:	2017-10-31 11:30 EDT (History)
CC List:	3 users (show)

See Also:

Flags:	sebastian.zarnekow: juno+

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.

Description Zoltan Ujhelyi

2012-02-07 10:37:59 EST

The AssertableDiagnostics class defines some public static methods that can be used to create DiagnosticsPredicates (e.g. errorCode()). However, all these public methods return Pred classes that is protected.

In general, this seems erroneous. In my case, it prevented me from using Xtend to feed assertAll() with multiple errorCode() predicates, as Xtend did not allow me to avoid referencing the non-visible Pred classes.

Comment 1 Zoltan Ujhelyi

2012-02-07 10:42:27 EST

I created a branch in Github that fixes this issue by changing the return type of the public static methods to the available DiagnosticPredicate interface.

This change should be compatible with all previous uses; however will not leak the Pred classes.

My commit with the fix is available from https://github.com/ujhelyiz/xtext/commit/9dfe5413156296f47dc3264eb46c6572357cea8d

Comment 2 Sebastian Zarnekow

2012-04-03 18:12:09 EDT

see also bug 374743

Comment 3 Knut Wannheden

2012-04-12 02:08:10 EDT

I think we would have to make the nested class public if we don't want to break binary compatibility as in the proposed commit. Overloading the methods is unfortunately not an alternative as the signatures (apart from the return type) remain identical. Any thoughts on this?

Comment 4 Sven Efftinge

2012-04-12 02:33:13 EDT

agreed and pushed.

Comment 5 Eclipse Webmaster

2017-10-31 11:30:49 EDT

Requested via bug 522520.

-M.