argon bulletin board
Факултети => Факултет по математика и информатика => Темата е започната от: Jack Johnson в 22.06.2006, 17:53:26
-
Наложи ми се да се занимавам с интерпретиране и изпълнение на Java сорс код. Оказа се, че по света има ентусиасти, които вече са направили интерпретатор, безплатен е и най-важното - работи!
Това, което ме удиви най-мног е, че настройките на GUI tool-чето, което идва с дистрибуцията се зареждат... да, точно така - от файл, който съдържа скрипт на JAVA (Подчертавам JAVA, не JavaScript).
Най-хубавото на интерпретатора е, че е безплатен, може да се вгражда в други приложения (точно това, което ми трябва) и може да използва всички класове, които са заредени в JVM.
Забравих да спомена, че интерпретаторът е писан на JAVA, много е малък и парсерът му е съвместим със синтаксиса на Java 1.2 (Java 2).
http://koala.ilog.fr/djava/
-
kakva e ideiata na cialoto vsichko?
v kakva situacia shte moje da polzvash VM-to i shte iskash da go polzvash prez interpretator vmesto direktno?
-
men ne mi e iasno sled kato interpretatora e pisan na Java znachi na PC-to na koeto e kache ntrqbva da ima JVM .. i toi kakvo shte interepretira pak java sled kato ima JVM ? :)
inache ako e Open Source sigurno e polezno za razglejdane ili za base na drug proekt.
Primerno interpretator za C# na Java bi bilo intresno haha :>
-
Иване, защо казваш "има ентусиасти, които вече са направили интерпретатор". Първо, това не е от вчера. Второ - погледни секцията "News" на сайта, който самият ти си дал и виж датите на въпросните news :wink:
-
kakva e ideiata na cialoto vsichko?
v kakva situacia shte moje da polzvash VM-to i shte iskash da go polzvash prez interpretator vmesto direktno?
Всъщност в редки случаи. Но понякога е полезно. Иван в поста си е споменал един пример за конфигурационен файл, в който потребителите могат да пишат Java source код. Схващаш ли къде е ключовия момент? Не че според мен това е идеалният начин да се пишат конфигурационни файлове, но важна е идеята. Този интерпретатор не го стартираш ти, а приложението. Не че целта не може да постигната и без външен интерпретатор, ама сети се сам какъв би бил начинът и какви биха били недостатъците тогава...
-
Де го чукаш, де се пука...
Смисълът е, че при интерпретацията няма нужда от прекомпилиране, а при клиент-сървър приложение това означава undeply, rebuild, deploy, което като цяло е бавен, муден, сравнително сложен и най-вече неприятен процес и за програмистите и за крайните потребители, които В МОМЕНТА използват приложението.
Интерпретираният JAVA код служи перфектно за тунинговане на отделни елементи на приложението и то докато приложението работи с пълна сила. Сигурно някой сега ще каже нещо за JMX (ако изобщо някой си е играл с JEE до толкова, че да го използва), но JMX върши работа само на сървъра и то пак само за някои неща.
Много ясно, че след като има инсталиран JVM, интерпретираният JAVA код си губи смисъла като ОСНОВЕН управляващ код. Но ето, че възникват ситуации, които налагат runtime промени по приложението. И какво става тогава? Пишем код за отдалечена настройка на всички възможни случаи, които се сетим? Ами онези останали 80%-90% от случаите, които не сме покрили? Аз си дадох възможност да настройвам (препрограмирам) всичко runtime и вече не ме интересува дали възможните случаи са 2, 20 или 200 000 000, сядам, пиша малко JAVA код, той се интерпретира и взаимодейства с приложението! За целите на моята работа това е перфектно решение!
-
Доста лош подход за поддръжка на приложение. Особено за клиент-сървър. Не се сещам за по-лоша идея.
-
Хммм... като казах, че използването на външен интерпретатор много рядко има смисъл... I meant it ;)
Това което правиш - да пишеш програма, която после да ъпдейтваш е най-нормалното решение. Не знам защо си усетил необходимост от такова екзотично решени. Redeploy-нето не е толкова страшно, колкото ти изглежда. Да, то довежда до малко забавяне, но само в момента когато си обновиш приложението. Отделно, че никой не те кара да обновяваш цялото приложение. Често е достатъчно само даден модул (jar, war, ear и т.н.). Би трябвало да си чувал и за т. нар. "hot redeploy"? Откъде въобще реши, че този процес е бавен, мудел, сложен, неприятен и т.н.?
Това което ти правиш има доста повече недостатъци. Ще спомена само част от тях... Съвсем скоро ще ти стане доста трудно да поддържаш приложението... не трудно, ще стане кошмар да хванеш края на различните версии, дистрибуции... особено ако имаш повече от един клиент. Второ, колко често правиш redeploy? Дори и да е всеки ден, кое е по-добре - част от логнатите потребители да усетят малко забавяне ако в точно този момент отправят определена заявка, или сървърът всеки път да интерпретира сорс кодове!? Моля те, не прави така, че после някой пак ще тръгне да обяснява колко бавна била java-та..
А впрочем JMX не знам защо го намесваш. Може би се заблуждаваш от това, че той е здраво залегнал в доста приложни сървъри. Но причината затова е малко по-друга... в момента ме мързи да го обяснявам
-
Ще се постарая да отговоря възможно най-културно:
1) Атанасе, това с ъпдейтването го казваш ти, аз казах тунинг.
2) Става въпрос изключително за тестови приложения, не за реално работещи системи. При реално работещите подобен подход представлява най-малкото пробив в сигурността и то много сериозен - аз лично бих уволнил човека, който направи подобно нещо.
3) В моя случай реалното приложение на интерпретатора е в доста по-различно направление от тунинг или поддръжка, само дадох пример с поддръжката и ЕВЕНТУАЛНО къде интерпретаторът би намерил приложение. Лошо е да се вади смисъл от контекста на неизказаното, но това е повече моя грешка.
4) Атанасе, повярвай ми, много добре съм запознат с парадигмата клиент-сървър, особено що се отнася до JEE! Знам отлично как и кога да направя редеплой на отделен модул. В тази връзка искам да направя една корекция в твоя предишен пост, цитирам:
...Отделно, че никой не те кара да обновяваш цялото приложение. Често е достатъчно само даден модул (jar, war, ear и т.н.). Би трябвало да си чувал и за т. нар. "hot redeploy"?...
EAR не е само "един модул", а архив, който съдържа други модули, които дефинират цялото приложение, редеплойването му автоматично ще доведе до редеплойване на отделните му съствни модули. От начина по който пишеш разбирам, че си запознат с това, предполагам, че в бързината не си доогледал поста и си допуснал "лексикална" грешка. :)
5) Аз лично много мразя да чакам по 2-3 минути при редеплойване на приложението на локалния ми компютър на локалния ми сървър само за да въведа промени в един модул, на да кажем един ред от сорс кода. А на ден може да се наложи и 20 пъти да се редеплойва цялото приложение, зависи какво точно искам да тествам. Ето тук идва на помощ интерпретатора, който ми позволява да пренастройвам вече деплойнатите обекти БЕЗ да пипам сървъра по какъвто и да било начин.
-
С какви точно тулове и приложения работиш? С Intellij Idea + JBoss приложението се hot-redeploy-ва за под 10 секунди. JDeveloper има чудесна интеграция с Oracle Application Server, JSP-тата се прекомпилират автоматично при touch, да не говорим че при debug е необходимо просто прекомпилиране на даден java файл.
Както и да се погледне ползването на интерпретатор е много лоша практика и не е оправдана.
Аз не само бих уволнил някой, който ползва подход като теб, но и бих му дал и чудесни референции за в бъдеще ;).
-
С какви точно тулове и приложения работиш?
Не мога да ти кажа с какви тулове и приложения работя, но общият брой на бийновете, които се деплойват е едно солидно четири цифрено число. Сега си представи за какъв обем от файлове става въпрос и защо ми е "неудобно" да чакам редеплойването!
-
Иване, изглежда че неволно съм те засегнал. Повярвай ми, не съм имал това за цел. Все пак форумът е за това - да се споделят мнения, опит, знание и т.н.
За EAR-ите не съм допуснал "лексикална" грешка. Както знаеш едно приложение може да се състои от множество EAR-и. Това че те от своя страна могат да съдържат .jar, .war, .sar и тем подобни архиви, не означава че е погрешно даден EAR да се нарече "модул". Както и да е, това са глупави подробности. Тъпо е и да спорим кой какво точно е казал.
От думите ти за 2-3 минутния redeploy си правя изводите, че най-вероятно redeploy-ваш цялото приложение. Това понякога е необходимо, лошо няма. Но често е достатъчно да се redeploy-ва само част от приложението. А иначе най-вероятно ползваш сървър и IDE, които позволяват автоматичен hot redeploy само на редактирания клас... Енев ти спомена за някои от тях.
Хайде и не се засягай за глупости. Не приемай различните мнения като заяждане. Чел съм напоследък някои твои постове във форума. Прави ми приятно впечатление, че като цяло си станал наистина компетентен по много въпроси, за което най-искрено се радвам и те поздравявам! :-)
Поздрави,
Наско
-
Atanase primerno na BEA Web Logic da spomena che naistina se deployva hiper bavno neznam zashto inache na JBoss naistina e pod 10 sec. taka che i 2-3 minuti e vazmojno i 10 secundi e vazmojno
zavisi ot vsichko i ot golemina na prilojenie i ot app serve-ra
no naistina redeploy na cialo prilojenie se pak se okazva po chesto otkolkoto ni se iska
ili pone na men.
kolkoto za interpretatora
spored men takyv nachin za tuningovane e typ :<
nenzam shto :) neshto ne go priemam
kolkoto po malko ima neshto obshto s interpretatori tolkova po dobre
kolkoto za configuraciqta znaem che v java 1.6 si ima ScriptEngine kef ti pishi na JavaScript kef ti na PHP python ruby iili Groovy ... shte si imash interpretatoren ezik i bez drug interpretator
inache naisitna ne se setih za tova prilojenie na interpretatora koito spomena ivan taka che ivane da naistina ima ideq v nego i like it :>
haresva mi che go ima a ne che shte go polzvam :)
-
kolkoto za configuraciqta znaem che v java 1.6 si ima ScriptEngine kef ti pishi na JavaScript kef ti na PHP python ruby iili Groovy ...
Е-е-е-х, то в Java 6 доста нови работи има, жалко че не я създадоха преди 10-тина години! :)
-
v .NET Framework sa vkliucheni compilerite za ezicite(csc.exe ilasm.exe...) tochno s tazi ideia da se suzdava code at runtime... mai
za java niama li neshto takova?
-
въпроса е без да се компилира.
-
v .NET Framework sa vkliucheni compilerite za ezicite(csc.exe ilasm.exe...) tochno s tazi ideia da se suzdava code at runtime... mai
А аз си мислех, че компилаторите за езиците са включени в дистрибуцуята на VIsual Studio, защото без тях IDE-то няма да компилира нищо :)
za java niama li neshto takova?
Има, ама директен съпорт идва чак в JAVA 6
-
А аз си мислех, че компилаторите за езиците са включени в дистрибуцуята на VIsual Studio, защото без тях IDE-то няма да компилира нищо :)
Има, ама директен съпорт идва чак в JAVA 6
ne sa s IDE-to s Frameworka si vurviat csc.exe, jsc.exe, vbc.exe i ilasm.exe i dosta drugi chisto developerski istorii ama da ne se izlagam da gi spomenavam kato ne znam kvo praviat
ta ideiata mi e che e gotino programata ti da tvori kod i da go compile-va
taia java pak izostava :)
-
neka :>
az lichno ne bih imal nishto protiv java da si sedeshe vinagi v polojenie JVM 1.4.2