nested synchronized
Marcin Biegan - 17-06-2007 00:54
nested synchronized
Witam
Jak to dok?adnie jest z zagnie?d?onymi blokami synchronized?
np.
synchronized(x){
synchronized(y){
y.wait();
}
}
Czy monitor x jest 'zaj?ty' po wywo?aniu y.wait()? Z moich testów wynika, ?e
jest zwalniany, ale szuka?em w lang. reference i nie znalazlem opisu tego
zachowania. Mo?e kto? poda? gdzie dok?adnie jest napisane jak to si? zachowuje?
(na googlach trudno cokolwiek na ten temat znale??)
--
pozdrawiam
Marcin Biegan
Zbyszek Malec - 17-06-2007 00:54
Dnia Fri, 15 Jun 2007 19:37:20 +0200, Marcin Biegan napisa?(a):
> Czy monitor x jest 'zaj?ty' po wywo?aniu y.wait()? Z moich testów wynika, ?e
> jest zwalniany, ale szuka?em w lang. reference i nie znalazlem opisu tego
> zachowania. Mo?e kto? poda? gdzie dok?adnie jest napisane jak to si? zachowuje?
> (na googlach trudno cokolwiek na ten temat znale??)
Z dokumentacji do Object.wait(long):
Note that the wait method, as it places the current thread into the wait
set for this object, unlocks only this object; any other objects on which
the current thread may be synchronized remain locked while the thread
waits.
Wi?c nie powinien zwalnia? blokady.
--
Zbyszek Malec Ustronie 104
jid: zbyszanna@jid.pl
Marcin Biegan - 17-06-2007 00:54
Zbyszek Malec napisa?(a):
> Dnia Fri, 15 Jun 2007 19:37:20 +0200, Marcin Biegan napisa?(a):
>
>> Czy monitor x jest 'zaj?ty' po wywo?aniu y.wait()? Z moich testów wynika, ?e
>> jest zwalniany, ale szuka?em w lang. reference i nie znalazlem opisu tego
>> zachowania. Mo?e kto? poda? gdzie dok?adnie jest napisane jak to si? zachowuje?
>> (na googlach trudno cokolwiek na ten temat znale??)
>
> Z dokumentacji do Object.wait(long):
>
> Note that the wait method, as it places the current thread into the wait
> set for this object, unlocks only this object; any other objects on which
> the current thread may be synchronized remain locked while the thread
> waits.
>
> Wi?c nie powinien zwalnia? blokady.
Widzia?em ten tekst, ale co? mi nie pasuje.
Konkretniej - dlaczego ten kod wy?wietla 'blah' zamiast sie zatrzyma?:
public class Test {
public static void main(String []args){
final Test test = new Test();
new Thread(){
public void run(){
test.a();
}
}.start();
new Thread(){
public void run(){
test.b();
}
}.start();
}
Integer x = 0, y = 0;
public void a(){
try {
synchronized(x){
synchronized(y){
y.wait();
System.out.println("y notified");
}
}
} catch (InterruptedException e) {
e.printStackTrace();
}
}
public void b(){
try {
Thread.sleep(1000);
synchronized(x){
System.out.println("blah");
}
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}
--
pozdrawiam
Marcin Biegan
Piotr Kobzda - 17-06-2007 00:54
Marcin Biegan wrote:
> Konkretniej - dlaczego ten kod wy?wietla 'blah' zamiast sie zatrzyma?:
Dziwne... Wygl?da mi to na powa?ny bug JVMy. U mnie (WinXP) jedynie
JRockit zachowuje si? z tym kodem zgodnie z oczekiwaniami. JVMa
Sun'owska, jak i IBMa, niestety nie. Mo?e to jakie? dzikie
optymalizacje, albo co? z ich pogranicza?... Nie wiem jeszcze...
Dopóki nie dojdziemy powodów proponuj? na atomow? synchronizacj? przej??
(poni?ej doko?czony ekwiwalent Twojego kodu). To dzia?a jak nale?y.
piotr
import java.util.concurrent.locks.*;
public class Test2 {
public static void main(String []args) {
final Test2 test = new Test2();
new Thread(){
public void run(){
test.a();
}
}.start();
new Thread(){
public void run(){
test.b();
}
}.start();
new Thread(){
public void run(){
test.c();
}
}.start();
}
Lock x = new ReentrantLock(), y = new ReentrantLock();
Condition yWait = y.newCondition();
public void a(){
try {
x.lock();
try {
y.lock();
try {
yWait.await();
System.out.println("y notified");
} finally {
y.unlock();
}
} finally {
x.unlock();
}
} catch (InterruptedException e) {
e.printStackTrace();
}
}
public void b(){
try {
Thread.sleep(1000);
x.lock();
try {
System.out.println("blah");
} finally {
x.unlock();
}
} catch (InterruptedException e) {
e.printStackTrace();
}
}
public void c(){
try {
Thread.sleep(5000);
y.lock();
try {
yWait.signal();
} finally {
y.unlock();
}
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}
0x28and0x4 - 17-06-2007 00:54
Piotr Kobzda napisa?(a):
> Marcin Biegan wrote:
>
>> Konkretniej - dlaczego ten kod wy?wietla 'blah' zamiast sie zatrzyma?:
>
> Dziwne... Wygl?da mi to na powa?ny bug JVMy. U mnie (WinXP) jedynie
> JRockit zachowuje si? z tym kodem zgodnie z oczekiwaniami. JVMa
> Sun'owska, jak i IBMa, niestety nie. [..]
Pu?ci?em to pod Sunowsk? JVM 5 (WinXP) i te? mam wynik taki jak Ty i Marcin.
btw:
(do Marcina)
Na wszelki wypadek wspomn?, ?e do synchronizacji w?tków mo?na te? u?y?
java.util.concurrent. U?ywam tego pakietu cz?sto i ... z przyjemno?ci :>
Nie dywaguj?c teraz, czego potrzebuje Marcin, osobi?cie do
synchronizacji wybra?bym java.util.concurrent. Mam wra?enie, ?e jako?
lepiej nad tym panuj? (w porównaniu do synchronized).
Pozdrawiam,
Adam
0x28and0x4 - 17-06-2007 00:54
Piotr Kobzda napisa?(a):
> import java.util.concurrent.locks.*;
Damn! Przecie? w?a?nie u?y?e? w swoim kodzie pakietu concurrent :) Sorry :>
pozdrowienia,
Adam
jolz - 17-06-2007 00:54
> Dziwne... Wygl?da mi to na powa?ny bug JVMy. U mnie (WinXP) jedynie
> JRockit zachowuje si? z tym kodem zgodnie z oczekiwaniami. JVMa
> Sun'owska, jak i IBMa, niestety nie. Mo?e to jakie? dzikie
> optymalizacje, albo co? z ich pogranicza?
Owszem optymalizacje, wyjasnione w opisie valueOf() Integera.
Wyglada na to ze JRockit tworzy za kazdym razem nowy obiekt co nie
jest zbyt mile. No ale przynajmniej dzieki temu zachowuje sie
przewidywalnie.
Piotr Kobzda - 17-06-2007 00:54
Marcin Biegan wrote:
[...]
Mam! Tu masz problem:
> Integer x = 0, y = 0;
Synchronizujesz wszystko na tym samym obiekcie. Zast?p np. tym:
Integer x = 0, y = new Integer(0);
Przy okazji wysz?o, ?e to JRockit (build 1.6.0-b105) ma buga.
W jego otoczeniu x == y daje false, co oczywi?cie niezgodne ze
specyfikacj? j?zyka jest:
"If the value p being boxed is true, false, a byte, a char in the range
\u0000 to \u007f, or an int or short number between -128 and 127, then
let r1 and r2 be the results of any two boxing conversions of p. It is
always the case that r1 == r2."
[JLS3 5.1.7 Boxing Conversion]
piotr
Artur Zabronski - 17-06-2007 00:54
On Fri, 2007-06-15 at 21:49 +0000, jolz wrote:
>
> Owszem optymalizacje, wyjasnione w opisie valueOf() Integera.
> Wyglada na to ze JRockit tworzy za kazdym razem nowy obiekt co nie
> jest zbyt mile. No ale przynajmniej dzieki temu zachowuje sie
> przewidywalnie.
>
Fakt to by??o problemem. Wystarczy nadaÄ? x, y inne warto??ci albo utworzyÄ?
nowe instancje u??ywajÄ?c konstruktora.
Tak na marginesie dodam podobnÄ? ciekawostkÄ? - trochÄ? temu natknÄ???em siÄ?
na podobne problemy z instancjami ale przy
serializowanych/deserializowanych Enum-ach. Deserializacja tworzy nowÄ?
zawsze instancjÄ? wiÄ?c jak ??atwo siÄ? domy??liÄ? wiÄ???e siÄ? to tylko z
problemami i to ca??kiem niemi??ymi. switch zachowuje siÄ? normalnie bo
operuje na ordinal-ach ale ju?? por??wnania przez ==/equals nie.. Trzeba
uwa??aÄ? na takie kruczki ;-)
Gdyby czasem kto?? szuka?? rozwiÄ?zania z Enum-ami to moje rozwiÄ?zanie
wyglÄ?da tak:
public enum Foo implements java.io.Serializable {
FOO, BAR;
private Object readResolve() throws ObjectStreamException {
return values()[ordinal()];
}
}
--
Pozdrawiam,
Artur
Piotr Kobzda - 17-06-2007 00:54
jolz wrote:
> Owszem optymalizacje, wyjasnione w opisie valueOf() Integera.
Zgadza si?, te? ju? doszed?em. :)
> Wyglada na to ze JRockit tworzy za kazdym razem nowy obiekt co nie
> jest zbyt mile.
Tak, zawsze niestety nowy.
> No ale przynajmniej dzieki temu zachowuje sie
> przewidywalnie.
Ja tam wol? jednak zgodno?? ze specyfikacj? (nawet je?li nie wszystko
tam zapisane jest idealne...). Inaczej to o przeno?no?ci Javy mo?emy
zupe?nie zapomnie?...
piotr
Piotr Kobzda - 17-06-2007 00:54
Artur Zabronski wrote:
> Tak na marginesie dodam podobnÄ? ciekawostkÄ? - trochÄ? temu natknÄ???em siÄ?
> na podobne problemy z instancjami ale przy
> serializowanych/deserializowanych Enum-ach. Deserializacja tworzy nowÄ?
> zawsze instancjÄ? wiÄ?c jak ??atwo siÄ? domy??liÄ? wiÄ???e siÄ? to tylko z
> problemami i to ca??kiem niemi??ymi. switch zachowuje siÄ? normalnie bo
> operuje na ordinal-ach ale ju?? por??wnania przez ==/equals nie.
Hmm.. M??g??by?? pokazaÄ? kod, kt??rym uda??o Ci siÄ? to osiÄ?gnÄ?Ä??
Wg mnie, je??li tak mia??e??, to albo jakiego?? bug'a implementacji enum??w,
albo w??asnego do??wiadczy??e??. Specyfikacja gwarantuje tylko jednÄ?
instancjÄ? dla tej samej sta??ej, nie trzeba nic kombinowaÄ?.
piotr
Artur Zabronski - 17-06-2007 00:54
On Sat, 2007-06-16 at 00:36 +0200, Piotr Kobzda wrote:
> Hmm.. M??g??by?? pokazaÄ? kod, kt??rym uda??o CisiÄ? to osiÄ?gnÄ?Ä??
>
TrochÄ? du??o by pisaÄ? ;-)
> Wg mnie, je??li tak mia??e??, to albo jakiego?? bug'a implementacji enum??w,
> albo w??asnego do??wiadczy??e??. Specyfikacja gwarantujetylko jednÄ?
> instancjÄ? dla tej samej sta??ej, nie trzeba nic kombinowaÄ?.
>
Z tego co pamiÄ?tam i z tego co wyszuka??em problem dotyczy tylko Enum-??w
przekazywanych przez RMI/IIOP i sÄ? zg??oszenia tego problemu. Niestety w
tym wypadku trzeba kombinowaÄ? tak jak poda??em, bo Enum kt??ryprzyszed??
ze zdalnego wywo??ania jest nowÄ? instancjÄ? - owszem ordinal iname sÄ? te
same ale hashCode inny stÄ?d equals() zawodzi tym bardziej operator ==.
Taka ciekawostka - patrzy??em w SVN OpenJDK7 i tam deserializacja Enum-??w
w og??le jest wy??Ä?czona...
--
Pozdrawiam,
Artur
Artur Zabronski - 17-06-2007 00:54
On Sat, 2007-06-16 at 00:36 +0200, Piotr Kobzda wrote:
>
> Hmm.. M??g??by?? pokazaÄ? kod, kt??rym uda??o CisiÄ? to osiÄ?gnÄ?Ä??
>
> Wg mnie, je??li tak mia??e??, to albo jakiego?? bug'a implementacji enum??w,
> albo w??asnego do??wiadczy??e??. Specyfikacja gwarantujetylko jednÄ?
> instancjÄ? dla tej samej sta??ej, nie trzeba nic kombinowaÄ?.
>
Sprawdzi??em na szybko:
- do pliku: ok,
- po RMI: ok,
- po IIOP: z problemami, przyk??adowy kod:
http://arturz.net/~artur/enum-iiop-test.zip
Wynik wywo??ania zdalnego EJB (metoda zwraca TestEnum.ONE):
// System.out.println("==: " + (en == TestEnum.ONE));
==: false
// System.out.println("hashCode: " + en.hashCode() + " " +
// TestEnum.ONE.hashCode());
hashCode: 14633156 19032695
--
Pozdrawiam,
Artur
Piotr Kobzda - 17-06-2007 00:54
Artur Zabronski wrote:
> Sprawdzi??em na szybko:
> - do pliku: ok,
> - po RMI: ok,
> - po IIOP: z problemami,
A ja znalaz??em jeszcze:
http://bugs.sun.com/bugdatabase/view...bug_id=6277781
Z komentarzy wynika, ??e to problem bardziej ze specyfikÄ? IDL'a ni?? z
enumami, a dok??adniej z implementacjÄ? RMI/IIOP.
Czyli po prostu kolejny bug (na dodatek w obszarze, z kt??rego
szczÄ???liwie nie korzystam... :) ). Ale dziÄ?ki za informacjÄ?, dobrze
wiedzieÄ?, ??e jednak nie muszÄ? kombinowaÄ?. :)
piotr
Artur Zabronski - 17-06-2007 00:54
On Sat, 2007-06-16 at 02:36 +0200, Piotr Kobzda wrote:
>
> A ja znalaz??em jeszcze:
> http://bugs.sun.com/bugdatabase/view...bug_id=6277781
>
> Z komentarzy wynika, ??e to problem bardziej ze specyfikÄ? IDL'a ni?? z
> enumami, a dok??adniej z implementacjÄ? RMI/IIOP.
>
Tak pamiÄ?tam ??e w??a??nie czyta??em to zg??oszenie i o to chodzi??o, no ale
rozwiÄ?zaÄ? to mo??na tak jak poda??em wcze??niej :-)
> Czyli po prostu kolejny bug (na dodatek w obszarze, z kt??rego
> szczÄ???liwie nie korzystam... :) ). Ale dziÄ?ki za informacjÄ?, dobrze
> wiedzieÄ?, ??e jednak nie muszÄ? kombinowaÄ?. :)
>
A kto zg??asza ten bug w JRockit? ;-)
--
Pozdrawiam,
Artur
Marcin Biegan - 17-06-2007 00:54
0x28and0x4 napisa?(a):
> Piotr Kobzda napisa?(a):
>> Marcin Biegan wrote:
>>
>>> Konkretniej - dlaczego ten kod wy?wietla 'blah' zamiast sie zatrzyma?:
>>
>> Dziwne... Wygl?da mi to na powa?ny bug JVMy. U mnie (WinXP) jedynie
>> JRockit zachowuje si? z tym kodem zgodnie z oczekiwaniami. JVMa
>> Sun'owska, jak i IBMa, niestety nie. [..]
>
> Pu?ci?em to pod Sunowsk? JVM 5 (WinXP) i te? mam wynik taki jak Ty i Marcin.
>
> btw:
> (do Marcina)
> Na wszelki wypadek wspomn?, ?e do synchronizacji w?tków mo?na te? u?y?
> java.util.concurrent. U?ywam tego pakietu cz?sto i ... z przyjemno?ci :>
>
> Nie dywaguj?c teraz, czego potrzebuje Marcin, osobi?cie do
> synchronizacji wybra?bym java.util.concurrent. Mam wra?enie, ?e jako?
> lepiej nad tym panuj? (w porównaniu do synchronized).
No i sie wyja?ni?o - mój b??d ;)
Dzi?ki wszystkim za pomoc.
A co do tego, do czego mi to potrzebne - w?a?ciwie to do niczego. Prowadz?ca
zaj?cia ze wspó?bie?no?ci powiedzia?a, ?e tylko jeden lock jest zwalniany, ale
przyk?adowy kod który machn??em, ?eby to sprawdzi? (przytoczony w pierwszym
po?cie) dzia?a? zupe?nie inaczej - st?d pytanie.
Zwalnianie ca?ej 'listy' locków by?o by bardzo fajne w ma?ych programach, ale w
wi?kszych powodowa?o by pewnie wi?ksze problemy, ni? s? teraz, wi?c wszystko
jest ok ;)
--
pozdrawiam
Marcin Biegan
Piotr Kobzda - 17-06-2007 00:55
Bug boksowania =?UTF-8?B?aW50w7N3IHcgSlJvY2tpdCBbYnnFgm86IG5lc3Rl?==?UT F-8?B?ZCBzeW5jaHJvbml6ZWRd?=
Artur Zabronski wrote:
> A kto zg??asza ten bug w JRockit? ;-)
Ja siÄ? podda??em. Straci??em na stronach BEA trochÄ? czasu w poszukiwaniu
jak zg??osiÄ? buga i niestety nie znalaz??em. :/ Chcia??em te?? wys??aÄ?
choÄ?by posta na forum JRockit
(http://forums.bea.com/bea/forum.jspa?forumID=2009), ale do tego trzeba
byÄ? zarejestrowanym u??ytkownikiem, wiÄ?c sobie odpu??ci??em. Mo??e kto??
bÄ?dzie wytrwalszy?... ;-)
Sprawdzi??em jeszcze, ??e problem dotyczy tylko boksowania inta, pozosta??e
prymitywy boksowane sÄ? poprawnie. Tak siÄ? sk??ada, ??e klasa Integer jest
w JRockit obs??ugiwana specjalnie (z pominiÄ?ciem bajtkodu z rt.jar, w
kt??rym, nawiasem m??wiÄ?c, valueOf() jest zaimplementowana poprawnie), i
najwyra??niej nie wszystko siÄ? przy tym uda??o...
piotr
Artur Zabronski - 17-06-2007 00:55
Piotr Kobzda wrote:
> Ja siÄ? podda??em. Straci??em na stronach BEA trochÄ? czasu w poszukiwaniu
> jak zg??osiÄ? buga i niestety nie znalaz??em. :/ Chcia??em te?? wys??aÄ?
> choÄ?by posta na forum JRockit
> (http://forums.bea.com/bea/forum.jspa?forumID=2009), ale do tego trzeba
> byÄ? zarejestrowanym u??ytkownikiem, wiÄ?c sobie odpu??ci??em. Mo??e kto??
> bÄ?dzie wytrwalszy?... ;-)
>
Ja dzisiaj r??wnie?? szuka??em i nie znalaz??em tam bug trackera. Ale zdaje
mi siÄ? ??e jest tu kto?? z BEA to mo??e bÄ?dzie pomocny? ;-)
> Sprawdzi??em jeszcze, ??e problem dotyczy tylko boksowania inta, pozosta??e
> prymitywy boksowane sÄ? poprawnie. Tak siÄ? sk??ada, ??e klasa Integer jest
> w JRockit obs??ugiwana specjalnie (z pominiÄ?ciem bajtkodu z rt.jar, w
> kt??rym, nawiasem m??wiÄ?c, valueOf() jest zaimplementowana poprawnie), i
> najwyra??niej nie wszystko siÄ? przy tym uda??o...
>
Te?? sprawdza??em i dotyczy w??a??nie tylko Integer-a.
(artur@ubuntu)(115/pts/0)(11:50pm:06/16/07)-
(%:/tmp)- cat Test.java
public class Test {
public static void main(String[] args) {
Byte b1 = 0, b2 = 0;
System.out.println(b1 == b2);
Character c1 = 1, c2 = 1;
System.out.println(c1 == c2);
Short s1 = 2, s2 = 2;
System.out.println(s1 == s2);
Integer i1 = 4, i2 = 4;
System.out.println(i1 == i2);
Long l1 = 8L, l2 = 8L;
System.out.println(l1 == l2);
}
}
(artur@ubuntu)(116/pts/0)(11:50pm:06/16/07)-
(%:/tmp)/usr/local/jdk1.6.0_01/bin/java Test
true
true
true
true
true
(artur@ubuntu)(117/pts/0)(11:51pm:06/16/07)-
(%:/tmp)- /usr/local/jrockit-R27.2.0-jdk1.6.0/bin/java Test
true
true
true
false
true
--
Pozdrawiam,
Artur
Waldemar Kot - 18-06-2007 00:02
=?ISO-8859-2?Q?Re:_Bug_boksowania_int=F3w_w_JRoc?= =?ISO-8859-2?Q?kit_[by=B3o:_nested_synchronized]?=
Cze??,
Wbrew pozorom, sprawa jest troch? bardziej skomplikowana ni? to, jak j?
przedstawiacie. Sprawdz? to jeszcze dok?adniej u ?ród?a (tj. deweloperów
JRockit), ale okazuje si?, ?e ró?nica w implementacji Integer'a w JRockit
zosta?a spowodowana przez jaki? dziwny kod, który Sun wprowadzi? od JDK 1.5
Update 10 pod has?em "optymalizacja", a który nasi deweloperzy wy??czyli z 2
powodów - b??dów w implementacji Suna i zak?ócania optymalizacji JRockit. Ten
kod zachowuje si? dziwacznie - polecam wykona? test Artura, ze zmienion?
nast?puj?c? lini?:
zamiast: Integer i1 = 4, i2 = 4;
wstawi?: Integer i1 = 4000, i2 = 4000;
O ile pierwszy da wynik:
true
true
true
true
true
O tyle drugi da wynik:
true
true
true
false
true
B??d ten wychodzi zarówno na JVM Suna, jak i BEA JRockit.
To co wygl?da na faktycznie "dodatkowy" b??d JRockit, to to, ?e w JRockit
dostajemy false nawet, je?li warto?ci tych Integer'ów s? ma?e (poni?ej 128). W
sumie oba s? bug'ami, ale (he he) przynajmniej JRockit robi ten bug
deterministycznie, tj. dla wszystkich warto?ci Integer.
Inn? ciekawostk? jest to, ?e ten "dodatkowy" b??d JRockit-a objawia si? tylko
w najnowszych JRockit (27.2). Wersje poprzednie (w??cznie z wersjami zawartymi
w WebLogic Server 9.x i 10.x), nie maj? tego "dodatkowego" b??du (troch? mi to
zabra?o czasu, ale sprawdzi?em, ?e tak jest - w sumie te testy zrobi?em na 13
wersjach JVM - 5 Suna i 8 JRockit). Czyli (he he) ju? nie mamy tego
jednakowego zachowania dla wszystkich Integer'ów.
Tak jak napisa?em - popytam jeszcze tych co wiedz? najlepiej (ludzi od
JRockit) i je?li potwierdzi si?, ?e to jest b??d to otworz? taki case. Popytam
te?, czy kto? ju? zg?osi? tego buga w Sun'ie.
Pozdrawiam,
Waldek Kot
BEA
--
Wys?ano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/
Waldemar Kot - 18-06-2007 00:02
=?ISO-8859-2?Q?Re:_Bug_boksowania_int=F3w_w_JRoc?= =?ISO-8859-2?Q?kit_[by=B3o:_nested_synchronized]?=
Zg?aszanie problemów z softem BEA jest dosy? proste. Ze strony g?ównej BEA
(www.bea.com), z opcji Support wybiera si? eSupport (szybsza opcja to wpisanie
adresu: support.bea.com).
Aby zg?osi? problem, trzeba by? zarejestrowanym u?ytkownikiem na bea.com
(m.in. dlatego, ?e eSupport to jest normalny kana? kontaktowy z klientami, a
nie lista dyskusyjna). Rejestracja niczym nie grozi - jak kto? nie chce, to
nie dostaje news'ów z BEA.
Rejestruje si? raz - po to aby ?ci?ga? software, te? trzeba si? zalogowa?.
Po zarejestrowaniu i zalogowaniu si? do eSupport, w menu po prawej stronie
pojawia si? opcja Case Management. Dalej wype?nia si? formularz z opisem problemu.
Klienci maj? jeszcze mo?liwo?? skojarzenia problemu z ich licencjami. Takie
case'y maj? wy?szy priorytet obs?ugi.
W opcji "About BEA eSupport" mo?na znale?? dodatkowe opisy, dokumenty i tutoriale.
Pozdrawiam,
Waldek Kot
BEA
--
Wys?ano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/
Aleksander Galicki - 19-06-2007 00:06
=?ISO-8859-2?Q?Re:_Bug_boksowania_int=F3w_w_JRoc?= =?ISO-8859-2?Q?kit_[by=B3o:_nested_synchronized]?=
Waldemar Kot <waldemar_kot.WYTNIJ@gazeta.pl> napisa³(a):
> Cze¶æ,
>
> Wbrew pozorom, sprawa jest trochê bardziej skomplikowana ni¿ to, jak j±
> przedstawiacie. Sprawdzê to jeszcze dok³adniej u ¼ród³a (tj. deweloperów
> JRockit),
Zrodlem jest specyfikacja Javy, a nie developerzy WebLogic. Specyfikacja w
tym watku byla juz cytowana, co oznacza, ze nie przeczytales nie tylko
specyfikacji ale nawet watku w ktorym odpowiadasz. Once again: " If the value
p being boxed is true, false, a byte, a char in the range \u0000 to \u007f,
or an int or short number between -128 and 127, then let r1 and r2 be the
results of any two boxing conversions of p. It is always the case that r1 ==
r2."
Zatem implementacja Suna jest zgodna ze specyfikacja.
Odpowiadanie na znaleziony bug we wlasnej implementacji "ale u konkurencji
tez jest bug i to znacznie gorszy" jest samo w sobie kiepskim posunieciem
PRowym. Ale gdy ow "bug u konkurencji" nie jest wcale bugiem lecz poprawnym
zachowaniem, to juz jest malym disasterem PRowym.
A.
--
Wys³ano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/
Waldemar Kot - 19-06-2007 00:06
=?ISO-8859-2?Q?Re:_Bug_boksowania_int=F3w_w_JRoc?= =?ISO-8859-2?Q?kit_[by=B3o:_nested_synchronized]?=
Pewnie gdybym napisa³, ¿e dzisiaj w San Jose jest s³oneczny poniedzia³ek, a w
Santa Clara albo Armonk pada, to te¿ uzna³by¶ to za posuniêcie PR. Trudno,
skoro takie przyj±³e¶ za³o¿enie....
Mi³ego dnia.
Waldek Kot
--
Wys³ano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/
Aleksander Galicki - 19-06-2007 00:06
=?ISO-8859-2?Q?Re:_Bug_boksowania_int=F3w_w_JRoc?= =?ISO-8859-2?Q?kit_[by=B3o:_nested_synchronized]?=
Waldemar Kot <waldemar_kot.WYTNIJ@gazeta.pl> napisa³(a):
> Pewnie gdybym napisa³, ¿e dzisiaj w San Jose jest s³oneczny poniedzia³ek, a
w
> Santa Clara albo Armonk pada, to te¿ uzna³by¶ to za posuniêcie PR. Trudno,
> skoro takie przyj±³e¶ za³o¿enie....
San Jose i Santa Clara to nie sa konkurujace ze soba firmy, jak rowniez nie
jestes ich przedstawicielem.
Tak sie sklada, ze na prawdziwe stwierdzenie ze "w JRockit jest bug"
odpowiedziales nieprawdziwym (doczytales juz java spec?) "a w Sun JDK tez
jest bug, gorszy!". I owszem - jest to mishandling z zakresu PR.
A.
--
Wys³ano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/
Waldemar Kot - 19-06-2007 00:06
=?ISO-8859-2?Q?Re:_Bug_boksowania_int=F3w_w_JRoc?= =?ISO-8859-2?Q?kit_[by=B3o:_nested_synchronized]?=
OK - pope³ni³em b³±d - uciek³ mi int podczas czytania fragmentu specyfikacji,
któr± Piotr przytoczy³. To co s±dzi³em, ¿e jest b³êdem warto¶ci Integer > 127
jest zachowaniem zgodnym ze specyfikacj± (nie by³em ¶wiadomy, ¿e takie
"ograniczenie" istnieje).
Tak jak obieca³em wcze¶niej - b³±d w JRockit 27.2 zosta³ zg³oszony i
potwierdzony. Dam znaæ, jak bêdzie wiadomo co dalej. Ci, którzy maj± kontrakt
supportowy na JRockit (lub inne produkty BEA), mog± w supporcie BEA odwo³aæ
siê do podanego numeru sprawy - CR327690 - i za¿±daæ patch'a.
Pozdrawiam,
Waldek Kot
PS
Przy okazji wysz³o, ¿e JCK nie robi na podan± funkcjonalno¶æ testu. Ma to byæ
zg³oszone do Sun'a, wiêc jest nadzieja, ¿e takie regresje nie bêd± pojawiaæ
siê w przysz³o¶ci i bêd± szybciej wy³apane.
--
Wys³ano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/
zanotowane.pldoc.pisz.plpdf.pisz.pleffulla.pev.pl
|
=?ISO-8859-2?Q?=5Bmysql=5D_synchronizacja_struktury_bazy_?==? ISO-8859-2?Q?lokalnej_ze_zdaln=B1?=
=?iso-8859-2?Q?=5BPostgreSQL=5D_synchronizacja_danych_mi=EAdz y_bazami?=
Uzywa ktos jakiejkolwiek replikacji/synchronizacji danych ?
timing petli synchronicznie 100kHz
synchronizacja danych wielu klientow?
MySql i PostgreSQL - synchronizacja danych
[PostgreSQL] Synchronizacja struktury bazy
[oracle] problem z nested table
Oracle, nested table, jdbc.
Nested Set
zanotowane.pldoc.pisz.plpdf.pisz.plmarcelq.xlx.pl
Cytat
Decede mihi sole - nie zas³aniaj mi s³onca.
Gdy kogo¶ kochasz, jeste¶ jak stworzyciel ¶wiata - na cokolwiek spojrzysz, nabiera to kszta³tu, wype³nia siê barw±, ¶wiat³em. Powietrze przytula siê do ciebie, choæby by³ mróz, a ty masz w sobie tyle rado¶ci, ¿e musisz j± rozdawaæ woko³o, bo siê w tobie nie mie¶ci
Hoc fac - tak czyñ.
A tergo - od ty³u; z ty³u.
I czarne w³osy posiwiej±. Safona |
|
