This is an umbrella API review of a split of NetBeans Platform APIs, Project APIs, Parsing API and Java APIs to UI and Non UI part.
The individual parts are tracked as a sub issues of this issue.
The changes are available in server_split branch in http://hg.netbeans.org/jet-main (http://hg.netbeans.org/jet-main/rev/0afbfa1021d6).
The description of changes can be found on: http://wiki.netbeans.org/SwingDependenciesRemoval
Created attachment 149289 [details]
Compressed diff file
Complete gzipped server_split diff file.
I've added bug 245014 ("Provide base I/O APIs") into this umbrella review.
While the diff is huge, I don't think it is correct. For example there is line:
which has been introduced by me and I don't see reason why you should modify it on the server_split branch!
API Review TCRs & TCAs:
TCR: editor.document: removal of Finder interface, rename getRow* to getLine* to get in line with JDEv terminology
TCR: Progress API - autoupdate does weird stuff in emulating JComponent. Check possible simplifications.
TCA: Progress API - move factory methods to ProgressHandle
TCR: commit_validation is failing in server_split
TCR: run all core tests
TCR: performance tests
TC? binary test distribution to run against server_split branch - jirka Skrivanek
TCR: run sigtests with bytecode patching - Jarda
* run binary applications on top of NB platform against built distribution, not before merge. Approx 1 month.
Created attachment 149465 [details]
AU CLI cleaned up from swing dep
> TCR: Progress API - autoupdate does weird stuff in emulating JComponent.
> Check possible simplifications.
currently AU listens on a Progress Component (JLabel) to intercept progress message from UC install/update and to propagate them to the CLI.
for a swing-less alternative see attached patch
in case no objection is raised, will push to split_server in a day or two ...
Y01 The AutoUpdate CLI change reveals one surprising thing. ProgressHandle is subclassable! Why? It is an API class. We should not mix API and SPI. If we do so, we can expect that somebody will create class like CLIProgressHandle. That only diffuses proper API usage. Consider making ProgressHandle final again and add InternalHandle.getProgressHandle() to make this functionality available but only for the SPI users.
Re. Y01 - how do you suggest to split off UI part of ProgressHandle so that client can still pass around a ProgressHandle instance, and use the same instance to access JComponent services ? In the current patch version, ProgressHandle is subclassable since there's ProgressUIHandle which adds Swing-related APIs on top of the base.
Implemented TCR editor.document: removal of Finder and AdjustFinder interfaces, rename getRow* to getLine* in LineDocumentUtilities.
(In reply to Tomas Stupka from comment #6)
> in case no objection is raised, will push to split_server in a day or two ...
Based on offline discussion, I slightly adapted your patch and committed as jet-main#fbc3397de290
Fixed all module-auto-deps in jet-main.
Commit-validation test violations are fixed and tests are passing.
>TC? binary test distribution to run against server_split branch - jirka Skrivanek
I doubt it's possible. The NetBeans tests are not prepared for dynamic injection of services. When a new service is needed the test has to be changed.
An example of such a test is
org.openide.explorer.ExplorerPanelTest which sets a Lookup by:
System.setProperty ("org.openide.util.Lookup", "org.openide.explorer.ExplorerPanelTest$Lkp");
and the Lookup content is hardened to:
ic.add (new Clb ("Testing clipboard"));
ic.add (new YesDialogDisplayer());
so such a test needs to be fixed as seen at: http://hg.netbeans.org/jet-main/rev/33ec6766e2e2
So it's probably enough to fix the server_split stable tests distribution.
TCR on FileSystem.Status hacked in as http://hg.netbeans.org/jet-main/rev/57447e2c930a
All core builder tests are passing.
The performance test result from Jirka Skrivanek:
Tested build was labeled by an artificial build numbers 201488880001 and 201488880002. In fact it was build from server_split branche #881eb115f249.
No significant increase at startup time observed in 3 most important tests:
ComplexJavaProjectStartup.Startup Time with 10 opened java files
ComplexNBProjectStartup.Startup Time with opened NB project
Some increase only on Windows8 but only up to 5%.
Scanning time decreased in "ScanProjectPerfTest.JEdit initial binary scan" and in contrary increased in "ScanProjectPerfTest.JEdit initial source scan". It is possibly cause by fix of #245912 (Preindexed sym files are not generated for rt.jar) in trunk. Otherwise measured values are in bounderies for trunk results.
Java, Java EE, Scripting, Web
- significantly decreased time for project creation.
- increased time of
- Source Packages expansion
- Help window opening
- java completion in editor
- Tools/Palette menu
We plan to integrate the branch to default tomorrow.
Merged in as changesets:
jet-main#a7e9b4eb3b8d (last-minute bugfixes, commit-validation fails)
Closing as fixed.
Integrated into 'main-silver', will be available in build *201410180001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
User: Miloslav Metelka <email@example.com>
Log: #247200 - Umbrella API Review of splitting NetBeans to non UI and UI modules - TCR editor.document: removal of Finder and AdjustFinder interfaces, rename getRow* to getLine* in LineDocumentUtilities.