| 2.0.0 RC1 with one small language change [message #672509] |
Sat, 21 May 2011 12:43 |
 Stephan Herrmann
Messages: 1853
Registered: July 2009 |
Senior Member |
|
|
Hi,
The simultaneous release train is rolling along its way to Indigo.
Today the full availability of Release Candidate 1 has been announced.
From the Object Teams Project this includes the first build with our
new version number: 2.0.0 RC1.
At this late stage our focus is shifting towards preparing the review
(scheduled for June 1-8, as for all projects participating in Indigo).
IP log and release docuware are in good shape and have been submitted.
I'd like to mention that scanning all bugzillas fixed in the last months showed
that we have some relevant contributions coming in on that channel:
Jan Marc Hoffmann has submitted several bug reports where I could
directly copy his test cases and incorporate them into our test suite.
Thanks, Jan Marc, for this contribution!
Language Change regarding LiftingFailedException:
Right before entering the polish phase, I made the changes discussed
in bug 337413, which could possibly require changes in existing OT/J
programms:
Note: if you've never used @SuppressWarnings("ambiguousbinding")
or @SuppressWarnings("abstractrelevantrole") you're probably not
affected by this change.
I was originally alerted by a discussion with Erik Ernst, who - together
with his student Matthias Diehn Ingesman - had investigated OT/J's
translation polymorphism with critical remarks on binding ambiguities.
They criticized that a team with potential binding ambiguity and a client
turning potential into actual ambiguity would require whole-system
analysis to find out whether a program is safe or not. Obviously,
we don't want that.
When a program fails at runtime due to a binding ambiguity it does so by
throwing a LiftingFailedException. All I had to do in order to make contracts
more explicit is hardening this exection from unchecked to checked.
As a consequence OT/J code with binding ambiguities (which always triggers
a warning in the first place) may have to declare that a LiftingFailedException
could be thrown in some places, notably methods with declared lifting.
Now the interface contracts are clear: if a method declares
LiftingFailedException it's the clients responsibility to handle the case where
a provided base object can indeed not be lifted. OTOH, if this exception is
not declared, clients may assume that lifting is indeed safe.
Interestingly, our own implementation of the OTDT contains not a single
occurrence of binding ambiguities. However, we have several parts in our
implementation that exhibit unsafe lifting for a different reason: potentially
relevant abstract roles, i.e., abstract bound roles, where smart lifting from
specific base classes may not be able to find a suitable non-abstract role
for lifting. After the change, also this situation may require the declaration
of throwing a LiftingFailedException in certain places.
From my experience of updating these locations, I collected some
alternative strategies in the corresponding paragraph of the N&N:
-> http://www.eclipse.org/objectteams/pages/new_in_2.0.html#bug337413
I hope that with these hints adopting this language change imposes no
problems. Else, please let us know here.
Request for Testing:
OK, I should stop here, because we're already into RC2 week, and on
Tuesday the OTDT 2.0 RC2 is due.
But for now: please give RC1 a try, so any severe bugs can be found and
resolved before the great release on June 22.
best,
Stephan
|
|
|
Powered by
FUDForum. Page generated in 0.04062 seconds
] 
Search
Help
Register
Login
Home
