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

Bug 188823

Summary: Improve Util#getLineNumber
Product: [Eclipse Project] JDT Reporter: Maxime Daniel <maxime_daniel>
Component: CoreAssignee: JDT-Core-Inbox <jdt-core-inbox>
Status: CLOSED WONTFIX QA Contact:
Severity: normal    
Priority: P3 CC: Olivier_Thomann, stephan.herrmann
Version: 3.3   
Target Milestone: ---   
Hardware: PC   
OS: All   
Whiteboard: stalebug

Description Maxime Daniel CLA 2007-05-24 02:30:47 EDT
Source based, v_764.

While reviewing bug 182359, I got confused by Util#getLineNumber.

The assignment on line 258 is clearly extraneous when g == d, hence the loop should be tuned.

The method would deserve a specification, so that the reader can figure out what it does more easily. 
One point that troubled me for a while is that g and d are relative to lineEnds, hence they are *not* line numbers. While this fits the scanner (which maintains a line index that has the same origin as lineEnds), other calls in JDT Core apply a -1 to d. Since the calls that use a 0-based value outnumber the others, changing the base would be a bad idea. Yet, this would deserve an explicit comment to help the user grasp that the parameters are not homogeneous with the result in this respect (in other words, g and d are not line numbers, but indexes from lineEnds that will scope the search so as to optimize it).
A statement of the expectations on the parameters would help too.

Last, I would also suggest that white-box tests be added that explicitly challenge Util#getLineNumber. I know that the norm is to rely on user-level tests, but this piece of code is isolated and non-trivial, and would deserve dedicated tests.
Comment 1 Olivier Thomann CLA 2007-05-24 17:01:48 EDT
We might want to investigate using java.util.Arrays.binarySearch(int[], int).
Comment 2 Eclipse Genie CLA 2019-01-30 03:55:47 EST
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.