<html>
<head>
<meta content="text/html; charset=ISO-8859-2"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Sajnos ez sokak elméjében úgy jelenik meg leegyszerűsítve (néhány
kulcs gondolatot "véletlenül" kihagyva), hogy a fejlesztői idő
drága, a RAM olcsó, ergó nem foglalkozik semmivel, az üzemeltetés
majd megoldja, a felhasználó alá teszi a megfelelő vasat.<br>
Sok elnagyolt "részlet" (majdnem mindegy, hogy tervezési vagy
programozási probléma) jelentősen meg tudja növelni az erőforrást
igényt, végül összességében nem néhány GB RAM a kérdés, hanem sok
milliós infrastruktúra, amik folyamatbeli komplexitásokat is
jelentenek, amik növelik a munkaerő szükségletet és az üzleti
kockázatot.<br>
<br>
Talán a felhő korszak majd kicsit rendet tesz ebben, főleg ha maga a
fejlesztő szolgáltat: akkor már nem lesz annyira mindegy, hogy
mennyi hardver szükséges a csodás alkalmazás alá, mert a
versenyképességet rontja.<br>
<br>
<br>
<br>
<div class="moz-cite-prefix">2012.07.25. 13:33 keltezéssel,
<a class="moz-txt-link-abbreviated" href="mailto:istvan.ketler@lhsystems.com">istvan.ketler@lhsystems.com</a> írta:<br>
</div>
<blockquote
cite="mid:186CDF99C3D12A42A1FF430860E5EEBB35A241CA@SW-FRAADS-MBX38.ads.dlh.de"
type="cite">
<meta content="text/html; charset=ISO-8859-2"
http-equiv="Content-Type">
<meta content="text/html; charset=ISO-8859-2"
http-equiv="Content-Type">
<meta content="Microsoft Word 12 (filtered medium)"
name="Generator">
<style><!--
/* Font Definitions */
@font-face
{font-family:Helvetica;
panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.apple-style-span
{mso-style-name:apple-style-span;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:70.85pt 70.85pt 70.85pt 70.85pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
<div>
<div class="WordSection1">
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Ámen.<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Szeretnék
annyit hozzátenni, hogy programozó ne foglalkozzék azzal,
hogy mi a hatékonyabb. A programozó írjon nagyon szép,
olvasható kódot, aztán tesztelje (ha lehet éles adatokkal,
még jobb ha éles környezetben), végezzen méréseket, és
ahol tényleg lassú, ott kezdjen optimalizálni.<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Kikerestem
a vonatkozó részt a kedvenc könyvemből:<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">„...
egy program egyszerű, kézenfekvő megírásával elérjük azt,
hogy helyesen működjön, és a minimumra csökkenjen a
zavarosság veszélye. Ezután teljesítményméréseket
végezhetünk, hogy eldöntsük, elég jól működik-e, és ha
nem, mire kell a figyelmünket összpontosítani. Egy adott
algoritmusnál a sebességet szinte minden esetben csak az
olvashatóság rovására növelhetjük. Csak akkor áldozzuk fel
az áttekinthetőséget a sebességért, ha tudjuk, hogy a
helyes feladatot oldjuk meg helyesen és tudjuk, hogy ez
megéri az áldozatot.”<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">A
könyvet, amiből idéztem, Kernighan írta (Plauger a
szerzőtárs) 1976-ban (!), és hihetetlenül modern, mind a
mai napig érvényes elveket mutat be gyakorlati példákon
keresztül (külön érdekesség, hogy „Ratfor” nyelvet használ
ehhez, ami a Fortran C-sített változata – csaknem olyan,
mintha régi C kódot olvasnál). Csak az azóta eltelt időben
objektum orientált, code reuse, test driven development,
és más hasonló egzotikus állatneveket aggattunk ezekre az
elvekre...<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Kernighan-Plauger:
Software Tools (1976)<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">„A
programozás magasiskolája” címmel a műszaki könyvkiadó
kiadta a fordítását magyarul 1982-ben. A mai napig hálás
vagyok a sorsnak, hogy annak idején zöldfülű kezdőként
megvettem és nagy figyelemmel kiolvastam (és
feldolgoztam). Szerintem kezdőknek a mai napig érdemes
használni (mint ahogy a Unixot és származékait is, amik
pedig kortársai a könyvnek – csak a Unixok azóta
fejlődtek, de ezek az elvek alig változtak, legfeljebb
lett még néhány belőlük).<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Az
idő előtti optimalizálás pedig minden rossz gyökere ezen a
Földön... :)<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Üdvözlettel,<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Iván<o:p></o:p></span></p>
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><b><span
style="font-size:9.0pt;font-family:"Arial","sans-serif";color:#999999">István
Ketler<br>
</span></b><span
style="font-size:9.0pt;font-family:"Arial","sans-serif";color:#999999">Senior
Consultant</span><span style="color:#1F497D"><o:p></o:p></span></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span
style="font-size:8.0pt;font-family:"Arial","sans-serif";color:#999999">Lufthansa
Systems Hungaria Kft.
<br>
Development Center Pest <br>
Neumann János u. 1/e<br>
1117 Budapest<br>
Hungary <o:p></o:p></span></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span
style="font-size:8.0pt;font-family:"Arial","sans-serif";color:#999999">Tel:
+36 1 887-2815
<br>
Fax: +36 1 887-2977<br>
Mobile: +36 30 600-4936 </span><span
style="color:#1F497D"><o:p></o:p></span></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span
style="font-size:8.0pt;font-family:"Arial","sans-serif";color:#999999">Room:
Infopark E, Room LH2-24
</span><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:8.0pt;font-family:"Arial","sans-serif";color:#999999">e-mail:
<a moz-do-not-send="true"
href="mailto:istvan.ketler@lhsystems.com">istvan.ketler@lhsystems.com</a>
<br>
Internet: <a moz-do-not-send="true"
href="http://www.lhsystems.hu/">www.LHsystems.hu</a></span><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<div>
</div>
</div>
</div>
<div>
<p class="MsoNormal" style="MARGIN: 0cm 0cm 0pt"> </p>
<p class="MsoNormal" style="MARGIN: 0cm 0cm 0pt"><span
style="FONT-SIZE: 8pt; COLOR: gray; FONT-FAMILY: Arial">Sitz
der Gesellschaft / Corporate Headquarters: </span><span
style="FONT-SIZE: 8pt; COLOR: gray; FONT-FAMILY: Arial;
mso-ansi-language: EN-GB" lang="EN-GB">Lufthansa Systems
Hungaria Kft, Budapest, Fövarosi Birosag 01-09-463417<br>
</span><span style="FONT-SIZE: 8pt; COLOR: gray; FONT-FAMILY:
Arial">Geschaeftsfuehrung / Management Board: Monika Houck</span></p>
<p class="MsoNormal" style="MARGIN: 0cm 0cm 0pt"><br>
</p>
<div class="WordSection1">
<div>
<div style="border:none;border-top:solid #B5C4DF
1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span
style="font-size:10.0pt;font-family:"Tahoma","sans-serif""
lang="EN-US">From:</span></b><span
style="font-size:10.0pt;font-family:"Tahoma","sans-serif""
lang="EN-US"> <a class="moz-txt-link-abbreviated" href="mailto:javalist-bounces@lists.javaforum.hu">javalist-bounces@lists.javaforum.hu</a>
[<a class="moz-txt-link-freetext" href="mailto:javalist-bounces@lists.javaforum.hu">mailto:javalist-bounces@lists.javaforum.hu</a>]
<b>On Behalf Of </b>Peter Verhas<br>
<b>Sent:</b> Wednesday, July 25, 2012 12:23 PM<br>
<b>To:</b> Java lista<br>
<b>Subject:</b> Re: [Javalist] Segítség! Java7
compiler BUG???<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Mesélni nem szeretek, illetve igen, de az
a gyereknevelés vagy a csajozás témaköre, ez meg egy szakmai
fórum, ahol a kőkemény tények számítanak. Persze szellemileg
nagyon fel tud frissíteni egy olyan téma, hogy jobb-e
exception-t dobni, vagy inkább null-t visszaadni egy
metódusból amennyiben abból a szempontból vizsgáljuk meg,
hogy melyik eredményez a hívó oldalon olvashatóbb kódot. Ez
mindaddig szubjektív, amíg nem végzünk mérést sok átlagos
programozón, definiált metrikával, ami méri, hogy mennyire
olvasható a kód. Gyakorlatilag ez kivitelezhetetlen, ezért
ilyenkor a common sense dönt; illetve az idő, ami éveket
jelent. Idővel kiderül, hogy mi a jó, mi a rossz, és sok
minden marad azon a mezsgyén, amire a legmegfelelőbb szó a
"megfelelő".<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Tipikusan például ilyen a singleton.
Baromi jól el lehet vitázni, hogy a singleton pattern,
vagy antipattern (talán erről is írok majd egy
blogbejegyzést, meg ezekből a hosszabb levelekből is), de
leginkább azt lehet mondani, hogy nem rossz. Megfelelő.
Arra amire.<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">A tények azonban makacs dolgok, és ha
mégoly szép kódot is eredményez egy programozási
módszertan, ha használhatatlan a kód, ami az alapján
készül, akkor az nem egy jó pattern (ezt írtam az előző
levelemben is, kedves néném...) Anno ezen halt el az
Algol60 meg az Algol68 is: nem volt olyan gép, ami le
tudta volna fordítani gyorsan és jól: maradt a FORTRAN a
kor kódolóinak.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Az a mondás, hogy ne dobjunk
Exception-t, mert az lassú überel mindent. Hiába lesz
szép és olvasható a kód ha egy null-t visszaadó metódus
1000-szer gyorsabb, mint egy olyan, amelyik egy 'new
Exception()' -t dob. (kb. ez az arány, beleértve a
try/catch kezelést is, olyan metódusoknál, amelyek
egyébként nem csinálnak semmit).<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Konkrétan csak egy 'return null'-t
visszaadó metódust tíz milliószor meghívva 12ms alatt
végez a gépem, míg ugyanennyiszer egy olyat, ami egy
Exception-t dob 23ms-ig is eltart. Hogyan?<o:p></o:p></p>
</div>
<div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">VIGYÁZAT CSALOK!<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Ha minden egyes alkalommal új
Exception-t hozok létre, akkor ez az érték már
11000ms, majdnem ezerszer lassabb. De ha ugyanazt az
Exception-t dobálom?<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Ez azt mutatja, hogy teljesítmény
szempontjából nem az a kérdés, hogy null-t adjak-e
vissza, vagy kivétel dobásával jelezzem a speciális
visszatérési értéket, hanem azt, hogy nem feltétlenül
kell minden egyes esetben új Exception objektumot
létrehozni.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Persze azt is tudni kell, hogy
ilyen esetben az exception objektum stack trace része
használhatatlan, hiszen nem azt fogja tartalmazni ahol
akkor járt a program, amikor el lett dobva, hanem azt
amikor és ahol létre lett hozva. A kérdés az, hogy
kell-e nekünk a stack trace?<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Ha olyan exception-t dobunk,
amelyik kivételes esetet jelez, tipikusan emberi
beavatkozást fog igényelni, meg kell hogy jelenjen a
log-ban a stack trace, hogy lehessen tudni, hogy
honnan lett dobva, akkor létre kell hozni egy új
exception objektumot, tipikusan a szokásos<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">throw new Exception()<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">pattern szerint. Amikor ezt tesszük
a programnak már úgyis betették a kaput, a
teljesítménynek nem számít, hogy a szerver X+12ms vagy
X+12mp alatt áll le (itt X az az idő ami még ezen
kívül kell a leálláshoz).<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Ha viszont olyan kivételt dobunk,
ami nem különleges helyzet, csak jelezni akarjuk
például, hogy nincs több adat, vagy nincs keresett
adat, akkor (ha egyébként ez megfelel az ízlésünknek,
és minden egyéb feltételnek) csak a teljesítmény
szempontokat figyelembe véve dobhatunk egy private
static final változóban tárolt exception-t. A metódus
futási idejének csak kis része lesz (mondjuk 1%-a) a
visszatérés maga, így ha ez kétszer annyi időt vesz
igénybe a hívó oldalon, akkor fél százalékkal nőtt a
metódus bruttó futási ideje (bruttó alatt a hívási
oldali költségeket is figyelembe vesszük,
try/catch/finally és társai).<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Ez tehát nem támasztja alá, hogy ne
dobjunk exception-t nem kivételes helyzetben. Kicsit
lassabb, de elviselhető. Ezzel némileg ellentmondok az
Effective Java könyvnek, de nem lehet vele vitázni,
mert csak annyit ír, hogy "egy száz elemű tömbnél az
én gépemen kétszer annyi ideig tart". Ez nem precíz.
Hidd el neki. Vagy ne hidd el, hanem mérd meg! Én erre
az utóbbira szavazok: a konkrét méréseket, meg kódot
majd felrakom a blogra, és továbbra is folyhat arról a
vita, hogy melyik a szebb pattern: null-t visszaadni,
vagy exception-t dobni (és persze van egy harmadik
pattern is, ami azt mondja, hogy legyen hasNext()
kinézetű metódus).<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<div>
<div>
<p class="MsoNormal"><span
class="apple-style-span"><span
style="font-size:13.5pt;font-family:"Helvetica","sans-serif";color:#888888">--</span></span><span
style="font-size:13.5pt;font-family:"Helvetica","sans-serif";color:#888888"><br>
<span class="apple-style-span">Verhás
Péter</span><br>
<span class="apple-style-span"><a
moz-do-not-send="true"
href="mailto:peter@verhas.com">peter@verhas.com</a></span><br>
<span class="apple-style-span">+36(30)9306805</span><br>
<span class="apple-style-span">skype:
verhas</span></span><span
style="font-size:13.5pt;font-family:"Helvetica","sans-serif";color:black"><o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><span
style="font-size:13.5pt;font-family:"Helvetica","sans-serif";color:black"><o:p> </o:p></span></p>
</div>
<p class="MsoNormal"><span
style="font-size:13.5pt;font-family:"Helvetica","sans-serif";color:black"><br>
<br>
</span><o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">On 2012.07.25., at 10:50,
István Székely wrote:<o:p></o:p></p>
</div>
<p class="MsoNormal"><br>
<br>
<o:p></o:p></p>
<div>
<p class="MsoNormal">Sziasztok!<br>
<br>
Péter, erről légy szíves mesélj, mert úgy érzem,
lemaradtam valamiről.<br>
<br>
A kivételkezelés Javaban is lassú (volt?). Ennek
oka pontosan a stack trace összeállítása. A
hívási lánc bejárása és a stack trace
összeállítása igen drága művelet. Pont ebből az
okból javasolja Joshua Bloch is, hogy
kivételkezelést ne használjunk vezérlési
szerkezetek helyett. Emiatt nem jó az sem, hogy
az említett JPA metódus is kivételt dob null
visszaadása helyett (persze emellett is lehet
érvelni, és hajlamos is vagyok elfogadni, de az
most más téma).<br>
<br>
Ahonnan van: Effective Java, 2nd ed<br>
Item 57: Use exceptions only for exceptional
conditions<br>
<br>
Üdv,<br>
Stivi<br>
<br>
<br>
On 2012-07-24 23:26, Peter Verhas wrote:<br>
<br>
<o:p></o:p></p>
<p class="MsoNormal">Technológiai okok miatt C++
és C# (általánosan .NET) környezetben nem
szeretünk exception-t dobni (én magam
programozni sem szeretek ezekben a
környezetekben, nem is tudok (nagyon), hát még
kivételt dobni). Ezekben a környezetekben a
kivétel dobása drága, egészen más a kivételek
szerkezete, és ezért nem is ad megfelelő
információt. Tipikusan nincs benne a stack
trace, ezért ha egy szinttel feljebb, mint
ahonnan dobták nem kapjuk el, akkor már nem is
lehet tudni, hogy honnan dobták. Akkor meg már
olcsóbb futási időben a megfelelő hibakód
visszaadása, és ennek nagy hagyománya van unix C
és Windows C programozási környezetben, régen
bevált. [Megjegyzés: ennek a bekezdésnek az
egyik fele nem első kézből való információ, csak
beszélgettem .NET-es kollégákkal. A másik fele
viszont ezer évvel ezelőtti C programozási
emlékek megmaradt halvány foszlányai.]<o:p></o:p></p>
<blockquote
style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal"><o:p> </o:p></p>
</blockquote>
<blockquote
style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal">A Java egészen más.
Java-ban az exception hordozza a stack trace-t
(vagy nem, de inkább igen, mint nem), és ebben
nagyon sok szimbolikus információ benne van.
Nem kell ott elkapni, ahol dobják, vagy egy
szinttel feljebb, mert minden szükséges
információ benne van, és ezért elég ha ott
kapjuk el, ahol kezelni tudjuk. Ezért lett
egyébként kitalálva a hiba dobás, és
véleményem szerint a .NET környezet az
exception dobás, mint pattern
funkcionalitásának egy részét feláldozta a
teljesítmény oltárán, amit viszont mostanra
(Java6, 7) kezd túlhaladni az idő.<o:p></o:p></p>
</blockquote>
<blockquote
style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal"><o:p> </o:p></p>
</blockquote>
<p class="MsoNormal"><br>
_______________________________________________<br>
Javalist mailing list<br>
<a moz-do-not-send="true"
href="mailto:Javalist@lists.javaforum.hu">Javalist@lists.javaforum.hu</a><br>
<a moz-do-not-send="true"
href="http://lists.javaforum.hu/mailman/listinfo/javalist">http://lists.javaforum.hu/mailman/listinfo/javalist</a><o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</div>
</div>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Javalist mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Javalist@lists.javaforum.hu">Javalist@lists.javaforum.hu</a>
<a class="moz-txt-link-freetext" href="http://lists.javaforum.hu/mailman/listinfo/javalist">http://lists.javaforum.hu/mailman/listinfo/javalist</a>
</pre>
</blockquote>
<br>
<br>
</body>
</html>