This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 128695 - API review of SourceForBinaryQuery extension
Summary: API review of SourceForBinaryQuery extension
Alias: None
Product: java
Classification: Unclassified
Component: Classpath (show other bugs)
Version: 6.x
Hardware: All All
: P2 blocker (vote)
Assignee: Tomas Zezula
Depends on:
Blocks: 128353 198951
  Show dependency tree
Reported: 2008-02-28 13:35 UTC by Tomas Zezula
Modified: 2011-05-27 12:58 UTC (History)
5 users (show)

See Also:
Issue Type: TASK
Exception Reporter:

Javadoc (281.65 KB, application/x-compressed)
2008-02-28 13:43 UTC, Tomas Zezula
Patch (54.19 KB, patch)
2008-02-28 13:44 UTC, Tomas Zezula
Details | Diff
Diff (54.99 KB, patch)
2008-03-07 17:08 UTC, Tomas Zezula
Details | Diff
Javadoc (280.97 KB, application/octet-stream)
2008-03-07 17:10 UTC, Tomas Zezula

Note You need to log in before you can comment on or make changes to this bug.
Description Tomas Zezula 2008-02-28 13:35:41 UTC
The current SourceForBinaryQuery doesn't allow the provider to pass information to the java infrastructure whether the sources should be preferred over the 
binaries. The java infrastructure has to use some heuristics to find this out. The heuristics doesn't work in some cases - extra sources attached to project 
classpath elements. Also in some freeform project setup the binaries should be preferred to sources. This change proposes extension of the SFBQ which 
allows the provider to pass such an information to the java infrastructure.
Change is both source and binary compatible.
Proposed API will be stable API in NB 6.1
Comment 1 Tomas Zezula 2008-02-28 13:43:59 UTC
Created attachment 57448 [details]
Comment 2 Tomas Zezula 2008-02-28 13:44:44 UTC
Created attachment 57449 [details]
Comment 3 Jesse Glick 2008-02-28 15:25:06 UTC
[JG01] <author login="jglick"/>? <issue number="128353"/>? <date day="28" month="2" year="2008"/> when it cannot anyway
be committed for a wekk? Please check over apichanges.xml.

(BTW you may be interested in:

[JG02] Why the calls to l.getClass() in add/removeCL?

[JG03] Use ChangeSupport.

[JG04] 'public' and 'static' modifiers inside an interface are redundant and can be deleted.

[JG05] SFBQI2.findSourceRoots2 Javadoc should be made very brief and link to SFBQI.fSR for all details to ease maintenance.
Comment 4 Tomas Zezula 2008-02-28 16:11:46 UTC
JG01: Fixed
JG02: Prevents null as a parameter, immediately throws NPE, nicer than
if (a == null)
throw new NPE();
JG03: ChangeSupport can be used it does the same. It has an unit test, so I will use it, it's new for me. Thanks or pointing me on it.
JG04:  I know that these modifiers are implicit inside interface, but I prefer to list them anyway - better readability from my point of view.
JG05: Putting @see instead of javadoc should work fine, but the code completion will show just a link. I don't have strong opinion on this.

Comment 5 Jesse Glick 2008-02-28 16:17:53 UTC
[JG02] - use o.o.u.Parameters

[JG05] - sure, but you can follow this link in CC by clicking on it. I am just saying that I see a lot of things I would
want to edit in the current Javadoc, and I would not want to have to edit it in two places.
Comment 6 Milos Kleint 2008-02-29 14:50:25 UTC
the api change looks ok to me.

mk1: the getSources() in the Result2 in api package seems to have no javadoc
mk2: the implementation part has the javadoc but it's not immediately clear what preferring binary or source actually means.
mk3: I haven't checked the actual code but I assume if some result is the old non-Result2 one, the old heuristics is
still performed? My specific usecase is maven support which provides only sources in jars for binary roots without a
project. Will that keep on working or I need to implement the Result2 immediately..
Comment 7 Tomas Zezula 2008-02-29 15:11:21 UTC
mk1: Already fixed.
mk2: It contains brief info how to implement it, the complete description of preferSources is in SFBQI2 Javadoc which is a top level of this method, but I can 
add a see. Copying the same javadoc into it is probably not a good solution.
mk3: Yes,no. (The heuristic is performed in the Result2 API class for original SPI Result, no heuristic for SPI Result2). You will not need to implement anything, 
as stated in apichanges.xml - binary,source,semantically compatible.
Comment 8 Tomas Zezula 2008-03-07 17:08:19 UTC
Created attachment 57985 [details]
Comment 9 Tomas Zezula 2008-03-07 17:10:52 UTC
Created attachment 57986 [details]
Comment 10 Tomas Zezula 2008-03-07 17:21:05 UTC
I've attached the final diff and javadoc.
I am going to integrate the patch on Monday (3/10/08).

Comment 11 Tomas Zezula 2008-03-11 11:20:38 UTC
Fixed in: bde895cd674e