Mikhail Loenko wrote:
> 2006/5/25, Mikhail Fursov <[EMAIL PROTECTED]>:
>> Yes, these ones can be only recomendations and can't be rules, because
>> the
>> most of them are performance related issues. E.g. nobody will file a bug
>> like 'this method is protected but can be private"
>
> Why not?
I
Erik Axel Nielsen wrote:
On 25. mai. 2006, at 17.42, Geir Magnusson Jr wrote:
Time for me to learn something - I thought there was only one monitor
per object how can different threads get different locks?
Hi, as I understand it, you use final on monitors to prevent the
following
I think it will be very hard to implement and does not worth the
efforts. Moreover these were recomendations only, and codebase can have
a thousands of reasonable violations such tool will always report.
On 5/25/06, Thorbjørn Ravn Andersen <[EMAIL PROTECTED]> wrote:
Would it be possible to writ
On 5/25/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote:
The first grep result is:
private PropertyChangeEvent createPropertyChangeEvent(
String propertyName, int oldValue, int newValue) {
return new PropertyChangeEvent(sourceBean, propertyName,
new Integer(o
Yes, you are right: different threads can get different locks only on
different objects.
Lets see BenContextSupport code as example:
private void addChild(Object targetChild) {
// Add a new child using targetChild as a key and
// its BCSChild instance as an entry
synchronized(this.children) {
On 25. mai. 2006, at 17.42, Geir Magnusson Jr wrote:
Time for me to learn something - I thought there was only one
monitor per object how can different threads get different locks?
Hi, as I understand it, you use final on monitors to prevent the
following from happening:
Let's sa
Mikhail Fursov wrote:
On 5/25/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote:
> 2) Try to make all objects used for synchronization 'final' (we have a
lot
> of non-final monitors in API, so we give a chance to bugs)
Could you please explain with details and an example?
This is not a bug (E
Hi Mikhail
2006/5/25, Mikhail Fursov <[EMAIL PROTECTED]>:
On 5/25/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote:
>
> > 2) Try to make all objects used for synchronization 'final' (we have a
> lot
> > of non-final monitors in API, so we give a chance to bugs)
>
> Could you please explain with det
On 5/25/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote:
> 2) Try to make all objects used for synchronization 'final' (we have a
lot
> of non-final monitors in API, so we give a chance to bugs)
Could you please explain with details and an example?
This is not a bug (E.g. ExemptionMechanism:47
Mikhail Fursov skrev den 25-05-2006 15:22:
Guys,
What do you think about the following recomendations?
These are only 'recomendations' and not must have rules, but if these
recomendations will become 'official' it will improve the quality of
API in
the long perspective.
1) Try avoid "magic n
Ok, I will "quote" you in future :)
On 5/25/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote:
2006/5/25, Mikhail Fursov <[EMAIL PROTECTED]>:
> Yes, these ones can be only recomendations and can't be rules, because
the
> most of them are performance related issues. E.g. nobody will file a bug
> lik
2006/5/25, Mikhail Fursov <[EMAIL PROTECTED]>:
Guys,
What do you think about the following recomendations?
These are only 'recomendations' and not must have rules, but if these
recomendations will become 'official' it will improve the quality of API in
the long perspective.
1) Try avoid "magic
2006/5/25, Mikhail Fursov <[EMAIL PROTECTED]>:
On 5/25/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote:
>
>
>
> > 1) Try avoid "magic number" nor "magic strings" in code ( the constant
> name
> > by itself can be a good comment )
>
> That's a universal rule of programming, isn't it? :)
Yes, and
On 5/25/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote:
> 1) Try avoid "magic number" nor "magic strings" in code ( the constant
name
> by itself can be a good comment )
That's a universal rule of programming, isn't it? :)
Yes, and I listed it after reading our sources :), E.g. see JIRA48
Mikhail Fursov wrote:
Guys,
What do you think about the following recomendations?
These are only 'recomendations' and not must have rules, but if these
recomendations will become 'official' it will improve the quality of
API in
the long perspective.
1) Try avoid "magic number" nor "magic st
Guys,
What do you think about the following recomendations?
These are only 'recomendations' and not must have rules, but if these
recomendations will become 'official' it will improve the quality of API in
the long perspective.
1) Try avoid "magic number" nor "magic strings" in code ( the consta
Nice! Well done!
Stepan Mishura wrote:
Hi,
It is hard to track decisions made on harmony-dev mailing list and I've
tried to summarize them[1]. The mail archive is quite big and most probably
I missed or misunderstand something. Feel free to send patches to improve
web-page content.
[1]
http:/
Stepan,
Thanks for your great job!
But now we should try to add to this list ALL the discussin results :)
SY, Alexey
2006/5/24, Stepan Mishura <[EMAIL PROTECTED]>:
Hi,
It is hard to track decisions made on harmony-dev mailing list and I've
tried to summarize them[1]. The mail archive is quite
Very useful document.
Now a have a reason to file some more bugs to JIRA against classlib sources
that violates this agreement.
**
On 5/24/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote:
Great!
2006/5/24, Stepan Mishura <[EMAIL PROTECTED]>:
> Hi,
>
> It is hard to track decisions made on harmony
Great!
2006/5/24, Stepan Mishura <[EMAIL PROTECTED]>:
Hi,
It is hard to track decisions made on harmony-dev mailing list and I've
tried to summarize them[1]. The mail archive is quite big and most probably
I missed or misunderstand something. Feel free to send patches to improve
web-page conten
Hi,
It is hard to track decisions made on harmony-dev mailing list and I've
tried to summarize them[1]. The mail archive is quite big and most probably
I missed or misunderstand something. Feel free to send patches to improve
web-page content.
[1]
http://incubator.apache.org/harmony/subcomponent
21 matches
Mail list logo
