Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipse-dev] About API Tools results analysis

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 AM
Subject:        [eclipse-dev] About API Tools results analysis
Sent 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: 
  • 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
So, I'm trying to understand why that happens through the following questions:
  • 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


Back to the top