Issue 13 in xmltool: add api to clone XMLTag instance
codesite...@google.com
Comment #10 on issue 13 by nzjess: add api to clone XMLTag instance
http://code.google.com/p/xmltool/issues/detail?id=13
Hi Mathieu,
Just wanted some further clarification re: comment #7 above, regarding
thread-safety. To use your
StringBuilder example, let's say I have a StringBuilder instance that
contains the characters "Hello World".
Now, if I somehow know (due to my programs known semantics) that this
particular instance will *never* be
modified, then I should be able to safely allow any number of threads to
concurrently read characters from
that StringBuilder - even though, as you say, StringBuilder is completely
unsynchronized internally.
My question is, is it safe to allow multiple threads to concurrently call
XMLTag.duplicate(), assuming that I
*know* no thread will ever modify the XMLTag instance that is being
duplicated? Or, even under these
conditions, must I still synchronize on the XMLTag instance in order to
safely duplicate it?
Thanks, and p.s. when is 3.0 planned for release?
Jesse.
--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings
codesite...@google.com
Comment #11 on issue 13 by mathieu.carbou: add api to clone XMLTag instance
http://code.google.com/p/xmltool/issues/detail?id=13
Hi,
As you could see in the source code, duplicate() is implemented like this:
public XMLTag duplicate() {
return XMLDoc.from(this, definition.isIgnoreNamespaces())
.gotoRoot()
.gotoTag(getCurrentTagLocation());
}
Since getCurrentTagLocation() is read-only operation, so is duplicate(). So
yes,
calling duplicate() from several threads will not cause issues.
I don't want to document all these sort of methods that are thread-safe for
the
simple reason that it will fix the API implementation also. I mean it is
possible for
some methods that their implementation would change at some time ans the
thread-safety behavior also, regarding if the new implementation modify or
not the
current state of the XMLTag.
So the best way is to check the source code, and obviously for duplicate()
i fear
they won't be any further change. It's been a while since the latest 2.xx
release has
been made and the library becomes more and more used and mature.
3.0 is not planned yet: since it is an major incrementation in version
corresponding
to an API break, i do not see any reason yet to release a 3.0 without the
deprecated
interfaces since there are not many issues that would require a 3.0
release. The
actual version is backward compatible with the old api deprecated and the
new api
working so as long as there are no new feature requests, bug fix to do,
there won't
be any release anymore.
Regards,
Mat'
codesite...@google.com
Comment #12 on issue 13 by nzjess: add api to clone XMLTag instance
http://code.google.com/p/xmltool/issues/detail?id=13
Thanks for the clarification on the duplicate() method. I did read the
source - however I couldn't quite 100%
convince myself of the answer :) So I asked to be sure. I guess the
StringBuilder example is more easy to
think about.
I do agree with not wanting to document the API in that way. Although in
practice, when an API becomes
widely used, even undocumented semantics can become 'the API', if a
majority of users are relying on them.
Though I think in this case there will be no problems.
About the 3.0 question. The reason I asked that is that I am using 2.11,
via the com.mycila... packages.
However, Eclipse is producing hundreds of 'method is deprecated' warnings
(one warning for every time I use
just about any method on the XMLTag interface). This are quite
distracting, but turning them off means I miss
legitimate instances of this warning in other parts of my code.
I suppose you can't just go to 2.12 and remove the com.google.code...
packages as that would be a breaking
change. But I understand that going to 3.0 is undesirable as there is no
real API change now that things have
settled. I would argue that you should go to 3.0 and remove the packages.
My argument is based on the fact
that when you decided to rebase the packages, that should have been the
point at which you bumped the
major revision number anyway (think Hibernate 1 -> 2). So even though you
have managed to switch
packages in this way, there's no guarantee that that should have been
possible, or will be possible in the
future (ie. it depends on your design, in particular your use of
interfaces). And remember, if you do change
the API in a major way again, there's always 4.0 :)
If you decide not to do anything, I may consider doing it myself (only for
my own use of course). Though this
is not ideal in case you do make more changes in 2.xx!
Anyway, those are my thoughts. Thanks again for the help with the API and
again great tool, I am a fan :)
Jesse.
codesite...@google.com
Comment #13 on issue 13 by mathieu.carbou: add api to clone XMLTag instance
http://code.google.com/p/xmltool/issues/detail?id=13
Hi,
Yes it's true... A 3.0 coule be released actually. I will do it today, it's
quite short.
Thanks you !