| Re: [eclipse-dev] About API Tools results analysis |
Hi John, thanks a lot for your attention!About 1. "there are often "internal" clients of the API, even within the same plugin, which are willing to update when the API changes and therefore can afford to extend or reference APIs in illegal ways."That's what I'm trying to understand and you made it clear!Would you say that these the problems (internal or friend clients) are less relevant than the others?is there any way to exclude them from the restrictions?About 2. Fantastic explanation! :)Let me ask you, is there any other way to get advantage of TreeViewer without extending it? I'm trying to understand whether the restriction should be changed or the way developers use TreeViewer should change.--JoãoOn Thu, Jul 25, 2013 at 11:18 AM, João Arthur <joaoarthurbm@xxxxxxxxx> wrote:
Hi there, I'm very glad to hear from you!Martin, I'm analyzing the official test reports. As I said, I'm analyzing them over time, that is, the data that I've shown you regards to all the reports between versions 3.4 and 4.3."It would be interesting to review some of the illegal references that you found."That's exactly what I need :) Let's try by examples. Most of the "illegal extends" are from org.eclipse.swt.events.*. For instance,org.eclipse.swt.events.VerifyListener extends non-API type org.eclipse.swt.internal.SWTEventListener
May you answer the questions based on this example?Another important fact is that 55 of the 56 were fixed in version 4.2.2.Additional questions:- Why and How were they fixed?I'm starting to write a report now. You can also answer there. Nothing official yet. See: eclipse reportThanks a lot for you attention!
On Thu, Jul 25, 2013 at 8:08 AM, John Arthorne <John_Arthorne@xxxxxxxxxx> wrote:
I think there are two broad categories of "illegal use" you are capturing here:
1. Usage from "friend" plugins that are very closely related and always ship concurrently. The strict API usage guidelines must be followed for any client that wants to take advantage of full binary compatibility between releases. However, there are often "internal" clients of the API, even within the same plugin, which are willing to update when the API changes and therefore can afford to extend or reference APIs in illegal ways. As Dani has said, we typically filter this kind of usage out of our reports and I think many of the examples below are like that. For example SWTEventListener is a dummy interface that no client should ever implement, but within SWT it is used as a shim layer to enable running SWT on older class libraries where java.util.EventListener is not available.
2. Cases where the API is not sufficiently flexible, and the only way to get the degree of customization required is via illegal API use. I suspect many of the TreeViewer extensions fall into this category. TreeViewer API could probably evolve to support many of these cases and remove the need for subclassing. There is usually a trade-off where offering greater flexibility for clients constrains how the API can evolve in the future. Sometimes the API designer will hold off on offering a certain kind of customization if it will "lock" them into particular design choices and prevent future evolution of the API. To give just one random example, OutlineTreeViewer in JDT illegally extends TreeViewer to customize the expansion logic for inner classes. One could imagine new API on TreeViewer to offer customization of expansion logic that would remove the need for subclassing. However that hook might make it difficult to optimize the tree expansion code in the future, or have other negative consequences. So in general a large number of "illegal uses" may point to problematic API that needs more flexibility, but there are often trade-offs involved in doing so.
John
From: João Arthur <joaoarthurbm@xxxxxxxxx>
To: eclipse-dev@xxxxxxxxxxx,
Date: 07/24/2013 08:08 AMSubject: [eclipse-dev] About API Tools results analysisSent by: eclipse-dev-bounces@xxxxxxxxxxx
_______________________________________________
Hi there,
My name is João Brunet and I'm a PhD student at UFCG - Brazil, currently visiting professor Gail Murphy at University of British Columbia.
In my PhD, I'm analyzing the API Tools Verification Reports of Eclipse project over time. I'm collecting some interesting observations from this data. However, I need some of specialists' opinion about these tests results. Would you please answer some questions regarding this topic?
For example, I found that:
So, I'm trying to understand why that happens through the following questions:
- org.eclipse.swt.internal.SWTEventListener is illegally extended by 56 classes
- org.eclipse.jdt.core.refactoring.descriptors.JavaRefactoringContribution illegally extended by 39 classes
- org.eclipse.jdt.internal.ui.javaeditor.JavaTextSelection is illegally referenced as a parameter of 27 methods
- org.eclipse.jdt.core.refactoring.descriptors.RenameJavaElementDescriptor is illegally instantiated by 20 classes
- org.eclipse.jface.viewers.TreeViewer is illegally extended by 14 classes
- Why are there so many illegal access to these particular classes?
- What is the role of each of these classes in the architecture of Eclipse?
- Can you assign importance for each one? (critical, high, medium or low)
Please, let me here from you all. I would be very grateful if you agree to answer these and some other questions. Your opinion will improve a lot my results. The more answers and discussion, the better are the results.
Thank you very much in advance.
Regards,
João.
https://sites.google.com/site/joaoarthurbm/research
eclipse-dev mailing list
eclipse-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/eclipse-dev
_______________________________________________
eclipse-dev mailing list
eclipse-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/eclipse-dev