-
Notifications
You must be signed in to change notification settings - Fork 8
Have immutable flag to allow for returning unmodifiable collections in java.util.Collections #8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: development
Are you sure you want to change the base?
Have immutable flag to allow for returning unmodifiable collections in java.util.Collections #8
Conversation
Appears there are a number of issues with actually trying to use the unmodifiable collecitons I was hoping to specify: in HashMap, JML complains of a catastrophic internal error related to the quantifiers (which don't seem very different from those in other files) and also complains of contradictory invariants (i don't know which are in contradiction). Any advice for working around these or getting to the bottom of it? |
Steven,
|
Done as suggested. I don't think I've missed any more places where there should be a -RAC but I'll give it another check soon |
…for returning unmodifiable collections in java.util.Collecitons
188272c
to
5b18e8c
Compare
The previous
This restricts a
Rustan |
Hi Rustan, and all,
That sounds right to me; thanks, Rustan!
Regards,
Gary T. Leavens
437D Harris Center (Bldg. 116)
Computer Science, University of Central Florida
4000 Central Florida Blvd., Orlando, FL 32816-2362 USA
http://www.cs.ucf.edu/~leavens phone: +1-407-823-4758
[email protected]
…On Thu, Sep 6, 2018 at 1:56 PM Rustan Leino ***@***.***> wrote:
The previous Map.jml file (and quite possibly also other collection
types) had an invariant
public invariant content.owner == this;
This restricts a Map from being used by more than one client. For
immutable maps, one would like to allow sharing. For this reason, the
invariant ought to be updated to:
public invariant isImmutable || content.owner == this;
Rustan
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#8 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ALu2vTtSGmHeRNaabiyP-YZURQDwzaRHks5uYWHegaJpZM4WAv0R>
.
|
… (inheriting classes may be immutable)
I'm sorry, I spoke too hastily when I mentioned the |
This might require some careful thought. From what I understand, there are plans to rework OpenJML collections on a larger scale, so perhaps this is not so disruptive a change.
I wonder if a better (less coupled and cluttered) approach would be to simply have model classes implementing List, Collection, etc., that throw UnsupportedOperationExceptions and have the spec for Collections.unmodifiableList, unmodifiableSet, etc., return those.