RE: NIO2 v JRE7 chybí?!

[Holý Jiří]

Kolegové mě kdysi naučili tomu říkat „papírový kamarád“. Stačí někoho požádat, 
aby se vám podíval přes rameno, na něco se ho zeptáte a v tu chvíli je jasná 
odpověď i vám :-) A proč papírový kamarád? Vypadá to divně, ale zkuste si 
vytisknout třeba Dilberta, nebo někoho podobného, přilepit na monitor a ptát se 
jeho - funguje jako takový katalyzátor úplně stejně a často „odpoví“ :-)

S pozdravem
Jiří Holý

From: konference-boun...@java.cz [mailto:konference-boun...@java.cz] On Behalf 
Of Libor Jelinek
Sent: Friday, March 25, 2011 8:24 AM
To: Java
Subject: Re: NIO2 v JRE7 chybí?!

To víte :-) Často mi pomůže se zeptat a při tázání zjistím, že na to vlastně 
umím odpovědět sám. Ale to už je mail odeslán :-)

Přesto děkuju panu Hubálkovi, že mě navedl i že mě že jste mě naučili, 
procházet zdrojáky OpenJDK :-)

Hezký den všem!
Libor
Dne 25. března 2011 7:31 Vladimir Balaz 
mailto:bal...@zoznam.sk>> napsal(a):
Nič na tom nie je, len by sa podľa toho dalo čakať, že na položenú otázku 
odpoviete skôr vy niekomu inému ako naopak.  :-)


On 24. 3. 2011 17:50, Libor Jelinek wrote:
Jenoduše protože mě jsem zvědavý a chci mít "prst na tepu doby". Učím se, hraju 
si. Nepíšu prozatím žádné mission-critical aplikace. Odebírám jd7-nio2-dev 
newsletter, čtu bugzillu a testuju NIO2, ...

NIO2 se mi prostě líbí a baví mě sledovat "za živa" vývoj tého části JDK7. Na 
tom přece není nic špatného.

Libor
Dne 24. března 2011 17:41 Tomas Hubalek 
mailto:tomas.huba...@onsemi.com>> napsal(a):
A proc vlastne pouzivate tak bleeding edge verzi? V dokumentaci je napsano, ze 
se signatury muzou menit, takze to klidne muzete predelavat jeste mesice.

Tom

From: Libor Jelinek [mailto:ljeli...@virtage.com]
Sent: Thursday, March 24, 2011 9:40 AM
To: Java
Cc: Tomas Hubalek
Subject: Re: NIO2 v JRE7 chybí?!

Právě že nejsou. Teď, když se umím (na základě rady od někoho zde) podívat na 
diff Paths.java na 
http://hg.openjdk.java.net/jdk7/jdk7/jdk/diff/236e3f2d0a6b/src/share/classes/java/nio/file/Paths.javam,
 tak zjišťuju, že došlo v nejnovějším sestavení build-134 k odebrání mnou 
použité signatury

Paths.get(String)

Při kompilaci jsem měl starší build, kde ještě takto vypadající metoda 
existuje. Tím se všechno vysvětluje.

I tak díky za pomoc!
Libor
Dne 24. března 2011 17:27 Tomas Hubalek 
mailto:tomas.huba...@onsemi.com>> napsal(a):
A jsou to JRE a JDK v uplne stejne verzi (vcetne cisla buildu na konci)?

Tom

From: konference-boun...@java.cz 
[mailto:konference-boun...@java.cz] On 
Behalf Of Libor Jelinek
Sent: Thursday, March 24, 2011 9:17 AM
To: Java
Subject: NIO2 v JRE7 chybí?!

Dobrý den,
nelaboroval jste už někdo s NIO 2 natolik, že byste narazili na nepřítomnost 
NIO2 některých tříd v JRE, které v JDK ale jsou?

Např. první na co jsem narazil je třída Paths. Zkompiloval jsem si aplikace v 
JDK7, když ji chci spustit na JRE7 tak:

Exception in thread "main" java.lang.NoSuchMethodError: java.nio.file.Paths.get(
Ljava/lang/String;)Ljava/nio/file/Path;
at cron4jscheduler.SchedulerLauncher.main(SchedulerLauncher.java:72)

Samozřejmě to může být nějaká má kravina, ale abych to zjistil mě nenapadá nic, 
než projít dostupné třídy JVM pomocí VisualVM. Jenže to vyžaduje JDK. Když ho 
nainstaluju žádnou chybu NoSuchMethodError už mít nebudu.

Druhá možnost k zjištění, zda je či není přítomná třída pro JVM by asi byla 
Reflection API, které ovšem neovládám.

Nenapadá Vás něco pro první problém i druhou otázku? Díky za vše.

Libor




__ Informacia od ESET Smart Security, verzia databazy 5983 (20110324) 
__

Tuto spravu preveril ESET Smart Security.

http://www.eset.sk



Upozornění společnosti OKsystem s.r.o. s ohledem na zavedené standardy ISO 
9001, ISO 27001 a ISO 14001:
Tato zpráva a všechny připojené soubory jsou dle obchodního zákoníku důvěrné. 
Jestliže nejste zamýšleným adresátem, uvědomte prosím odesilatele a smažte 
zprávu i přiložené soubory.
Opravdu potřebujete vytisknout tento email? Myslete na přírodu.

Disclaimer of OKsystem s.r.o. with respect to implemented standards ISO 9001, 
ISO 27001 and ISO 14001:
This message and all attached files are confidential and legally privileged. If 
you are not the intended recipient, please notify the sender and delete the 
message including all attachments.
Please consider the environment before printing this email.

RE: Hibernate - foreign ID versus

[Holý Jiří]

Jen doplním - lazy přístup je fajn, pokud s tou entitou pracujete v rámci 
jednoho .. nevím jak to nazvat, pravděpodobně kontextu/transakce. Pokud ji 
posíláte dál, třeba serializací, tak se dostanete do situace, kterou popisoval 
Zdeněk Troníček - tedy je potřeba dát pozor i na použití.

S pozdravem
Jiří Holý

-Original Message-
From: konference-boun...@java.cz [mailto:konference-boun...@java.cz] On Behalf 
Of Vladimir Dvorak
Sent: Friday, July 15, 2011 2:12 PM
To: Java
Subject: Re: Hibernate - foreign ID versus

   U vsech OneToOne/ManyToOne pouzivame dusledne Lazy fetch, takze dotahujeme 
jen to co potrebujeme


On 07/15/2011 12:51 PM, "Zdeněk Troníček" wrote:
> Dobrý den,
>
> já na použití foreign ID nevidím nic špatného.
> Naproti tomu nadměrné používání asociací (OneToMany, ManyToOne,...) vede k
> problémům, protože je pak propojeno všechno se vším. A může se stát, že
> vyčtením jedné entity vyčtete půlku databáze.
> Tj. asociace ano, ale s mírou.
>
> Z.T.


Upozornění společnosti OKsystem s.r.o. s ohledem na zavedené standardy ISO 
9001, ISO 27001 a ISO 14001:
Tato zpráva a všechny připojené soubory jsou dle obchodního zákoníku důvěrné. 
Jestliže nejste zamýšleným adresátem, uvědomte prosím odesilatele a smažte 
zprávu i přiložené soubory.
Opravdu potřebujete vytisknout tento email? Myslete na přírodu.

Disclaimer of OKsystem s.r.o. with respect to implemented standards ISO 9001, 
ISO 27001 and ISO 14001:
This message and all attached files are confidential and legally privileged. If 
you are not the intended recipient, please notify the sender and delete the 
message including all attachments.
Please consider the environment before printing this email.

RE: viac monitorow (Was: OT: hardware)

[Holý Jiří]

> Čistě mimochodem: už se Eclipse naučil vytáhnout nějaký panel a pustit jej 
> vedle v samostatném okně? Tato neschopnost byla jedním z důvodů, proč jsem od 
> něj kdysi přešel k NetBeans.

Snad kromě editoru lze každý panel vytáhnout ven jako nástrojové okénko. 
Zajímavé je také drag n drop záložky v editoru, kdy přetažením můžete udělat 
split-screen. Za zmínku stojí i první dvě položky v menu Window (New Window a 
New Editor), vyzkoušení nechám na vás ;)

S pozdravem
Jiří Holý

From: konference-boun...@java.cz [mailto:konference-boun...@java.cz] On Behalf 
Of Pecinovský Rudolf
Sent: Monday, August 15, 2011 1:38 PM
To: Java
Subject: RE: viac monitorow (Was: OT: hardware)

>  Ako pouzivate viac monitorov vy?

Když jsem dělal na stolním počítači, používal jsem 3 monitory a bylo to 
optimální. Na jednom jsem psal, na druhém běžel program, o kterém (resp. který) 
jsem psal a na třetím různé systémové věci – např. pošta.

Teď na notebooku používám jen dva, protože na víc nemá (USB monitor jsem 
nezkoušel), a když jednou za čas musím s počítačem někam odjet, jsem z toho 
chybějícího monitoru docela nesvůj.

Vynikající je to při ladění programů, kdy si mohu na druhý monitor vytáhnout 
panel zobrazující standardní výstup a obsah proměnných, takže mi nezaclánějí na 
monitoru, kde mám rozdělané programy. (Čistě mimochodem: už se Eclipse naučil 
vytáhnout nějaký panel a pustit jej vedle v samostatném okně? Tato neschopnost 
byla jedním z důvodů, proč jsem od něj kdysi přešel k NetBeans.)

Dva monitory se hodí i při přednáškách: na notebooku mám to, co chci vidět já, 
na druhém pak to, co jde do projektoru a mají to vidět i ostatní. Divím se 
jenom, proč tento mechanizmus používá tak málo přednášejících.




Upozornění společnosti OKsystem s.r.o. s ohledem na zavedené standardy ISO 
9001, ISO 27001 a ISO 14001:
Tato zpráva a všechny připojené soubory jsou dle obchodního zákoníku důvěrné. 
Jestliže nejste zamýšleným adresátem, uvědomte prosím odesilatele a smažte 
zprávu i přiložené soubory.
Opravdu potřebujete vytisknout tento email? Myslete na přírodu.

Disclaimer of OKsystem s.r.o. with respect to implemented standards ISO 9001, 
ISO 27001 and ISO 14001:
This message and all attached files are confidential and legally privileged. If 
you are not the intended recipient, please notify the sender and delete the 
message including all attachments.
Please consider the environment before printing this email.

RE: Swing a uvolnovani Window

[Holý Jiří]

Byl bych v těch tvrzení trochu opatrnější, co třeba takové:

Thread th = new Thread(new SomeRunnable());
th.start();
th = null; //timhle bych vlakno rozhodne zastavit nechtel


On je rozdil v tom, nastavit pointer na null a vykonat na objektu nejakou 
operaci (třeba to finalize).

Jiri Holy

-Original Message-
From: konference-boun...@java.cz [mailto:konference-boun...@java.cz] On Behalf 
Of Ondra Medek
Sent: Tuesday, January 26, 2010 4:43 PM
To: Java
Subject: Re: Swing a uvolnovani Window

Hmm, tak to soudruzi v Sunu zase neco vydumali. Kdyz udelam

window.setVisible(false);
window = null;

Tak objekt v pameti furt visi. To nepovazuji za stastne reseni. Priste
abych u kazde tridy louskal manual, jestli nahodou nema specialni
metodu, kterou musim volat, nez objekt prestanu pouzivat. Co kdyby
neco podobneho bylo treba u kazde JComponent? To bychom se z toho asi
pos.


2010/1/26 Filip Jirsák :
> Zdravím,
> setVisible(false) okno nezavírá, ale pouze skryje. Pokud chcete okno zavřít,
> použijte dispose() - přesně jak píšete. Memory leak to je, ale ne na straně
> Swingu, ale na straně programátora, který okno skrývá když jej ve
> skutečnosti chce zavřít...
>
> S pozdravem
>
> Filip Jirsák
>
>
> Dne 26. ledna 2010 15:39 Ondra Medek  napsal(a):
>>
>> Ahoj,
>>
>> narazil jsem na divne chovani Swingu (AWT). Kdyz zmizim JFrame pomoci
>> setVisible(false), tak v pameti zustane viset pres nejaky seznam
>> java.awt.Window.allWindows. Tedy memory leak. Musim volat
>> JFrame.dispose(). Stejne u JDialog. Vzhledem k tomu, ze default close
>> operation u JDialog je HIDE_ON_CLOSE, pak vsechen kod typu
>>
>> MyDialog().setVisible(true);
>>
>> je memory leak, musim delat
>>
>> JDialog d = MyDialog().setVisible(true);
>> d.dispose();
>>
>> anebo nastavit v MyDialog() construktoru
>> setDefaultCloseOperation(WindowConstants.DISPOSE_ON_CLOSE);
>>
>> Tak nevim, je to Java (SUN JRE 1.6) bug? Pokud je to ocekavane
>> chovani, proc neni java.awt.Window.finalize(), ktera by po sobe
>> uklidila? Koukam, ze v Java 5 jeste tato metoda je vyuzita, viz:
>>
>>
>> http://java.sun.com/j2se/1.5.0/docs/api/java/awt/Window.html#finalize%28%29
>>
>> ale v Java 6 chybi.
>>
>> Dik
>> Ondra Medek
>
>



-- 
Ondra Medek

RE: spring-jdbc a transakcie

[Holý Jiří]

Prominte mi muj hloupy dotaz, ale jsem docela zvedavy - mohl by jste se vice 
rozepsat o zpusobu, jakym chcete onu aplikaci realizovat? Rozhodne nejsem 
odbornik na desktopove aplikace, nicmene zakladni oddeleni vrstev by mělo byt 
vice nez podobne ee. Takhle to na me pusobi, ze chcete mit otevrenou transakci 
dejme tomu pro cely zivotni cyklus nejakeho dialogu - od otevreni a nacteni 
udaju do nej, během práce s nim, az po ulozeni ...

Jiri Holy

-Original Message-
From: konference-boun...@java.cz [mailto:konference-boun...@java.cz] On Behalf 
Of Dusan Msk
Sent: Tuesday, February 16, 2010 5:27 PM
To: Java
Subject: Re: spring-jdbc a transakcie

Urcite precitam.

Aby som nebol za uplneho rebela, popisem asi moju situaciu.

V mojom pripade sa nejedna o ee aplikaciu, ale o desktop aplikaciu. Ta
drzi prave jedno spojenie do databazy uz od main() a na zaver dava
commit a close(). Vsetky operacie mimo main bezia v neznamom poradi,
prevazne su to obsluhy uzivatelskej interakcie. Takze cele je to bud
vsetko, alebo nic. Prave preto nemozem rozumne pouzit @transactional a
moc sa mi ani nechce babrat s xml konfiguraciou springu. V pripade ee
je samozrejme situacia uplne ina.

Pouzijem singleconnectiondatasource, diky.

2010/2/16, Roman Pichlík :
> Jeste jsem chtel upozornit, ze pokud budete ty transakce resit, tak
> hned na prvni veci si rozbijete hubu. Ta vec se jmenuje vnorene
> transakce. Jakmile bude chtit rozjet nekde nahore (v business logice)
> transakci a chtit, aby v ni nejake spodni vrstvy pokracovaly, tak se
> vas kod neuveritelne zneprehledni. V pripade tech abstrakci, ktere vam
> ted vadi, se o to vubec nestarate. Mimochodem na tema abstrakci napsal
> Lukas Krecan vyborny clanek
> http://blog.krecan.net/2010/02/02/slava-abstrakci/ ten bych vam taky
> doporucoval precist ;-).
>
>
> 2010/2/16 Dusan Zatkovsky :
>> On Tuesday 16 of February 2010 16:57:49 Roman Pichlík wrote:
>>
>>> evidentne jste to poradne nepochopil.
>>
>> To je viac ako iste. Asi som stara skola a na pracu s databazou sa pozeram
>> z
>> pohladu tej databazy. Prehnana miera abstrakcie mi v tomto pripade dost
>> znacne vadi v pochopeni danej temy.
>>
>>> Zkuste si udelat jednoduchy
>>> priklad rizeni transakci pomoci anotaci a potom pomoci kodu obe ve
>>> Springu. Rozhodne tam nebudete mit tuny balastu v podobe XML. To XML
>>> se vem vejde do deseti radku to se klidne vsadim ;-).
>>
>> Urcite to tak spravim akonahle zostane trocha casu.
>>
>>
>> --
>> Dusan
>>
>
>
>
> --
> S pozdravem Roman "Dagi" Pichlik
>
> /* http://www.sweb.cz/pichlik/ Blog pro kodery */
>

RE: ECLIPSE A RAP

[Holý Jiří]

Neděláte to nahodou jako kombinaci rap + rcp desktop ? Docela by me zajimalo, 
jak narocne muze byt udrzovat obe cilove platformy prave u velkeho projektu.

Jiri Holy

-Original Message-
From: konference-boun...@java.cz [mailto:konference-boun...@java.cz] On Behalf 
Of Michal Nikodím
Sent: Tuesday, March 23, 2010 9:00 AM
To: Java
Subject: Re: ECLIPSE A RAP

Ja ano, delame na tom jednu hodne velkou aplikaci (HRMS - sprava 
lidskych zdroju). Rap ve verzi 1.2.2 (posledni service release) uz je 
dost pouzitelnej. Par hacks tam sice mame (download, upload, sem tam 
uprava layoutu), ale jinak je to hodne mocne.

Nasledny RAP 1.3 ma byt docela revolucni (grid edit, lepsi theme, cele 
na jadre RCP 3.6 atd..).

Predstava, ze delame nas projekt na necem jinem (ExtJS, GWT, nedej boze 
JSF + nejaka taglib apod), tak me jima hruza.

NkD

P.S. Uz jsem tuhle zpravu posilal jednou i se screenshotem a nevim kde 
to zmrzlo. Tak ji po druhe zkusim bez screenshotu.

Dne 22.3.2010 10:59, Ivan Polak napsal(a):
> Ahojte,
>
> bola tu diskusia o Eclipse RCP, tak ja sa spytam na ECLIPSE RAP
> (http://www.eclipse.org/rap/introduction.php). ma niekto s tymto
> skusenosti?
>
> dakujem
>
> Ivan
>
>

java.cz - redakční systém nefunguje?

[Holý Jiří]

Prosím, jsem v tom sám, nebo i na vás redakční systém na java.cz hází chyby, 
když se chcete registrovat popřípadě  zaslat heslo na email?

S pozdravem
Jiří Holý

RE: Jeden beziaci proces

[Holý Jiří]

Flag se musí v db updatovat prostě jinou transakcí. Zároveň se hodí přidat 
timestamp atribut, do kdy je ten zámek aktivní - v praxi pak spuštěný timer 
může ten timestamp updatovat (prodlužovat jeho platnost, aby nedošlo k 
opětovnému spuštění). Podmínkou pro spuštění "nového" timeru je neexistující 
zámek, nebo vyexpirovaný (tj. ošetření případu, že server spadne a zámek 
existuje).

Jiří Holý

From: konference-boun...@java.cz [mailto:konference-boun...@java.cz] On Behalf 
Of Tomas Studva
Sent: Monday, September 06, 2010 1:24 PM
To: Java
Subject: Re: Jeden beziaci proces

Asi myslite explicitny DB zamok. To sa mi nezda celkom idealne, lebo taky zamok 
je viazany na tranzakciu a teda ta by musela byt otvorena po celu dobu. Tomuto 
som sa vyhol, lebo sa neda zarucit dlzka behu toho procesu, v zlom pripade to 
moze bezat aj 30 minut. No na druhej strane, nemam ziadne ine proti :).

Moje riesenie cez flag teda stlpec v tabulke ma inu nevyhodu, ktora je ale 
ovela viacej bolestivejsia. Ked sa restartne server alebo vypadne elektrina 
pocas behu procesu, tak sa flag nezmeni na false.

Dakujem, zvazim to.
2010/9/6 Kamil Podlesak 
mailto:kamil.podle...@gmail.com>>
Dobrý den,

 Zámek v databázi má výhody:
- bude fungovat i v clusteru
- lze ho sledovat administračními nástroji databáze a případně i násilně zrušit

Kamil Podlešák

2010/9/6 Tomas Studva mailto:tstu...@gmail.com>>:
> Dobry den,
> v nasej aplikacii mame periodicky spustany proces. Tento proces je
> schedulovany Jbossom, a moze trvat od niekolko sekund az po niekolko minut.
> Spustany je asi kazde tri minuty. Potrebujem zarucit aby bezal iba 1 na
> celom servery. Momentalne to riesim flagom v databaze, ak je flag true, tak
> proces sa hned ukonci.
>
> Chcem sa spytat, ci nie je aj jednoduchsie riesenie a ako by to bolo s
> implementaciou. Ten zamok naozaj suvisi s datami, teda s databazou a
> aplikaciou. Ako druhe riesenie mi napada lockovat sa na nejakom objekte v
> aplikacii.
>
> Tomas Studva