Community
Participate
Working Groups
Follow-up from bug 537014: The API of class Signature doubly confuses unions and intersection types: The signature of an IntersectionCastTypeReference is computed using Signature.createUnionTypeSignature() and the signature of a UnionTypeReference is computed using Signature.createIntersectionTypeSignature(). Secondly, Signature uses C_INTERSECTION = '|' and C_UNION = '&' directly opposite how these symbols are used in source code. Checking what these signatures are being used for I see both methods called only via org.eclipse.jdt.internal.core.util.Util.typeSignature(TypeReference), with these call contexts: - Some use it to create a org.eclipse.jdt.internal.core.LocalVariable - Others use it for comparison with methodHandle.getParameterTypes() - Or for retrieving an IMethod using selector and signature In all these cases all is local to the Java Model, so probably no harm is done. In particular I don't see any direct relation to source nor bytecode (where we'd have to closely follow specifications). The bug leaks into clients via the constants Signature.INTERSECTION_TYPE_SIGNATURE and Signature.UNION_TYPE_SIGNATURE. Those are indeed used in jdt.core.manipulation and jdt.ui. Interestingly, org.eclipse.jdt.internal.core.manipulation.JavaElementLabelComposerCore.appendTypeSignatureLabel(IJavaElement, String, long) reverses the logic: when we find an "intersection" we pass "isIntersection=false" to downstream, and vice versa. BTW, the history of that class is broken by the move from Bug 534284. Another client, org.eclipse.jdt.internal.ui.javaeditor.JavaElementHyperlinkDeclaredTypeDetector.addHyperlinks(List<IHyperlink>, IRegion, SelectionDispatchAction, IJavaElement, boolean, JavaEditor) only asks about intersections, but then doesn't perform any intersection-specific operation. Seems it could handle intersections and unions in the same way. Ideally we should clean up this mess by simply swapping the names of both confused methods, but since they are API this is not an option. Should we simply add to the javadoc a hint that both methods do the opposite of what their names suggest? Same for the constants indicating signature kinds?
(In reply to Stephan Herrmann from comment #0) > The bug leaks into clients via the constants > Signature.INTERSECTION_TYPE_SIGNATURE and Signature.UNION_TYPE_SIGNATURE. > Those are indeed used in jdt.core.manipulation and jdt.ui. > Interestingly, > org.eclipse.jdt.internal.core.manipulation.JavaElementLabelComposerCore. > appendTypeSignatureLabel(IJavaElement, String, long) reverses the logic: > when we find an "intersection" we pass "isIntersection=false" to downstream, > and vice versa. BTW, the history of that class is broken by the move from > Bug 534284. Digging beyond the refactoring I see that "wrong correction" coming from https://git.eclipse.org/r/#/c/120251/ - "wrong" by the letter, "correct" by the outcome. Cc'ing JDT/UI for comments.
Direct link to prior discussion regarding use of '&' & '|' in Signature: https://git.eclipse.org/r/#/c/119966/ Unfortunately, back then we didn't realize the other name-swap and how it leaks to clients.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
