[Java] Minder code..

[Alarmnummer]

Een van de dingen waar ik me aan erger bij het ontwikkelen van code is dat er vaak zoveel overhead is. De simpelste dingen kosten veel werk als je het op de 'robuuste' manier wilt doen. Ik ben helemaal voor de robuuste manier, maar in veel gevallen (vooral als je in de leafs van je systeem zit), dan is er bv weinig voordeel te halen. Je gaat niets re-usen aangezien het zo specifiek is. De code wordt nooit in een andere context gebruikt dus waarom nog letten op access modifiers? Waarom nog letten op losse files?

Daarom kijk ik de laatste tijd wel anders aan tegen deze 'leaf' code, en misschien is dat bv een goeie plek om wel scripttalen te gebruiken. Ik werk zelf (zoals iedereen wel weet) met Spring en ik zie dat heel veel van dit soort 'leaf' code verplaatsen naar Spring. Dit heeft als voordeel dat ik minder classes in mijn systeem krijg (en daarom het systeem imho ook veel beter te begrjpen is). Verder heb ik ook geen verplichtingen van dit soort code meer en een van de gevolgen is, is dat mijn software meer agile is. Je kunt Spring dan zien als een scripttaal (met een hoogst twijfelachtige syntax).

Een voorbeeld van de twijfelachtige syntax:

XML:

<bean class="com.jph.spring.MethodInvokingSequenceJobDetailFactoryBean">
    <property name="methodInvokerList">
        <list>
            <bean class="org.springframework.util.MethodInvoker">
                <property name="targetObject">
                    <ref bean="indexWriter"/>
                </property>

                <property name="targetMethod">
                    <value>processQueue</value>
                </property>
            </bean>

            <bean class="org.springframework.util.MethodInvoker">
                <property name="targetObject">
                    <ref bean="baseSearcher"/>
                </property>

                <property name="targetMethod">
                    <value>refreshReader</value>
                </property>
            </bean>
        </list>
    </property>

    <property name="concurrent">
        <value>false</value>
    </property>

</bean>

Het enige dat ik hier doe is een 2 methodes aanroepen op een paar object...

In het algemeen denk ik ook dat Scripttalen voor de grenzen van een systeem wel eens een oplossing kunnen zijn. Zeker als je kijkt dat je bijna per definitie een betere syntax krijgt dan xml.
Waar ik op dit moment wel bang voor ben is refactoring, aangezien scripttalen niet worden geanalyseerd door ide`s.

Een ander punt waar ik me de laatste tijd weer aan heb zitten ergeren zijn exceptions. Ik werk veel met layering in mijn systemen en dan moet je exceptions van lagere layers vertalen naar exceptions van hogere layers, zodat er geen dependencies naar diepere lagen ontstaat. In sommige gevallen is dit perfect.. exceptions vertalen naar lager abstractie nivo (wrappen dus) en voorzien van meer betekenis volle fouten. Dus ipv een 'error op #1F49:AE57 in controller #2394' krijg je een 'het bestand kon niet opgeslagen worden' (eventueel met een cause). Je moet er wel voor zorgen dat alle acties die een gebruiker heeft uitgevoerd met een try catch(alles) worden uitgevoerd.. (voor zover je dat nog niet had gedaan )

Maar in veel gevallen, zijn het exceptions, waarvan ik weet dat ze op hoger nivo toch niet afgehandeld gaan worden. Voorbeeld hiervan zijn IOExceptions in Lucene (een searchengine voor Java). Als een fout zich voordoet dan (en dat kan gewoonlijk nooit gebeuren), dan weet ik dat ik op hoger nivo hier toch niets zinnigs mee ga doen. Maar toch sleep ik die exception mee naar boven in de lagen (en bij iedere laag transformeer ik de exception).. Ik heb daarom een van de mission statements van Spring er bji gepakt Checked exceptions are overused in Java. A framework shouldn't force you to catch exceptions you're unlikely to be able to recover from.

En idd.. ik moet dit keer toegeven dat in veel gevallen ik wel de prijs betaal van die exception afhandeling (lees wrappen en doorgooien omhoog), maar er totaal niets mee doe. Daarom kan ik hier ook weer wat onnodige code besparen. Verder is dit gebied voor mij wel nieuw dus ik zet nog wel met een aantal vragen en daar zal ik eerst eens goed over na moeten denken.

Wat is verder jullie idee over minder code? Over de 'logheid' van niet-script talen?

[ Voor 87% gewijzigd door Alarmnummer op 11-04-2005 11:48 ]

[Boudewijn]

jouw punt van teveel gezanik heb ik bij de meeste talen

Scrhijf maar een hello world op een 'robuuste' wijze in java ... echt niet klein hoor. Sinds ik hier echt een paar keer tegenop ben gelopen doe ik voornamelijk C en C++ (ook vanwege de snelheid). Het scheelt ook wel dat ik ook embedded software maak, dan is Java (zeker de JVM ) _veel_ te zwaar.

[Alarmnummer]

BoudewijnLinux schreef op zondag 10 april 2005 @ 21:42:
jouw punt van teveel gezanik heb ik bij de meeste talen

Niet in alle gevallen heb ik er problemen mee. Naarmate classes meer door andere classes worden gebruikt, des te minder problemen ik met 'robuustere' oplossingen heb. Hoe meer ik richting de core ga (en helemaal als ik richting classes/interfaces ga die onderdeel uit gaan maken van andere projecten), dan betaal ik met veel plezier die prijs aangezien ik er zo enorm veel voor terug krijg.

Scrhijf maar een hello world op een 'robuuste' wijze in java ... echt niet klein hoor. Sinds ik hier echt een paar keer tegenop ben gelopen doe ik voornamelijk C en C++ (ook vanwege de snelheid). Het scheelt ook wel dat ik ook embedded software maak, dan is Java (zeker de JVM ) _veel_ te zwaar.

Hmm tja.. een scripttaal die draait op dezelfde java vm zal dan ook geen oplossing zijn. Je geeft daarom kritiek op java in het geheel, en aangezien ik daar wel begrip voor op kan brengen, denk ik niet dat dit het juiste topic hiervoor is.

[ Voor 5% gewijzigd door Alarmnummer op 10-04-2005 21:53 ]

[ACM]

Alarmnummer schreef op zondag 10 april 2005 @ 21:21:
In het algemeen denk ik ook dat Scripttalen voor de grenzen van een systeem wel eens een oplossing kunnen zijn. Zeker als je kijkt dat je bijna per definitie een betere syntax krijgt dan xml.

Ik gruwel ook van de enorme hoeveelheid code-overhead die je bij java (en anderen) soms hebt. Ook het veelvuldig gebruik van XML maakt het er niet beter op, sterker nog. Soms is het minder werk om het in de code uit te voeren dan in de XML.
Annotations en Generics zorgen er al voor dat het in Java soms gewoon significant minder code is. Generics werkt tenslotte over het algemeen niet in de XML-lezende applicaties en Annotations zorgen er voor dat er slechts 1 regeltje "code" extra is ipv een complete XML-entry.

Waar ik op dit moment wel bang voor ben is refactoring, aangezien scripttalen niet worden geanalyseerd door ide`s.

Dat is de boel omdraaien Scripttalen kunnen heus wel geanalyseerd worden. Elke zichzelf respecterende php-"ide" parsed on-the-fly je function-headers voor code-completion. Zend's IDE kan zelfs define's, includes en allerlei andere dingetjes voor je analyzeren en je daardoor nog wat meer grip op je code geven. Het haalt het absoluut niet bij wat ik in IDEA allemaal kan doen, maar het gaat wel een goede kant op.

Wat is verder jullie idee over minder code? Over de 'logheid' van niet-script talen?

Minder code kan imho ook al met goed gebruik van Java en wat nieuwere features. Hoe slimmer de "omgeving" hoe beter natuurlijk. Zo kan je met Hibernate3 de .hbm.xml's overboord gooien als je bereid bent Annotations te gebruiken. Overigens is het in dit geval niet eens zo veel meer code om toch de .hbm.xml's te gebruiken.

Trouwens, in je spring-configuratie moet je natuurlijk ook de shortcuts kennen en gebruiken he?

XML:

<bean class="com.jph.spring.MethodInvokingSequenceJobDetailFactoryBean">
    <property name="methodInvokerList">
        <list>
            <bean class="org.springframework.util.MethodInvoker">
                <property name="targetObject" ref="indexWriter"/>

                <property name="targetMethod" value="processQueue" />
            </bean>

Is toch weer aardig wat korter dan de jouwe en zeker met een flinke hoeveelheid properties maakt dat flink uit.

[Verwijderd]

Goh, de java-hova komt eindelijk tot inzicht dat 'zijn' taal en de bijbehorende frameworks wel heel erg bloated zijn
Ik werk nu enige tijd met java/spring/hibernate maar ik begin me meer en meer te irriteren aan de 'overdesign' houding die er in de java cultuur heerst. Voor de simpelste database acties worden er minimaal 5 lagen geschreven In plaats van de ontwikkeltijd te versnellen neemt de kleinste aanpassing al uren in beslag omdat alle lagen doorgewerkt moeten worden.
De bomen in het bos mogen dan wel allemaal mooi gestructureerd geplant zijn, maar als het 5 uur duurt om naar de andere kant te komen heb je d'r ook niets aan. Dan maar een wat rommeliger, maar 10x kleiner, bos.

[MSalters]

Dat is inderdaad een typische kwaal die ik in de Java wereld vaker zie. Laten we een DB-neutrale implementatie kiezen, en vervolgens gaat er een laag rondom een paar SQL SELECTs. De ironie dat SQL juist een gemeenschappelijke taal is van die DBs, en dus al die gewenste functie vervult, ontgaat ze.

[Orphix]

Die robuustheid, en ik geloof dat dit voornamelijk komt door de extra loosely-coupled classes die je introduceert voor flexibiliteit, wil je wel. Ik denk dat wat je meer tegenzit niet de vele code op zich is (mits goed gestructureerd is dit geen probleem), maar het feit dat je steeds dezelfde code zit te typen. Na verloop van tijd zie je vaak dat er programma's komen die een abstractielaag hoger zitten om dit voor jou af te handelen. Een goed voorbeeld hiervan zijn UML editors die rechtstreeks java classes kunnen generen. Nu is dit misschien nog triviaal, maar je kan je voorstellen dat je met programma's waarbij je bijvoorbeeld visueel workflows kan definieeren en daaruitvolgend javacode kan genereren je een hoop tikwerk kan besparen. Een ander voorbeeld is het generen van DA layers. Het voordeel hiervan is dat mocht je onverhoopt toch nog specifieke en creatieve dingen willen doen, dan kan je altijd nog in die gegenereerde code gaan werken. De vraag is dus denk ik meer of de bloatedness een probleem van de taal (want het had bijvoorbeeld abstracter moeten zijn) is, of dat je er op een manier mee werkt waar het niet voor bedoeld is.

p.s. het verplicht afhandelen van exceptions is wel een crime, dat hadden ze allang moeten afschaffen

[Blue2k]

MSalters schreef op zondag 10 april 2005 @ 23:29:
Dat is inderdaad een typische kwaal die ik in de Java wereld vaker zie. Laten we een DB-neutrale implementatie kiezen, en vervolgens gaat er een laag rondom een paar SQL SELECTs. De ironie dat SQL juist een gemeenschappelijke taal is van die DBs, en dus al die gewenste functie vervult, ontgaat ze.

Maar aan de andere kant, ontwikkelingen staan ook niet stil. Als je eenmaal je db laag in SQL hebt is het mijnsinziens een kleine moeite om er een wrapper omheen te gooien die ervoor zorgt dat later bij SQL optimalisaties (nieuwere versies) alles makkelijk te updaten is. En ook het switchen van db's is echt niet transparant. Voor simpele SQL queries misschien wel, maar voor de wat geavanceerdere notaties zijn er toch kleine nuances. Maar voor de rest ben ik het wel met iedereen eens dat het ook van het project afhangt,

[Orphix]

MSalters schreef op zondag 10 april 2005 @ 23:29:
Dat is inderdaad een typische kwaal die ik in de Java wereld vaker zie. Laten we een DB-neutrale implementatie kiezen, en vervolgens gaat er een laag rondom een paar SQL SELECTs. De ironie dat SQL juist een gemeenschappelijke taal is van die DBs, en dus al die gewenste functie vervult, ontgaat ze.

Helaas zijn er SQL dialecten tussen verschillende DB systemen dus praktisch gezien gaat dit helaas niet altijd op. Maar ik vermoed dat je op het idee erachter doelt dat de javaprogrammeur zich verplicht voelt zoveel mogelijk design in de oplossing proberen te verwerken, waar ik me wel een beetje in kan vinden. Maar is dit dan een kwaal van de taal, of een kwaal van de java-community?

[Verwijderd]

MSalters schreef op zondag 10 april 2005 @ 23:29:
Dat is inderdaad een typische kwaal die ik in de Java wereld vaker zie. Laten we een DB-neutrale implementatie kiezen, en vervolgens gaat er een laag rondom een paar SQL SELECTs. De ironie dat SQL juist een gemeenschappelijke taal is van die DBs, en dus al die gewenste functie vervult, ontgaat ze.

Nouja, elke database heeft wel zijn eigen SQL dialect. Bij ons is er, o.a om deze reden, gekozen om Hibernate te gebruiken. Mooi zo'n extra abstractie, ware het niet dat je 'complexe' queries toch weer zelf moet schrijven alleen dan in HQL. Het mooie is dat men tijdens het deployen op een HP NonStop server er achter kwam dat Hibernate toch niet zo database onafhankelijk was en er toch weer de nodige aanpassingen gemaakt moesten worden. Dan vraag ik me toch serieus af waarom je het allemaal doet. Ontwikkeltijd? Performance?

[Alarmnummer]

Verwijderd schreef op zondag 10 april 2005 @ 23:21:
Goh, de java-hova komt eindelijk tot inzicht dat 'zijn' taal en de bijbehorende frameworks wel heel erg bloated zijn
Ik werk nu enige tijd met java/spring/hibernate maar ik begin me meer en meer te irriteren aan de 'overdesign' houding die er in de java cultuur heerst. Voor de simpelste database acties worden er minimaal 5 lagen geschreven

Voor kleine applicatie trekken we de hele applicatielaag ertussen uit en en integreren we dat netjes bij de view (in het backing object van de view). Je blijft maar door lagen heen lopen om ergens te komen en voor simpele dingen gaat dit gewoon sneller.

Verder ben ik bezig met een code-generator die al de meeste dingen klaar zet (combinatie van middlegen/hibernate tools en mijn eigen velocity templates). Op basis van een db model heb je dan meteen alle entities, hbm mappings, dao`s interfaces/dao implementaties, spring config aanpassingen, service interfaces/implementaties etc. Ik moet hierin nog de mogelijkheid kunnen geven om andere code te genereren op basis van het soort aanpak (en dat is afhankelijk van de omvang van een project).

[ Voor 22% gewijzigd door Alarmnummer op 11-04-2005 06:23 ]

[Alarmnummer]

MSalters schreef op zondag 10 april 2005 @ 23:29:
Dat is inderdaad een typische kwaal die ik in de Java wereld vaker zie. Laten we een DB-neutrale implementatie kiezen, en vervolgens gaat er een laag rondom een paar SQL SELECTs. De ironie dat SQL juist een gemeenschappelijke taal is van die DBs, en dus al die gewenste functie vervult, ontgaat ze.

Niet helemaal mee eens. Veel databases hebben hun eigen speciale dialecten en daar kan een goeie or mapper ook volledig gebruik van maken. Verder maak ik zelf graag een abstractie van de interface en implementatie omwillen van het testen... Gelukkig wordt dit allemaal voor me gegenereerd

En ik zit er aan te denken om de guidelines voor kleine projecten ook aan te passen dat interface/class platgeslagen kan worden tot alleen een class. Scheelt weer een hele zwik met niets toevoegende code.

[ Voor 15% gewijzigd door Alarmnummer op 11-04-2005 06:14 ]

[Alarmnummer]

ACM schreef op zondag 10 april 2005 @ 22:57:
[...]

Ik gruwel ook van de enorme hoeveelheid code-overhead die je bij java (en anderen) soms hebt. Ook het veelvuldig gebruik van XML maakt het er niet beter op, sterker nog. Soms is het minder werk om het in de code uit te voeren dan in de XML.
Annotations en Generics zorgen er al voor dat het in Java soms gewoon significant minder code is.

Hmm tja.. generics.. Ik ben in het verleden erg veel bezig geweest met generics, maar ik kan het nu een tijdje niet gebruiken, aangezien we op mijn werk nog met 1.4 werken. Ik kan niet zeggen dat ik er nou zo extreem rauwig om ben. Het enige dat ik enorm mis, is dat ik niet kan zien wat in mijn collections zit.

Generics werkt tenslotte over het algemeen niet in de XML-lezende applicaties en Annotations zorgen er voor dat er slechts 1 regeltje "code" extra is ipv een complete XML-entry.

Annotations zouden je veel werk kunnen besparen maar aangezien we nog met 1.4 werken is het geen optie. En verder moet je ook tools hebben die er gebruik van maken (hibernate 3 zou wel interessant kunnen zijn, maar dat is ook de enige die ik ken).

Dat is de boel omdraaien Scripttalen kunnen heus wel geanalyseerd worden. Elke zichzelf respecterende php-"ide" parsed on-the-fly je function-headers voor code-completion. Zend's IDE kan zelfs define's, includes en allerlei andere dingetjes voor je analyzeren en je daardoor nog wat meer grip op je code geven. Het haalt het absoluut niet bij wat ik in IDEA allemaal kan doen, maar het gaat wel een goede kant op.

Het ging mij erom dat ik het kan zien in de ide waar ik mee werk. Aangezien dat nu niet kan: geld het motto: wat niet werkt, bestaat niet.

Minder code kan imho ook al met goed gebruik van Java en wat nieuwere features. Hoe slimmer de "omgeving" hoe beter natuurlijk. Zo kan je met Hibernate3 de .hbm.xml's overboord gooien als je bereid bent Annotations te gebruiken. Overigens is het in dit geval niet eens zo veel meer code om toch de .hbm.xml's te gebruiken.

Hmmm... moet ik binnenkort toch eens naar Hibernate 3 kijken *wil eerst 2 goed onder de knie krijgen*

Trouwens, in je spring-configuratie moet je natuurlijk ook de shortcuts kennen en gebruiken he?

Die kon ik nog niet. Ik zal het eens gaan aanpassen. Verder werk ik trouwens zo weinig mogelijk met properties en doe bijna alles via de constructor.

[ Voor 15% gewijzigd door Alarmnummer op 11-04-2005 11:49 ]

[ACM]

Alarmnummer schreef op maandag 11 april 2005 @ 06:59:
Hmm tja.. generics.. Ik ben in het verleden erg veel bezig geweest met generics, maar ik kan het nu een tijdje niet gebruiken, aangezien we op mijn werk nog met 1.4 werken. Ik kan niet zeggen dat ik er nou zo extreem rauwig om ben. Het enigste dat ik enorm mis, is dat ik niet kan zien wat in mijn collections zit.

Ik heb het o.a. toegepast voor een generalisatie van mijn DAO en Service klassen. Daardoor heb ik maar 1 interface definitie nodig voor de basisfunctionaliteit en een abstracte klasse nodig die het gros van de basisfunctionaliteit voor zijn rekening neemt. Generics zorgt er wel voor dat een subklasse van die abstracte klasse dan automatisch type-safe de basisfunctionaliteit krijgt.
Toen ik dat met een nog wat minder handig opgezet stuk code uitvoerde heb ik geloof ik de boel van 2000 naar 1000 regels code teruggebracht. Als het niet meer was.

Dus ik had het niet over het gebruiken van de generics-dingetjes die je in Java kan gebruiken, dat gebruik ik natuurlijk ook wel, maar het toepassen in code die wel type-safe moet zijn, maar weer zo generiek is dat ik geen zin had de boel meerdere keren te schrijven.

Annotations zouden je veel werk kunnen besparen maar aangezien we nog met 1.4 werken is het geen optie. En verder moet je ook tools hebben die er gebruik van maken (hibernate 3 zou wel interessant kunnen zijn, maar dat is ook de enigste die ik ken).

Andere dan: de Transaction-manager van Spring kan het in 1.2 ook Heb ik uiteraard ook direct in mijn code toegepast, veel handiger dan apart nog weer ergens in een XML definieren dat een bepaalde functie transaction-safe moet zijn. Want eerlijk gezegd vind ik dat iets dat wel in je code hoort te staan. Dat je dan verder onafhankelijk van je code definieert wat er precies voor transaction-management is, is verder prima.

Het ging mij erom dat ik het kan zien in de ide waar ik mee werk. Aangezien dat nu niet kan: geld het motto: wat niet werkt, bestaat niet.

Het kan dus wel, maar nog niet zo compleet als in Java-IDE's

Hmmm... moet ik binnenkort toch eens naar Hibernate 3 kijken *wil eerst 2 goed onder de knie krijgen*

Zo groot was het verschil tussen 2 en 3 niet volgens mij, maar ik ben overigens direct met 3-alpha bezig gegaan, ipv eerst nog 2 te leren.

[Alarmnummer]

ACM schreef op maandag 11 april 2005 @ 08:29:
[...]

Ik heb het o.a. toegepast voor een generalisatie van mijn DAO en Service klassen. Daardoor heb ik maar 1 interface definitie nodig voor de basisfunctionaliteit en een abstracte klasse nodig die het gros van de basisfunctionaliteit voor zijn rekening neemt.

Dat doe ik ook. Enige voordeel is dat het typesafe is.

Dus ik had het niet over het gebruiken van de generics-dingetjes die je in Java kan gebruiken, dat gebruik ik natuurlijk ook wel, maar het toepassen in code die wel type-safe moet zijn, maar weer zo generiek is dat ik geen zin had de boel meerdere keren te schrijven.

Dan heb je ook andere dingen aangepast om op zo`n besparing te komen. Wat casts verwijderen zou niet mogen leiden tot zo`n reductie in de code.

Andere dan: de Transaction-manager van Spring kan het in 1.2 ook

I know.. dito voor security.

Het kan dus wel, maar nog niet zo compleet als in Java-IDE's

Ik doel op een integratie binnen mijn ide van een script taal. Bv Groovy, Jython, JRuby etc.

Zo groot was het verschil tussen 2 en 3 niet volgens mij, maar ik ben overigens direct met 3-alpha bezig gegaan, ipv eerst nog 2 te leren.

Het verschil is niet groot (het zijn voornamelijk toevoegingen). Daarom wil ik de basis goed beheersen ipv me op de nieuwe goodies te concentreren.

[Infinitive]

Het nadeel van code-generation is dat je vaak toch nog aanpassingen wilt maken in de gegenereerde code. Helaas kan dit soms vervelend zijn wanneer je de code overnieuw wilt genereren.

Maar wat denk je van language-embeddings, zoals:
http://catamaran.labs.cs....Stratego/JavaSwulExamples

(een nadeel hiervan is dat een editor voor java de embedding niet zal snappen)

[Alarmnummer]

Infinitive schreef op maandag 11 april 2005 @ 10:23:
Het nadeel van code-generation is dat je vaak toch nog aanpassingen wilt maken in de gegenereerde code. Helaas kan dit soms vervelend zijn wanneer je de code overnieuw wilt genereren.

Helemaal mee eens. Maar ik heb nu een (niet perfecte) oplossing voor een bepaald probleem. Deze oplossing (zelfs in zijn niet perfecte staat) bespaard mij een hoop dom werk.

Maar wat denk je van language-embeddings, zoals:
http://catamaran.labs.cs....Stratego/JavaSwulExamples

Ik denk dat dat wel de toekomst gaat worden: domein specifieke talen.

[ACM]

Alarmnummer schreef op maandag 11 april 2005 @ 08:34:
Dan heb je ook andere dingen aangepast om op zo`n besparing te komen. Wat casts verwijderen zou niet mogen leiden tot zo`n reductie in de code.

't Ging dus niet om die casts, juist om de reductie van code in de service en dao-klassen. Ik had het namelijk wel type-safe, dus ook zonder generics (en dus veel "bijna dezelfde" code). Die duplicatie van bijna-dezelfde-code heb ik met generics weggewerkt en toch nog steeds generieke, maar type-safe code overgehouden.
En dat leverde dus wel degelijk een flinke reductie van code op.

Het vervangen van allerlei casts, omschrijven van while's met iterator naar for-each, etc dat bespaarde ook nog wel aardig wat code, maar niet zo enorm veel.

Ik doel op een integratie binnen mijn ide van een script taal. Bv Groovy, Jython, JRuby etc.

Dus je wilt met een scripttaal stukken code/configuratie genereren? Op zich is dat wel een aardig idee, maar waarom dan niet een scripting-omgeving integreren in Java?
Dus dat je zelfs die generatie-stap overslaat maar dat configuraties on-the-fly worden gegenereerd en/of bijgewerkt van je applicatie.

[Alarmnummer]

Dus je wilt met een scripttaal stukken code/configuratie genereren? Op zich is dat wel een aardig idee, maar waarom dan niet een scripting-omgeving integreren in Java?

pcies.. is trouwens ook een JSR voor.

Dus dat je zelfs die generatie-stap overslaat maar dat configuraties on-the-fly worden gegenereerd en/of bijgewerkt van je applicatie.

Hmmm.. generatie stap overslaan.. niet helemaal. Bij ons kunnen de gegenereerde bestanden bewerkt worden. Als je opnieuw genereerd ben je dus al je wijzigingen kwijt. Maar dit de opzet van die generator ook niet.. het was de bedoeling om iedereen zo snel mogelijk aan het werk te krijgen, en om iedereen een zelfde basis structuur aan te bieden (directories, scripts, layers etc). Uiteraard kun je hier van af wijken maar tot zover is dat nog niet vaak voorgekomen.

[Verwijderd]

offtopic:
Ik vraag me af of dit allemaal nou echt nodig is. Ik wil geen flame starten of zeggen dat het allemaal niet nodig is, maar ik was me bij het lezen van deze topic weer af aan het vragen of alle frameworks, mappers etc etc nou echt zo veel bijdragen aan een project.

Als je in XML in principe code bent aan het zetten om methods aan te roepen, ben je dan niet al te ver doorgeschoten? Natuurlijk is het ongelofelijk flexibel etc etc, maar in Java zelf kan het vele malen korter en veiliger (geen reflection exceptions, compile-time gecheckt etc).

Ik ben zelf ook altijd druk bezig geweest in Java met mooi designen, alles zo netjes mogelijk te maken/houden (dit nog steeds trouwens ) en bestaande frameworks te gebruiken, maar de laatste tijd heb ik wat in PHP gewerkt en daar moet je het merendeel toch zelf maken. Voor mij werkte het programmeren in PHP (inclusief het schrijven van een struts-achtig framework, DB mapping etc) echt stukken sneller en prettiger dan het (over)designen in Java en het leren van frameworks.

Dus daarom mijn vraag: hebben jullie (Alarmnummer ) nou echt projecten gedraaid waarbij je noemenswaardig voordeel uit alle faciliteiten van Java hebt gehaald?

[Alarmnummer]

Verwijderd schreef op maandag 11 april 2005 @ 16:55:
[offtopic]
Ik vraag me af of dit allemaal nou echt nodig is. Ik wil geen flame starten of zeggen dat het allemaal niet nodig is, maar ik was me bij het lezen van deze topic weer af aan het vragen of alle frameworks, mappers etc etc nou echt zo veel bijdragen aan een project.

Als je in XML in principe code bent aan het zetten om methods aan te roepen, ben je dan niet al te ver doorgeschoten? Natuurlijk is het ongelofelijk flexibel etc etc, maar in Java zelf kan het vele malen korter en veiliger (geen reflection exceptions, compile-time gecheckt etc).

Yep.. maar je krijgt zoveel crappy 'bouw' code en dat gooi ik hier in XML zonder dat ik me er nog druk om hoef te maken. In java schrijf ik mijn componenten, in Spring lijm ik het in elkaar. Ik zit er alleen aan te denken om eens te gaan spelen met Groovy icm Spring. Dan kan je je hele systeem in Groovy in elkaar lijmen. Geen XML-syntax meer, maar een die leesbaarder is. Alleen lijkt me dit op dit moment onverstandig aangezien het bedrijf waar ik werk (mede door mij) over is op Spring. Daarom even een techniek stop.. iedereen kennis laten maken met Spring en het nieuwe platform.. daarna zien we wel weer.

Dus daarom mijn vraag: hebben jullie (Alarmnummer ) nou echt projecten gedraaid waarbij je noemenswaardig voordeel uit alle faciliteiten van Java hebt gehaald?
[/offtopic]

Hmmm lastige vraag. Ik begin me wel steeds meer te ergeren aan "in de toekomst wil je misschien wel ... " en daarop je ontwerp meteen al afstemmen. Al die layering is in veel applicatie een godsellendig blok aan je been. Met grote projecten is dit wel handig (vooral omdat je uitspraken kunt doen), maar met kleine projecten ben je imho onnodig moeilijk aan het doen.

Om je vraag te beantwoorden:
Ons eigen interne platform icm Spring, de code generator, en de juiste aanpak (is afhankelijk van de omvang van het project), ja.. dan haal je wel winst. Het uitgangspunt van ons platform is trouwens ook om ons zoveel mogelijk werk uit handen te nemen voor bepaalde type applicaties. Default staat alles zo ingesteld zoals je het waarschijnlijk zult gebruiken.. hoef je alleen de wijzigingen door te voeren (bv bij controllers).

Ik heb trouwens geen ervaring met scripttalen en webapps, en ik ben ook geen ervaren webapp bouwer (tenminste niet naar de weblayer kant toe). Aan de achterkant van systemen (die anderen dus gebruiken) heb ik erg weinig problemen met alle verbositeit van Java. Daar wil ik het zo robuust mogelijk hebben. Verder lijm ik deze componenten ook met Spring helemaal in elkaar en kan ik me ook een enorme zooi bouwobjecten (ruistobjecten) besparen. Ik vind dit eigelijk erg prettig aangezien ik maar een paar bestanden heb waarin ik een heel systeem volledig in elkaar lijm. Dit werkt zoveel prettig dan de klassieke aanpak.

[ Voor 17% gewijzigd door Alarmnummer op 11-04-2005 17:10 ]

[.oisyn]

Optimalisatiediscussie afgesplitst naar [rml][ Alg] code optimalisaties[/rml]

[Cuball]

Alarmnummer schreef op zondag 10 april 2005 @ 21:21:
Een ander punt waar ik me de laatste tijd weer aan heb zitten ergeren zijn exceptions. Ik werk veel met layering in mijn systemen en dan moet je exceptions van lagere layers vertalen naar exceptions van hogere layers, zodat er geen dependencies naar diepere lagen ontstaat. In sommige gevallen is dit perfect.. exceptions vertalen naar lager abstractie nivo (wrappen dus) en voorzien van meer betekenis volle fouten. Dus ipv een 'error op #1F49:AE57 in controller #2394' krijg je een 'het bestand kon niet opgeslagen worden' (eventueel met een cause). Je moet er wel voor zorgen dat alle acties die een gebruiker heeft uitgevoerd met een try catch(alles) worden uitgevoerd.. (voor zover je dat nog niet had gedaan )

Maar in veel gevallen, zijn het exceptions, waarvan ik weet dat ze op hoger nivo toch niet afgehandeld gaan worden. Voorbeeld hiervan zijn IOExceptions in Lucene (een searchengine voor Java). Als een fout zich voordoet dan (en dat kan gewoonlijk nooit gebeuren), dan weet ik dat ik op hoger nivo hier toch niets zinnigs mee ga doen. Maar toch sleep ik die exception mee naar boven in de lagen (en bij iedere laag transformeer ik de exception).. Ik heb daarom een van de mission statements van Spring er bji gepakt Checked exceptions are overused in Java. A framework shouldn't force you to catch exceptions you're unlikely to be able to recover from.

En idd.. ik moet dit keer toegeven dat in veel gevallen ik wel de prijs betaal van die exception afhandeling (lees wrappen en doorgooien omhoog), maar er totaal niets mee doe. Daarom kan ik hier ook weer wat onnodige code besparen. Verder is dit gebied voor mij wel nieuw dus ik zet nog wel met een aantal vragen en daar zal ik eerst eens goed over na moeten denken.

Wat is verder jullie idee over minder code? Over de 'logheid' van niet-script talen?

Ik ben sinds kort ook bezig met het Spring framework te integreren en ondertussen ben ik ook bezig met wat opschonen van allerhande code. Waar ik nu ook mee bezig ben zijn de exceptions... Voordien wrapte ik ALLE fouten (dus bv ook fouten vanuit de databank) in een eigen BusinessException. Ik ving die op in de Action klasse van men applicatie. Probleem was, wanneer er effectief een Business optrad in de business logica deze ook in een Businessexception terecht kwam. Wat tot gevolg heeft dat er aan de webkant geen onderscheid kon gemaakt worden tussen een fatale fout (meestal wanneer iets verkeerd gaat in de datalaag) en een business fout, die nog hersteld kan worden door de gebruiker.

Nu heb ik zitten denken, en hoe ik het nu zie om Exceptions naar de gebruiker toe zal laten vloeien:

• Echte BusinessException (die de gebruiker nog in staat stelt om verder te werken na correctie van de de fout
• Een DataAccessException die gewrapped wordt in een soort eigen exception met hierbij een foutcode of dergelijk zodat de gebruiker bij een probleem de helpdek kan verwittigen en deze fatale fout code mee doorgeven

hebben jullie hier nog andere ideeën over? of hoe doen jullie het nu ?

[Alarmnummer]

Cuball schreef op donderdag 14 april 2005 @ 15:27:
[...]

• Echte BusinessException (die de gebruiker nog in staat stelt om verder te werken na correctie van de de fout
• Een DataAccessException die gewrapped wordt in een soort eigen exception met hierbij een foutcode of dergelijk zodat de gebruiker bij een probleem de helpdek kan verwittigen en deze fatale fout code mee doorgeven

hebben jullie hier nog andere ideeën over? of hoe doen jullie het nu ?

Echte business exceptions zijn fouten die optreden als er een 'bedrijfslogische' fout optreed. Iemand probeerd bv 400 uur werk voor deze week op zichzelf te boeken. Dit zijn fouten die je zelf af kunt handelen (je kan de gebruiker een scherm tonen en zeggen dat ie niet zo moet ouwehoeren).

Database fouten zijn over het algemeen (niet altijd!) fouten die niet te herstellen zijn. De db is net ontploft, of het internet is gestopt. Dat zijn fouten die je gewoon niet kan herstellen en ik zou hiervoor gewoon gebruik maken van een runtime exception. De DataAccessException van Spring is trouwens een RuntimeException.

[Cuball]

laten we stellen dat die database ontploft is, krijgt de gebruiker dan een mooie error 500 pagina te zien met een of andere stacktrace erbij? Niet echt aanvaardbaar vind ik

[Alarmnummer]

Cuball schreef op donderdag 14 april 2005 @ 16:08:
laten we stellen dat die database ontploft is, krijgt de gebruiker dan een mooie error 500 pagina te zien met een of andere stacktrace erbij? Niet echt aanvaardbaar vind ik

Hmm.. Je zou de specifieke DataAccessException kunnen opvangen en op basis daarvan een database-error scherm laten zien.

[misfire]

Het verschil tussen scripttalen en programmeertalen vind ik persoonlijk in termen van logheid vrij minimaal (even los van de discussie of een scripttaal ook niet gewoon een programmeertaal is). Wat het verschil in logheid voornamelijk bepaalt is de semantische waarde van de syntax in relatie tot je probleemdomein. Oftewel, hoeveel onnodige onzin moet je schrijven voordat iets werkt.

Spring is zo opgezet dat je niet alleen XML hoeft te gebruiken voor de definitie van je configuratie. Je kunt gewoon Java code schrijven die doet wat jij wilt. In dit artikel wordt een voorbeeld gegeven van hoe je Groovy zou kunnen inzetten voor het opstellen van een Spring configuratie.

Van het voorbeeld in het bovenstaande artikel krijg ik echter spontane hoofdpijnen en andere lichamelijke klachten. Volgens mij is het droppen van de XML syntax niet de oplossing. De Spring configuratie is opgebouwd uit een hierarchisch gedefinieerde set nodes, die samen een netwerk vormen. In principe kan dat prima in XML, alleen moet je er af en toe wat meer voor typen dan je zou willen als je dat helemaal 1 op 1 moet doen. In de Spring 1.2 en 1.3 releases komen nieuwe features waarmee een aantal shortcuts worden toegevoegd om gangbare constructies te vergemakkelijken. De XML configuratie wordt dan wat simpeler, en dus duidelijker, zonder dat hiervoor een nieuwe taal moet worden bedacht (en moet worden ondersteund in editor tools en worden geleerd enz).

De maker van Hivemind heeft overigens in eerdere releases ook overwogen een eigen definitietaal te maken. Dat heeft hij later geschrapt. Waarom? Het voegde niets toe, werkte drempelverhogend, en leidde de aandacht af van de echte configuratieproblematiek.