RE: File.length() a InputStream.available()
Dobry den, no, ten FileInputStream je trochu problematicky, protoze blokovat muze - treba u sitoveho filesystemu. A zalezi na implementaci Javy, v RealTime JVM by urcite FileInputStream.available() mel vracet jen to, co ma skutecne uz v bufferu v pameti, protoze jinak by se mi u RT kritickych metod odezva mohla prodlouzit z mikrosekund, se kterymi pocitam, na desitky az stovky milisekund i u lokalnich filesystemu a to by byl prusvih. V. -Původní zpráva- Od: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] za uživatele Lukáš Zapletal Odesláno: 17. září 2008 14:47 Komu: Java Předmět: Re: File.length() a InputStream.available() To je prispevku :-) Samozrejme ze jsem si to precetl, nez jsem psal na konferenci. Semantiku obou metod znam, ale pochopil jsem ji tak, ze v pripade FileInputStream neni duvod k zadnemu blokovani, takze by mela available vracet velikost souboru. Ona to tak v praxi i dela, a proto jsem se ptal, jestli s tim nema nekdo praktickou zkusenost. Co JRE od Sunu vrati pri volani available nad FileInputStreamem u vetsiho souboru nez je INT_MAX. Mohla by napriklad vratit INT_MAX a po nacteni takoveho mnozstvi znovu - az do konce souboru... to uz spekuluji. LZ
RE: eclipse + subversion
Zdravím, > asi mi to uniklo, ale proč že to nechcete používat řádkového svn klienta? > Všechno je v něm rychlejší a hromadné přidávání souborů taky zvládne v pohodě > - po jednom to dělat nemusíte. Kdysi jsem zkoušel subclipse a to byla taková > katastrofa, že jsem se rychle naučil používat právě příkaz svn a od té doby > je úplně jedno co které IDE podporuje za pluginy. asi mi to uniklo, ale jak jednoduse udelate z commadline vetsi refaktorig, ktery zasahne cca 100 trid movem? Tedy treba split plug-inu nebo naopak presun nejakych trid do spolecne centralni knihovny? Podle mne to znamena jednou zasahovat do kodu a podruhe vypisovat svn mv na vsechny tridy, ktere se presunuly. To bych prave chtel od IDE, abych po refaktoringu mohl jen commitnout a nemusel premyslet nad tim, co se presunulo a kam. Proti command line opravdu nic nemam, a na cruisecontrol serveru si s ni tykam, ale na desktopu ji pouzivam opravdu vyjimecne, protoze i ten checkout delam tak vyjimecne, ze je jednodusi nechat subclipse checkoutnout a naimportovat projekty nez checkoutovat rychle z cmdline a pak rucne doimportovavat projekty z workspace. Pouzivame subclipse cca 2 roky a na zacatku to opravdu katastrofa byla, ale dneska uz ho vubec nevnimame, protoze beha dobre a spolehlive. BTW: Je ta XP metodika, ktera pozaduje aby novy par pracoval na cistem checkoutu tak dulezita? Nestacilo by checkoutovat treba automaticky jednou denne (v noci)? - To nechci delat chytreho, to by me pravdu zajimalo - jestli a jake mate zkusenosti s tim, kdyz par prevezme po predchozim paru jejich workspace... V.
equals a hashCode (WAS: java.security.Permission)
Zdravim. Doporucuji precist si knizku od pana Blocha (cesky Java efektivne, anglicky Effective Java). Pan Bloch tuto problematiku rozebira pomerne podrobne a myslim, ze tohle patri k zakladnim znalostem, bez kterych dobry Java kod proste psat nebudete. Jedna se totiz o to, ze predefinovani metody equals nebo hashCode vas zavazuje k dodrzeni urcitych pravidel, bez kterych vam treba Collections budou chodit _velmi_ divne nebo vubec. Samozrejme je mozne nadefinovat hashCode a equals implementovat jen jako porovnani hashCode, to ovsem casto neni to, co chcete. Vetsinou jdete obracene – nejak si urcite, kdy maji byt dve instance nejake tridy rovne a to naimplementujete. Napriklad budete mozna chtit aby dve ruzne instance tridy mujBigInt, reprezentujici cislo 37, vratily na equals true, ale reprezentace cisla 37 a cisla 56498765654987984632159789 by na equals true vratit nemela. Pak Vas ovsem hashCode zavazuje, aby equals instance vracely stejny hashCode, ale nijak Vas nenuti, aby pro dve instance, ktere equals nejsou byly hashCode ruzne. A zrovna u mujBigIntu hashCode tak, aby pro kazda dve nonequals cisla vratil ruzne hashe, proste nevymyslite. Dalsi vec je, ze kod, kde equals je implementovano jako porovnani hashi, nebude zrovna moc citelny... Toz tak, hodne stesti V. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kamzik-II Sent: 27. července 2006 12:49 To: Java Subject: Re: java.security.Permission Ale paklize by tohle vzdy platilo, pak by byla uplna blbost predefinovat metodu equals, protoze by v ni stacilo porovnavat hascode, kdezto v rodicovske implementaci se porovnavaji pouze instance. - Original Message - From: Richard Malaschitz To: Java Sent: Thursday, July 27, 2006 10:58 AM Subject: Re: java.security.Permission A este si treba pozriet Javadoc k samotnemu objektu java.lang.Object. Tam sa pise o metode hashCode(), ze musi byt implementovana tak aby dva objekty, ktore su equals() musia mat rovnaky hshCode().
RE: RT Java
Dobry den, asi bych byl schopen neco sehnat, ale materialy ktere mam z velke casti podlehaji nejakym agreementum, podle kterych to nesmim sverit dalsim ocim. Kdybyste to mohl nejak upresnit, co by Vas zajimalo... V. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Veolw Sent: Saturday, May 06, 2006 11:30 AM To: konference@java.cz Subject: RT Java Zdravim, Chtel bych se zeptat jestli nekdo mate nejake materialy o RT Jave? Diky moc ... PS: Google znam ale i presto se ptam ;)
Jeste patterny [WAS: Konstruktory]
Jeste k tem patternum,
Patterny nejsou striktne vazany na javu, jedna se spis
o jakesi standardni konstrukce pouzivane v objektove
orientovanem programovani, stejne dobre pujdou pouzit
i v C++, C# nebo Pythonu. Je to prostredek jak snaze
napsat dobry kod (casto podobne problemy uz nekdo
vyresil lepe, nez kdy budu schopen ja) i k usnadneni
komunikace (je snazsi a pochopitelnejsi rict kolegovi
"udelej z toho singleton" nez "tuhle tridu napis tak,
aby existovala jedina instance a jeji vytvorei bylo v
rezii tridy same". Pro studium patternu bych Vam doporucil
zejmena knihu "Head First Design Patterns", o niz se
tu nedavno diskutovalo, ale je jich vic, napriklad
predmailnikem zminene internetove odkazy.
Co se tovarni metody tyce, je to aternativa k verejnemu
konstruktoru, ktera je nekdy (ne vzdy) vhodnejsi. Jeji
vyhodou je zejmena lepsi kontrola nad vytvarenim objektu.
Jedna se o to, ze trida poskytne public static metodu, ktera vraci
tuto tridu (nebo ji implementovany interface) a skryje (protected
nebo private) konstruktor. Tedy misto
class MyClass() {
public MyClass() {
...
}
}
udelam
class MyClass() {
private MyClass() {
...
}
public static MyClass getInstance() {
MyClass myClass = new MyClass();
...
return myClass;
}
}
Jake to ma vyhody?
- nemusim vzdy vracet novy objekt: u tridy Boolean nestojim o to,
abych mel 1000 ruznych instanci hodnoty TRUE, takze neposkytnu
konstruktor public Boolean(String str), ale poskytnu tovarni metodu
public Boolean getValue(String str) a vratim jednu z jiz hotovych
hodnot Boolean.TRUE nebo Boolean.FALSE
- mohu si provest pre-inicializaci, jak se mi zlibi; v ramci tovarni
metody mohu novy objekt vytvorit az tehdy, kdy se mi to hodi:
class MyClass {
// skryty konstruktor
private MyClass(Param p) {
...
}
// verejna tovarni metoda
public static MyClass getInstance(Param p) {
preinicializace(p);
MyClass retVal = new MyClass(p);
postinicializace(p);
return retVal;
}
...
}
- konstruktor se dle syntaxe jmenuje stejne jako trida a tudiz
jeho jmeno nemuze nest informaci o jeho funkci, coz nekdy muze
byt na skodu; tovarni metoda muze informovat uz svym jmenem
o sve funkci: napr. BigInteger nabizi konstruktory
BigInteger(int bitLength, int certainty, Random rnd)
a BigInteger(int numBits, Random rnd) ktere vytvori BigInteger,
ktery je pravdepodobne prvocislo, prip. nahodne cislo.
Tovarni metody createProbablePrime a createRandom by byly
vhodnejsi - v kodu by bylo jasnejsi, co delaji; srovnejte:
...
BigInteger pPrime = new BigInteger(55, 10, new Random());
...
a
...
BigInteger pPrime = BigInteger.createProbablePrime(55, 10, new Random());
...
- tovarni metoda muze vratit i instanci podtridy,
pokud pro to je duvod; konstruktor vzdy vraci jen
instanci te tridy, ve ktere je napsan:
class URL {
public URL(String str) {
...
}
}
vzdy vrati jen objekt typu URL.
class URL {
public static URL getURL(String str) {
if (zacina(str, "file:")) {
return new FileURL(str);
} else if (zacina(str, "http:")) {
return new WebURL(str);
} ...
}
}
muze vratit instanci ruznych podtrid tridy URL.
Samozrejme to muze mit i nevyhody, napriklad se
tim komplikuje az znemoznuje dedicnost. Kazdopadne
jeste jednou doporucim knihu J.Blocha "Java Efektivne",
viz tez http://www.linuxzone.cz/index.phtml?ids=33&idc=475
kde zrovna factory method je take rozebirana.
Dobrou noc
VN
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Goo GGooo
Sent: Monday, November 21, 2005 11:51 PM
To: Java
Subject: Re: Konstruktory
Diky vsem za vysvetleni!
Ted si jenom nekde nastudovat co je to "tovarni metoda" ;-) Jak se
tomu rika anglicky? Mam k ruce jen knizku "Java in a nutshell", kde
jsem zadnou zminku o "factory method" nenasel.
Goo
RE: Konstruktory
Dobry den, hledejte spise Factory Method pattern :) VN -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Radovana Straube Sent: Tuesday, November 22, 2005 12:08 AM To: Java Subject: Re: Konstruktory Zdravim, to co hladate je Factory pattern. Priklady a popis najdete napr. na tychto strankach: - http://home.earthlink.net/~huston2/dp/patterns.html - http://www.javacamp.org/designPattern/ Radovana Straube
RE: Konstruktory
Dobry den,
pridam se k predchozim odpovedim:
chcete-li kontrolovat parametry konstruktoru,
pak se nejspis muze stat, ze kontrolou neprojdou.
Pak by mozna lepsi nez vyhodit vyjimku mohlo byt
vratit null nebo nejaky NullObject, coz taky
umozni jen tovarni metoda, tedy:
class Autobus extends Bus {
private Autobus(int a, int b) {
super(a);
}
public static Bus Autobus(int a, int b) {
if (checkParams(a,b)) {
return new Autobus(a,b);
} else {
return new NullBus();
return null;
}
}
}
Doporucuju tez knizku pana Blocha " Java efektivne - 57 rad softwaroveho
experta"
VN
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Goo GGooo
Sent: Sunday, November 20, 2005 12:55 PM
To: Java
Subject: Konstruktory
Ahoj vsichni,
uz jsem se pri svem seznamovani s Javou stacil dozvedet ze volani
konstruktoru nadrazene tridy (tedy "super(...)") musi byt v novem
konstruktoru hned jako prvni prikaz. Netusite nekdo jaky to ma duvod?
Ted jsem chtel vytvorit konstruktor ktery by pred zavolanim sveho
super() vykonal validaci parametru, ale tvrde jsem narazil takze
musim pouzit nehezky workaround. Vrta mi hlavou jake tohle omezeni
muze mit duvod...?
Dik
Goo
RE: Volania test metod vs. konstuktor
Vzhledem k tomu, ze u JUnitu stejne neni definovano, v jakem poradi se
testMetody pousti, prislo by mi jako cistsi a citelnejsi si udelat jen jednu
testMetodu a v ni si volat svoje testy, ktere uz nebudou mit prototyp
"public void testBlaBla()". Mnohem lip pak muzu zachazet i se stavem
objektu, pokud ho potrebuju atp.
Metody fail, assertTrue atp. muzete pouzivat vesele dal.
Jedina nevyhoda, kterou ted vidim, je ta, ze pokud ve firme mate metriku na
pocet testu, pak takto vytvarene testy se v ni neprojevi. :)
V.
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf Of Oto Buchta
> Sent: Thursday, August 18, 2005 9:51 AM
> To: Java
> Subject: Re: Volania test metod vs. konstuktor
>
> On Thursday 18 of August 2005 09:01, Horvath Bystrik wrote:
> > Zdravim konferenciu!
> >
> > Mam nasledovny problem. Pri testovani pomocou junit som zistil, ze ak ma
> > trieda odvodena od TestCase viac testXxx metod, tak pred kazdym volanim
> > takejto metody sa vola konstruktor danej triedy, co rezultuje vo
> vytvorenie
> > viacerych instancii triedy TestCase (jej derivatu). Junit zrejme interne
> > pre kazdu testXxx metodu vytvori interne instanciu triedy v ktorej je
> > metoda deklarovana a potom invokuje metodu testXxx. Ocakaval som, ze na
> > jendej instancii TestCase sa invokuju vsetky testXxx metody. Da sa toto
> > chovanie junit-u nejako ovpyvnit?
>
> Nejjednodussi je podivat se do zdrojaku, jestli je tam nejaka properta.
> Ale
> jinak ja pouzivam klasicky single-init design pattern, tedy prazdne
> konstruktory (pouze super(...) ) a
>
> private static boolean first = true;
> public void setUp() {
> if (first) {
>first = false;
>...
> }
> ...
> }
>
> Diky seqencnosti junitu neni treba synchronizovat.
> --
> Oto 'tapik' Buchta, [EMAIL PROTECTED]
> QA Engineer, Systinet Corp,
> http://www.systinet.com
