Community
Participate
Working Groups
In a talk at the university of Aarhus, Computer Science, Stephan Herrmann presented Object Teams to a class on Types in Objct-Oriented Programming Languages. I asked him what would happen if two different roles captured the same method at the same time - the answer is not relevant here, but he asked me to file an enhancement request for the compiler. So, the compiler should warn you if two roles capture the same method at the same time.
Thanks for the report! After thinking about this I will probably not add this to the compiler but add a separate builder to drive that analysis. The reason is: This kind of analysis requires knowledge about the whole system. The compiler, however, is geared at operating locally to show good performance when translating individual files. A separate builder will instead be able to use the search engine in order to find overlaping playedBy & callin bindings. Enabling the new analysis will then be a matter of adding one more builder to a project - for which I will probably add a menu action in the context menu below "Configure".
(In reply to comment #1) > Thanks for the report! > > After thinking about this I will probably not add this to the compiler > but add a separate builder to drive that analysis. The reason is: > This kind of analysis requires knowledge about the whole system. > The compiler, however, is geared at operating locally to show > good performance when translating individual files. > A separate builder will instead be able to use the search engine > in order to find overlaping playedBy & callin bindings. > > Enabling the new analysis will then be a matter of adding one more > builder to a project - for which I will probably add a menu action > in the context menu below "Configure". That makes sense. I didn't know you have that kind of separation in ObjectTeams.
Created attachment 201844 [details] proposed implementation In contrast to my initial assessment it seems easiest to indeed use the information directly from the compiler. Just, the compiler doesn't know when to start/stop collecting information. The required coordination between the BatchImageBuilder (because this analysis cannot work during incremental compilation) and the Compiler is performed by a new team CheckUniqueCallinCapture. This team activates callin-data collection only during a full build and at the end of the build it creates markers for all affected base methods. Initial experiments look promising, let's see how this works in real life. Open issues: - can we add markers to binary types? - can we create this warning also during command-line, ant, or maven builds? - In the IDE: should we use a different marker ID so that markers are not deleted by incremental compilation?
Created attachment 201861 [details] additional changes for binary types This patch leverages the infrastructure from bug 355297 to add markers also to binary types (classfiles). We also add some more attributes to the marker so that the Problems view can display Resource and Path of these markers. Finally, a new team (MarkerViewAdaptor) fixes openMarkerInEditor for our new markers. So far, these markers on binary types are not deleted, so they accumulate across full builds :-/
Created attachment 201862 [details] additional changes: marker lifecycle This patch adds a new marker type "Global Analysis Problem". These markers are persistent and are not deleted by incremental builds. A new team ProblemCleaner observes the start of any full or clean build in order to remove all Global Analysis Problems. This defines the life cycle of the new problem markers.
With the above improvements (which have been committed between r1910 and r1921) I consider this issue as resolved. Further enhancements should be discussed in separate bugs (if any).
Created attachment 202022 [details] additional change: avoid interference with workspace initialization With the new MarkerViewAdaptor the Choose Workspace dialog was no longer shown due to bug 204829, triggered here by loading interface IMarker when activating the team. With the latest patch we avoid this issue by one more indirection: an outer team that has no dependencies on the resources plugin, watching for initialization of the problems view and only then activating the inner team that contains the actual logic.
Verified using build 201112131519.
