[
https://issues.apache.org/jira/browse/AVRO-261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12828947#action_12828947
]
Thiruvalluvan M. G. commented on AVRO-261:
------------------------------------------
Perhaps a better approach (inspired by Scott's) is:
- Have a subclass of ArrayList called LockableArrayList, In that
- Have a boolean field _locked_, which is initially set to _false_.
- Have a void method lock(), which sets _locked_ to _true_.
- Override mutating methods of ArrayList, which will call the ArrayList's
corresponding method if _locked_ is _false_. If _locked_ is _true_, these
methods would throw.
Use LockableArrayList instead of ArrayList. After fully constructing the
container of the LockableArrayList, lock it.
What do we do with iterator() method? Fortunately only mutating method of
Iterator, remove, calls remove on the container. So one can remove things using
iterator if the container is not locked; if the container is locked, remove()
on the iterator would throw.
There is no change to the public interface of Schema. There is minimal
performance overhead during construction.
A similar approach however doesn't work well with LinkedHashMap. For maps we
have too many ways of modifying contents:
- Through map's put(), putAll(), remove() and clear().
- Through clear() of entrySet(), keySet() and valueSet().
- Through remove(), removeAll(), retainAll() of entrySet(), keySet() and
valueSet().
- Through remove() method of iterator() of entrySet(), keySet() and
valueSet().
The technique above works for the first two but not with the last two. Sad!
> Allow Schemas to be immutable
> -----------------------------
>
> Key: AVRO-261
> URL: https://issues.apache.org/jira/browse/AVRO-261
> Project: Avro
> Issue Type: New Feature
> Components: java
> Reporter: Kevin Oliver
> Assignee: Thiruvalluvan M. G.
> Priority: Minor
> Attachments: AVRO-261.patch
>
>
> It would be nice if there was the ability to have an immutable Schema in
> java.
> Without this, it makes sharing schemas risky. Also, with this, we could
> (lazily) cache the hashCode which is a fairly expensive operation today,
> especially on something like a record.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
