jdk1.3 vs jdk1.4
14 отговора
770 прегледа
jdk1.3 vs jdk1.4
Zdrasti,
Iskam da vi pitam nqkoj dali znae ima li razlika na nivo bajtkod mejdu jdk1.3 i jdk1.4, ili razlikata e edinstveno v bibliotekite?
Pravq neshto koeto shte trqbva da vyrvi v/u jre1.3, a sym s 1.4.0(vypreki 4000-te byga v nego :-)) i iskam da sym siguren 4e nqma da se nalaga prekompilaciq.
Thanx!
Iskam da vi pitam nqkoj dali znae ima li razlika na nivo bajtkod mejdu jdk1.3 i jdk1.4, ili razlikata e edinstveno v bibliotekite?
Pravq neshto koeto shte trqbva da vyrvi v/u jre1.3, a sym s 1.4.0(vypreki 4000-te byga v nego :-)) i iskam da sym siguren 4e nqma da se nalaga prekompilaciq.
Thanx!
в отговор на silverBullet
#2
Re: jdk1.3 vs jdk1.4
Определено има!
В JDK 1.4+ се поддържат assertions. За тази операция се налага да се добавят и някои нови инструкции в байткода, които не се поддържат от предишните JDK. Поради тази причина, самата версия на клас файл формата е увеличена и verifyer-a на по-стари виртуални машини веднага ще избълват грешка, ако срещнат по-нов клас файл.
..
Все пак, въпреки, че си с JDK 1.4 няма проблем да компилираш съвместими с по-стари JRE класове. Просто, когато компилираш, подавай на javac параметър '-target 1.2'. T.e:
javac -target 1.2 *.class
В JDK 1.4+ се поддържат assertions. За тази операция се налага да се добавят и някои нови инструкции в байткода, които не се поддържат от предишните JDK. Поради тази причина, самата версия на клас файл формата е увеличена и verifyer-a на по-стари виртуални машини веднага ще избълват грешка, ако срещнат по-нов клас файл.
..
Все пак, въпреки, че си с JDK 1.4 няма проблем да компилираш съвместими с по-стари JRE класове. Просто, когато компилираш, подавай на javac параметър '-target 1.2'. T.e:
javac -target 1.2 *.class
Re: jdk1.3 vs jdk1.4
Blagodarq ti mnogo :-).
S javac ne rabotq mnogo direktno(obiknoveno prez ant ili eclipse) i zatova ne se setih za tazi opciq - u4udvashto e kakvo mogat da napravqt stegnatite deadlines s mozyka na 4ovek :-).
Blagodarq ti oshte vednyj !
PS: Vsyshtnost ti izpozvash li gi assertions - az dosega vinagi sym polzval subclasove na RuntimeException za signalizaciq na strukturni greshki.
S javac ne rabotq mnogo direktno(obiknoveno prez ant ili eclipse) i zatova ne se setih za tazi opciq - u4udvashto e kakvo mogat da napravqt stegnatite deadlines s mozyka na 4ovek :-).
Blagodarq ti oshte vednyj !
PS: Vsyshtnost ti izpozvash li gi assertions - az dosega vinagi sym polzval subclasove na RuntimeException za signalizaciq na strukturni greshki.
в отговор на silverBullet
#4
Re: jdk1.3 vs jdk1.4
Не, не използвам assertions. При мен ограниченият са нещата да вървят дори с jdk 1.1.
Re: jdk1.3 vs jdk1.4
Моите съчувствия - значи нямате и swing. Лично аз съм фен на assert-ите. BTW, може да бъда разстрелян в този форум, но препоръчвам и една книга от Microsoft Press - "Как да пишем надеждни програми/Writing a Solid Code". Издаде я на български NiSoft (не знам дали ги има още). Отделен въпрос е че май доста кодери в майкрософт не я четат.
Та в java изполвах следния код преди да се появят в jdk 1.4:
public static void _assert(boolean c, Object info) {
if (DEBUG && !c) {
throw new InternalError("assertion failed: " + info);
}
}
Когато в 1.4 се появиха вградени, ми се наложи да преименувам assert на _assert на десетки хиляди места :-)
Често съм си мислил - най-важното при assert-а в java е, че трябва да се използва за проверка на алгоритми, а не на данни. За прекондиции има NullPointerException,
IllegalStateException, InvalidArgumentException и так дале. Според мен затова в Sun са се колебали чак до версия 1.4. За посткондиции и инварианти няма проблеми, но за входни данни аssert трябва да се използва само при защитаване на модули - когато един exception в runtime
версията би дестабилизирал нещата в крайния продукт, а в крайната версия assert-ите ще са спряни. Примерно отворили сме файл за запис и искаме да го запишем на всяка цена, въпреки че единия аргумент на функцията е некоректен. В този случай по-добре да не се хвърля exception в началото, а
да се сложи assert. Но в този случай аз бих поставил assert в края, а не в началото, защото не бих искал да си изгубя данните дори и в тестовата версия. Проблемът е обаче, че след close-а, спокойно можех да хвърля в края и exception.
Но в интерес на истината това би решило проблема само в рамките на метода. За защитено програмиране панацея няма - трябва да се гледа общата архитектура.
Както и да е - assertite са хубаво нещо и горещо ги препоръчвам. Често съм получавал съвсем основателни предупреждения от тях и съм си спестявал кошмарни дебъгвания. Assert-ите и Throwable-ите са една от причините да обичам java-тa, стига да ги гледа програмистът, а не потребителят.
Та в java изполвах следния код преди да се появят в jdk 1.4:
public static void _assert(boolean c, Object info) {
if (DEBUG && !c) {
throw new InternalError("assertion failed: " + info);
}
}
Когато в 1.4 се появиха вградени, ми се наложи да преименувам assert на _assert на десетки хиляди места :-)
Често съм си мислил - най-важното при assert-а в java е, че трябва да се използва за проверка на алгоритми, а не на данни. За прекондиции има NullPointerException,
IllegalStateException, InvalidArgumentException и так дале. Според мен затова в Sun са се колебали чак до версия 1.4. За посткондиции и инварианти няма проблеми, но за входни данни аssert трябва да се използва само при защитаване на модули - когато един exception в runtime
версията би дестабилизирал нещата в крайния продукт, а в крайната версия assert-ите ще са спряни. Примерно отворили сме файл за запис и искаме да го запишем на всяка цена, въпреки че единия аргумент на функцията е некоректен. В този случай по-добре да не се хвърля exception в началото, а
да се сложи assert. Но в този случай аз бих поставил assert в края, а не в началото, защото не бих искал да си изгубя данните дори и в тестовата версия. Проблемът е обаче, че след close-а, спокойно можех да хвърля в края и exception.
Но в интерес на истината това би решило проблема само в рамките на метода. За защитено програмиране панацея няма - трябва да се гледа общата архитектура.
Както и да е - assertite са хубаво нещо и горещо ги препоръчвам. Често съм получавал съвсем основателни предупреждения от тях и съм си спестявал кошмарни дебъгвания. Assert-ите и Throwable-ите са една от причините да обичам java-тa, стига да ги гледа програмистът, а не потребителят.
в отговор на Koнcтaнтин Cпиpoв
#6
Re: jdk1.3 vs jdk1.4
Ако се пише нещо , което ще работи и на jdk 1.3 би трябва да се избягва assert.
Assert-ите са удобно нещо наистина , и осмислят кода (това е лично мое мнение) макар рядко да ги използвам - винаги бих предпочел да хвърля exception. Да не говорим че при невнимателно използване са предпоставка за грешки от странични ефекти - например
ResultSet rs
...........
assert rs.next();
и т.н.
Трудно ми е обаче да си представя как биха могли да се използват за защита на алгоритмите...може би това е била първоначалната им идея.
А книгата е много хубава - въпреки че е от майкрософт пресс - от един от авторите на excel - препоръчвам я на всеки
Assert-ите са удобно нещо наистина , и осмислят кода (това е лично мое мнение) макар рядко да ги използвам - винаги бих предпочел да хвърля exception. Да не говорим че при невнимателно използване са предпоставка за грешки от странични ефекти - например
ResultSet rs
...........
assert rs.next();
и т.н.
Трудно ми е обаче да си представя как биха могли да се използват за защита на алгоритмите...може би това е била първоначалната им идея.
А книгата е много хубава - въпреки че е от майкрософт пресс - от един от авторите на excel - препоръчвам я на всеки
в отговор на nabludatel
#7
Re: jdk1.3 vs jdk1.4
Здрасти пак :-) Това наистина би бил много интересен код, ако се пусне в release версията :-) Навремето наричахме страничните ефекти на каквото и да е "бонуси".
В твоя пример проблем създават изключени assert-и. Но още по-красиви са проблемите, причинени от *неизключени* такива. Любимият ми е един в kernel-a на старите версии на Windows NT 4, намерен когато майкрософт публикували сорсите на тяхното ТCP/IP за да видят всички колко добре е написано. Много скоро след това се появи една програмка WinNuke, която пращя IP с точно определена контролна сума. По някаква причина един програмист от майкрософт си е мислил, че такъв пакет е невъзможен и се дължи на грешка в извиквания от него метод - съответно сложили инвариантен assert и са забравили да го изключат. Като резултат сценарий - работи си стабилният NT server, гордо обслужва сума ти потребители.
Пристига към него едно миниатюрно IP пакетче (да го наречем "Давид") и о, ужас, Голиат гръмва със син екран :-)
Аз поне разбирам защитеното програмиране като каква да е архитектура, при която случайни грешки "гръмвания" в кода няма да доведат до тотална загуба на данни. От тази гледна точна и assert-ите и exception-ите пречат на защитеното програмиране. Но хвърлянето на assert-и би могло да се изключва за разлика от хвърлянето на exception-и.
Но това опира и до настройки на IDE-тата на всички в екипа, съответно уточняване къде ще бъдат различните версии ако има тестова и не. При нас това е една от причините все още да ползваме "вътрешния" assert, който хвърля RuntimeException или по-скоро Error (забравих) и се изключва със статичен файнал булев флаг на глобално място за дa може още компилатора да отсява assert-натите пасажи. Според мен несъщестествено предимство, но както и да е.
Освен това, ето ти един инвариант, който провярява алгоритъм за икчисляване на корен квадратен, а не входни данни (ако беше в края на mySqrt щеше да е посткондиция, май).
duble b = mySqrt(a);
assert a*a=b
....
Някак си, просто ми изглежда за assert, не мислиш ли? Даже си спомням, че навремето видях в старите сорси на swing коментар от рода на (PENDING... това си е само за assert, но за нещастие такъв няма :-)
В твоя пример проблем създават изключени assert-и. Но още по-красиви са проблемите, причинени от *неизключени* такива. Любимият ми е един в kernel-a на старите версии на Windows NT 4, намерен когато майкрософт публикували сорсите на тяхното ТCP/IP за да видят всички колко добре е написано. Много скоро след това се появи една програмка WinNuke, която пращя IP с точно определена контролна сума. По някаква причина един програмист от майкрософт си е мислил, че такъв пакет е невъзможен и се дължи на грешка в извиквания от него метод - съответно сложили инвариантен assert и са забравили да го изключат. Като резултат сценарий - работи си стабилният NT server, гордо обслужва сума ти потребители.
Пристига към него едно миниатюрно IP пакетче (да го наречем "Давид") и о, ужас, Голиат гръмва със син екран :-)
Аз поне разбирам защитеното програмиране като каква да е архитектура, при която случайни грешки "гръмвания" в кода няма да доведат до тотална загуба на данни. От тази гледна точна и assert-ите и exception-ите пречат на защитеното програмиране. Но хвърлянето на assert-и би могло да се изключва за разлика от хвърлянето на exception-и.
Но това опира и до настройки на IDE-тата на всички в екипа, съответно уточняване къде ще бъдат различните версии ако има тестова и не. При нас това е една от причините все още да ползваме "вътрешния" assert, който хвърля RuntimeException или по-скоро Error (забравих) и се изключва със статичен файнал булев флаг на глобално място за дa може още компилатора да отсява assert-натите пасажи. Според мен несъщестествено предимство, но както и да е.
Освен това, ето ти един инвариант, който провярява алгоритъм за икчисляване на корен квадратен, а не входни данни (ако беше в края на mySqrt щеше да е посткондиция, май).
duble b = mySqrt(a);
assert a*a=b
....
Някак си, просто ми изглежда за assert, не мислиш ли? Даже си спомням, че навремето видях в старите сорси на swing коментар от рода на (PENDING... това си е само за assert, но за нещастие такъв няма :-)
в отговор на Koнcтaнтин Cпиpoв
#8
Re: jdk1.3 vs jdk1.4
Здрасти :),
Давид и Голиат , интересно сравнение :-))...
Напълно съм съгласен за защитеното програмиране , макар че не знам кое е по-важно - да не се загубят данни , или да не се обработват неправилно, но това зависи от спецификата на проекта , екипа и т.н.
Честно казано , assert най-приляга в това инвариантче наистина :-) , става по-смислено някак си ( само май не е ли assert b*b == а;) и хубаво че го има в 1.4. Взех да се замислям да го използвам по-често ...
Между другото, с тези вътрешни ассерт-и по-удобно ли работите отколкото с вградения , или вече имате много разписан код с тях?
Давид и Голиат , интересно сравнение :-))...
Напълно съм съгласен за защитеното програмиране , макар че не знам кое е по-важно - да не се загубят данни , или да не се обработват неправилно, но това зависи от спецификата на проекта , екипа и т.н.
Честно казано , assert най-приляга в това инвариантче наистина :-) , става по-смислено някак си ( само май не е ли assert b*b == а;) и хубаво че го има в 1.4. Взех да се замислям да го използвам по-често ...
Между другото, с тези вътрешни ассерт-и по-удобно ли работите отколкото с вградения , или вече имате много разписан код с тях?
Редактирано от nabludatel на
в отговор на nabludatel
#9
Re: jdk1.3 vs jdk1.4
E, но и моя пример няма да гръмва с assert-ване за 1 (всъщност като се замисля примерът е суперлош, защото за double не е много добра идея да се прави проверка с =.)
Използваме нашите assert-и по инерция - някои среди за разработка искат специална настройка за assert. В момнента поддържаме "старата" версия на проекта и разработваме нова - старата се build-ва със сложни bat файлове - съответно shell скриптове за Linux, a новата - с верига от около стотина навързани йерархично ant скрипта. Тоест и в двата случая преработката на build файловете е тромава - ако не се включи компилиране -source 1.4 опция на компилатора, всичко се обезсмисля - дават се warning-и, а assert-ите се филтрират. Иначе проектът ни е за 1.4 и няма проблем принципно.
Използваме нашите assert-и по инерция - някои среди за разработка искат специална настройка за assert. В момнента поддържаме "старата" версия на проекта и разработваме нова - старата се build-ва със сложни bat файлове - съответно shell скриптове за Linux, a новата - с верига от около стотина навързани йерархично ant скрипта. Тоест и в двата случая преработката на build файловете е тромава - ако не се включи компилиране -source 1.4 опция на компилатора, всичко се обезсмисля - дават се warning-и, а assert-ите се филтрират. Иначе проектът ни е за 1.4 и няма проблем принципно.
в отговор на Koнcтaнтин Cпиpoв
#10
Re: jdk1.3 vs jdk1.4
Zdrasti,
dosta vreme ne bqh se mqrkal tuka maj :-). Kato stana duma za zashtiteno programirane kakvo mislite za zado4niq dialog m/u J.Gosling i A. Hejlsberg na artima.com po vyprosa checked vs unchecked exceptions. Li4no az sym sys s dqdo James ;-) - da si go kajem napravo cenata(vreme i syotvetno pari) za napisvane na edna programa obiknoveno e dosta po-malka ot cenata za poddryjkata j(razshirenie, prisposobqvane kym novi iziskvaniq i t.n.). I smqtam 4e proverqvanite izklu4eniq mogat dosta da pomognat da ne zabravish da proverish nqkakvo vajno uslovie/invariant. A tova 4e nqkoj go myrzi i ostavq prazni catch blokove si e negov problem i samo govori dokolko dyrji na rabotata si(pyk i na sebe si syotvetno). Makar 4e pyk i syvremennite IDE sa dosta naprednali sprqmo 95-a i moje bi C# nqma da strada 4ak tolkova ot lipsata na checked exceptions(primerno IDEA e prosto potresavashto dobra IDE naistina i dobyr primer nakyde vyrvqt integriranite sredi).
A po vyprosa za assert - da syshto namiram 4e izpolzvaneto mu e konceptualno po-4isto i vodi do po-samodokumentirasht se kod, makar 4e syshto ne sym sviknal da gi izpolzvam oshte.
Btw kolko trqbva da e golqm edin proekt 4e da iziskva 100 navyrzani ant scripta :-) - zvu4i mi kato overkill.
dosta vreme ne bqh se mqrkal tuka maj :-). Kato stana duma za zashtiteno programirane kakvo mislite za zado4niq dialog m/u J.Gosling i A. Hejlsberg na artima.com po vyprosa checked vs unchecked exceptions. Li4no az sym sys s dqdo James ;-) - da si go kajem napravo cenata(vreme i syotvetno pari) za napisvane na edna programa obiknoveno e dosta po-malka ot cenata za poddryjkata j(razshirenie, prisposobqvane kym novi iziskvaniq i t.n.). I smqtam 4e proverqvanite izklu4eniq mogat dosta da pomognat da ne zabravish da proverish nqkakvo vajno uslovie/invariant. A tova 4e nqkoj go myrzi i ostavq prazni catch blokove si e negov problem i samo govori dokolko dyrji na rabotata si(pyk i na sebe si syotvetno). Makar 4e pyk i syvremennite IDE sa dosta naprednali sprqmo 95-a i moje bi C# nqma da strada 4ak tolkova ot lipsata na checked exceptions(primerno IDEA e prosto potresavashto dobra IDE naistina i dobyr primer nakyde vyrvqt integriranite sredi).
A po vyprosa za assert - da syshto namiram 4e izpolzvaneto mu e konceptualno po-4isto i vodi do po-samodokumentirasht se kod, makar 4e syshto ne sym sviknal da gi izpolzvam oshte.
Btw kolko trqbva da e golqm edin proekt 4e da iziskva 100 navyrzani ant scripta :-) - zvu4i mi kato overkill.
в отговор на silverBullet
#11
Re: jdk1.3 vs jdk1.4
Mi okolo edin milion linii kod (zasega) i to chistia e pone 50%. Pravili sme go 7 godini. Shte ti pratia listata s direktoriite, tia e mnogoznachitelna :-)
в отговор на silverBullet
#12
Re: jdk1.3 vs jdk1.4
Listat e dosta po-goliam, zashtoto ne sam tsitiral niakoi moduli, na koito imeto e ot konfidentisalen harakter, kakto i build-fiailove, koito ne sa build.xml :-)) No tova e samo zaradi golemia proekt - problemat na tsialata tazi veriga e, che kogato se nalozhi smiana v kontseptsiata na build-a, tezko ti i gorko tsial den :-(
No za naz e vazno, sashtoto problemat beshe da napravim taka builda, che programistite, izpolzvashti platformata ni da prestanat da butat klientski kod v serverskite klasove, ili vikane na DB tier-a direktno ot klienta ili ot web server tier-a, bypass-vaiki serverskata biznes logika - pri serioznata
arhitektura tova e nedopustimo - novata versia prosto shte otkazhe da
se kompilira. Toest eleminirame arhitekturni greshki na nivo build. No beshe *mnogo* trudoemko, dokato go izlislim. :-(
Ne che pak marliacha niama da si ostane pak marliach, no pone shte mranka,
che mu e po-trudno da marlia s tezi build scriptove. :-)
cba/adk/db2install/build.xml
cba/adk/somwizard/build.xml
cba/adk/somwizard/filesystem/client/build.xml
cba/adk/somwizard/filesystem/nmod/build.xml
cba/adk/somwizard/filesystem/root/build.xml
cba/adk/somwizard/filesystem/server/build.xml
cba/adk/somwizard/filesystem/shared/build.xml
cba/adk/somwizard/filesystem/ula/build.xml
cba/adk/studio/build.xml
cba/adk/xmlexport/build.xml
cba/build/ant/build.xml
cba/build/client/build.xml
cba/build/mdk/build.xml
cba/build/mdk/ant/build.xml
cba/build/ula/build.xml
cba/kernel/build.xml
cba/kernel/Client-API/build.xml
cba/kernel/Core-API/build.xml
cba/kernel/Server-API/build.xml
cba/kernel/ULA-API/build.xml
cba/modinstall/build.xml
cba/modinstall/mast/build.xml
cba/modinstall/modsrv/build.xml
cba/modules/build.xml
cba/modules/bugReport/build.xml
cba/modules/bugReport/Client/build.xml
cba/modules/bugReport/Server/build.xml
cba/modules/bugReport/Shared/build.xml
cba/modules/bugReport/ULA/build.xml
cba/modules/Demo/build.xml
cba/modules/Demo/Client/build.xml
cba/modules/Demo/Server/build.xml
cba/modules/Demo/Shared/build.xml
cba/modules/Developer/Studio/Documents/build.xml
cba/modules/Developer/Studio/Documents/Client/build.xml
cba/modules/Developer/Studio/Documents/Server/build.xml
cba/modules/Developer/Studio/Documents/Shared/build.xml
cba/modules/Developer/Tutorial/build.xml
cba/modules/Developer/Tutorial/Client/build.xml
cba/modules/Developer/Tutorial/Server/build.xml
cba/modules/Developer/Tutorial/Shared/build.xml
cba/modules/Diagnostics/build.xml
cba/modules/Diagnostics/Client/build.xml
cba/modules/Diagnostics/Server/build.xml
cba/modules/Diagnostics/Shared/build.xml
cba/modules/InternationStandard/build.xml
cba/modules/InternationStandard/Client/build.xml
cba/modules/InternationStandard/Server/build.xml
cba/modules/InternationStandard/Shared/build.xml
cba/modules/Template/build.xml
cba/modules/Template/Client/build.xml
cba/modules/Template/Server/build.xml
cba/modules/Template/Shared/build.xml
cba/modules-internal/build.xml
cba/modules-internal/Admin/build.xml
cba/modules-internal/Admin/Client/build.xml
cba/modules-internal/Admin/Server/build.xml
cba/modules-internal/Admin/Shared/build.xml
cba/modules-internal/DDSimpleAppServer/build.xml
cba/modules-internal/Regulation/build.xml
cba/modules-internal/Regulation/Client/build.xml
cba/modules-internal/Regulation/Server/build.xml
cba/modules-internal/Regulation/Shared/build.xml
cba/modules-internal/SimpleAppSrv/build.xml
cba/modules-internal/SQLOracle/build.xml
cba/modules-internal/TableEditor/build.xml
cba/modules-internal/TableEditor/Client/build.xml
cba/modules-internal/TableEditor/Server/build.xml
cba/modules-internal/TableEditor/Shared/build.xml
cba/sa/build.xml
cba/setup/build.xml
cba/so-ext/build.xml
cba/so-ext/Bootstrap/build.xml
cba/so-ext/Crypto/build.xml
cba/so-ext/I18n/build.xml
cba/so-ext/KSwing/build.xml
cba/so-ext/KTL/build.xml
cba/so-ext/KTL/Client/build.xml
cba/so-ext/KTL/Server/build.xml
cba/so-ext/KTL/Shared/build.xml
cba/so-ext/Parser/build.xml
cba/so-ext/Parser/Editor/build.xml
cba/so-ext/RMI-security/build.xml
cba/so-ext/RMI-security/Common/build.xml
cba/so-ext/RMI-security/Server/build.xml
cba/so-ext/SQL/build.xml
cba/so-ext/Util/build.xml
cba/so-ext/Wizard/build.xml
cba/so-ext/XML2DB/build.xml
cba/sql/build.xml
cba/sql/access/build.xml
cba/sql/interbase/build.xml
cba/sql/oracle/build.xml
No za naz e vazno, sashtoto problemat beshe da napravim taka builda, che programistite, izpolzvashti platformata ni da prestanat da butat klientski kod v serverskite klasove, ili vikane na DB tier-a direktno ot klienta ili ot web server tier-a, bypass-vaiki serverskata biznes logika - pri serioznata
arhitektura tova e nedopustimo - novata versia prosto shte otkazhe da
se kompilira. Toest eleminirame arhitekturni greshki na nivo build. No beshe *mnogo* trudoemko, dokato go izlislim. :-(
Ne che pak marliacha niama da si ostane pak marliach, no pone shte mranka,
che mu e po-trudno da marlia s tezi build scriptove. :-)
cba/adk/db2install/build.xml
cba/adk/somwizard/build.xml
cba/adk/somwizard/filesystem/client/build.xml
cba/adk/somwizard/filesystem/nmod/build.xml
cba/adk/somwizard/filesystem/root/build.xml
cba/adk/somwizard/filesystem/server/build.xml
cba/adk/somwizard/filesystem/shared/build.xml
cba/adk/somwizard/filesystem/ula/build.xml
cba/adk/studio/build.xml
cba/adk/xmlexport/build.xml
cba/build/ant/build.xml
cba/build/client/build.xml
cba/build/mdk/build.xml
cba/build/mdk/ant/build.xml
cba/build/ula/build.xml
cba/kernel/build.xml
cba/kernel/Client-API/build.xml
cba/kernel/Core-API/build.xml
cba/kernel/Server-API/build.xml
cba/kernel/ULA-API/build.xml
cba/modinstall/build.xml
cba/modinstall/mast/build.xml
cba/modinstall/modsrv/build.xml
cba/modules/build.xml
cba/modules/bugReport/build.xml
cba/modules/bugReport/Client/build.xml
cba/modules/bugReport/Server/build.xml
cba/modules/bugReport/Shared/build.xml
cba/modules/bugReport/ULA/build.xml
cba/modules/Demo/build.xml
cba/modules/Demo/Client/build.xml
cba/modules/Demo/Server/build.xml
cba/modules/Demo/Shared/build.xml
cba/modules/Developer/Studio/Documents/build.xml
cba/modules/Developer/Studio/Documents/Client/build.xml
cba/modules/Developer/Studio/Documents/Server/build.xml
cba/modules/Developer/Studio/Documents/Shared/build.xml
cba/modules/Developer/Tutorial/build.xml
cba/modules/Developer/Tutorial/Client/build.xml
cba/modules/Developer/Tutorial/Server/build.xml
cba/modules/Developer/Tutorial/Shared/build.xml
cba/modules/Diagnostics/build.xml
cba/modules/Diagnostics/Client/build.xml
cba/modules/Diagnostics/Server/build.xml
cba/modules/Diagnostics/Shared/build.xml
cba/modules/InternationStandard/build.xml
cba/modules/InternationStandard/Client/build.xml
cba/modules/InternationStandard/Server/build.xml
cba/modules/InternationStandard/Shared/build.xml
cba/modules/Template/build.xml
cba/modules/Template/Client/build.xml
cba/modules/Template/Server/build.xml
cba/modules/Template/Shared/build.xml
cba/modules-internal/build.xml
cba/modules-internal/Admin/build.xml
cba/modules-internal/Admin/Client/build.xml
cba/modules-internal/Admin/Server/build.xml
cba/modules-internal/Admin/Shared/build.xml
cba/modules-internal/DDSimpleAppServer/build.xml
cba/modules-internal/Regulation/build.xml
cba/modules-internal/Regulation/Client/build.xml
cba/modules-internal/Regulation/Server/build.xml
cba/modules-internal/Regulation/Shared/build.xml
cba/modules-internal/SimpleAppSrv/build.xml
cba/modules-internal/SQLOracle/build.xml
cba/modules-internal/TableEditor/build.xml
cba/modules-internal/TableEditor/Client/build.xml
cba/modules-internal/TableEditor/Server/build.xml
cba/modules-internal/TableEditor/Shared/build.xml
cba/sa/build.xml
cba/setup/build.xml
cba/so-ext/build.xml
cba/so-ext/Bootstrap/build.xml
cba/so-ext/Crypto/build.xml
cba/so-ext/I18n/build.xml
cba/so-ext/KSwing/build.xml
cba/so-ext/KTL/build.xml
cba/so-ext/KTL/Client/build.xml
cba/so-ext/KTL/Server/build.xml
cba/so-ext/KTL/Shared/build.xml
cba/so-ext/Parser/build.xml
cba/so-ext/Parser/Editor/build.xml
cba/so-ext/RMI-security/build.xml
cba/so-ext/RMI-security/Common/build.xml
cba/so-ext/RMI-security/Server/build.xml
cba/so-ext/SQL/build.xml
cba/so-ext/Util/build.xml
cba/so-ext/Wizard/build.xml
cba/so-ext/XML2DB/build.xml
cba/sql/build.xml
cba/sql/access/build.xml
cba/sql/interbase/build.xml
cba/sql/oracle/build.xml
в отговор на Koнcтaнтин Cпиpoв
#13
Re: jdk1.3 vs jdk1.4
Zna4i naistina proekta vi e mnogo golqm i vse pak ako skriptovete sa naistina 100 pak mi se vijda mnogo. Mejdu drugoto ako ne e konfidencialno s kakva naso4enost e proekta? I drugo : kak go postigate tova "nalagane na dobyr stil" s ant? Moje bi nqkakvi igri sys sourcepath/classpath opciite na javac ili ...?
в отговор на silverBullet
#14
Re: jdk1.3 vs jdk1.4
Platforma za barzo razrabotvane na opredelen klas ot administrativni dokumenti - razrabotvame ne konkreten produkt, a platforma. Proektat izobshto ne e prednaznachen za BG i edva li ima shans da igrae na balgarskia pazar (a shefovete ni ne smiatat i da se opitvat - v BG neshtata sa po-osobeni, kakto vsicki znaem). Nash application server, proektat ne izpolzva EJB, no e mashtabiruem, zashtoto user tranzaktsiite sa proektirani po izkliuchitelno prost nachin. Arhitekturata e 3 tier (ili 4, ako se varze web servera). Sobstvena sistema za biznes logika, koiato e i na klienta, i na server-a. Sobstven DOM i lesen XML import/export. Mnogo sharen i tezak klientski interfeis + leka web chast, koiato za PDA ustroistva. Paranoichna sistema za sigurnost, logvane na tsialata istoria na dokumenta i lesna inspektsia. Nachina, po koito dokumenta moze da se promenia ot razlichnite potrebiteli i zhiznenia mu tsikal e opredelen v edin graf i zadaden mnogo iasno v koda. Ili kazano s drugi dumi - oshte po-goliamo ogranichavane svobodata za tehnologichen izbor na programista, no mnogo barzo razrabotvane.
A za xml-ite, tvarde mnogo e, az sam na sashtoto mnenie. Osobeno ako vsickite 100 faila s 1 ime mi se tsafnat na glavno nivo v IDE-to. No tova si e nash problem, a ne na application developer-ite, pri tiah shte sa mnogo po-malko.
Tochno kazano, igra s classpath. Imame shabloni za build failove i wizard-i, koito gi create-vat ot shablonite. Vav vseki modul classpath-a e takav, che .../server ima dostap do ../shared, no ne do ../client i taka natatak.
A za xml-ite, tvarde mnogo e, az sam na sashtoto mnenie. Osobeno ako vsickite 100 faila s 1 ime mi se tsafnat na glavno nivo v IDE-to. No tova si e nash problem, a ne na application developer-ite, pri tiah shte sa mnogo po-malko.
Tochno kazano, igra s classpath. Imame shabloni za build failove i wizard-i, koito gi create-vat ot shablonite. Vav vseki modul classpath-a e takav, che .../server ima dostap do ../shared, no ne do ../client i taka natatak.
Re: jdk1.3 vs jdk1.4
Mersi za infoto Kosio (az sym Vasko btw). Zvu4i kato naistina golqm proekt kakto go obqsnqvash. Oba4e ima neshto koeto ne mi se vryzva s tazi vashata platforma. Ako naistina kakto kazvash q pravite ot 7 godini, tova ozna4ava 4e q pravite priblizitelno ot 96-a. Hm, po tova vreme dokolkoto znam na Java ne se e gledalo kato na serverside platforma(koeto e donqkyde ironi4no kato se ima predvid dneshnoto systoqnie na neshtata). Taka 4e predpolagam 4e kogato ste q zapo4nali(ti moje bi ne si bil tam oshte zashtoto ako si spomnqm pravilno nqkyde beshe kazal 4e si na 30 - sledovatelno po tova vreme veroqtno si sledval) vsyshtnost ne e bila java platforma. Rannoto zapo4vane moje bi e obqsnenieto zashto ne ste izpolzvali nqkakyv open source application server(JBoss ili Jonas), koeto shteshe da vi dade nagotovo vyzmojnosti kato clustering i load balancing. E vqrno LGPL e ograni4itelen no pyk predpolagam 4e mojeshe arhitekturata da e takava 4e da otvorite sourca na eventualnite promeni v infrastrukturata na samiq server a ne na cqlata platforma. No kakto i da e - qvno si imate pri4ini da pravite neshtata taka kakto gi pravite. Uspeh :-).