Kigger ud af vinduet mens jeg leger med en matematisk formel og tænker på "Unit in the last place":http://en.wikipedia.org/wiki/Unit_in_the_last_place Beregningen fortager en prognose over en rate pension. Den antager en masse udfra nogle parameter og returner et resultat i form af kroner og øre. Jeg er stoppet op for at tænke lidt over præcision og udtryk mellem formler og programmeringsprog. Problemet er at jeg operere med store decimaltal og jeg ved de er upræcise. I første ilteration udnytter jeg Ruby som programmeringssprog fordi det handler udvikling af en formel og forståelse af problemområdet. Derefter skal de bedste formler overføres til Java som implementeringserpog og Javascript for hurtige forretningsvalidering. Undervej har jeg erfaret at jeg får forskellige resultater afhængig af platform og sprog. Lad mig starte med et regnestykke. 0.1 + 0.1 + 0.1 = ? <pre> System.out.println(0.1 + 0.1 + 0.1); # 0.30000000000000004 </pre> Resultatet er skuffende, og ikke de forventede 0.3 men et mere præcist resultat. Grunden er at Java konvertere værdien 0.1 til en double repræsentation og nu vil de mest ihærdige Java folk straks råbe løs om BigDecimal. <pre> System.out.println(new BigDecimal(0.1).add(new BigDecimal(0.1)).add(new BigDecimal(0.1))); # 0.3000000000000000166533453693773481063544750213623046875 </pre> Og det hjalp også lidt. Nu er resultatet langt mere præcist men stadig helt forkert. Problemet er at et "floating point tal":http://en.wikipedia.org/wiki/Floating_point er internt repræsenteret i binær form og decimaltallet 0,1 kan ikke præcist repræsenteres som "1,00011001100110". Det er lidt det samme som at dele en hel (1) i 1/3 og 2/3. Derved får man en 0.333333 og en 0.666666. Når disse to lægges sammen bliver det kun en 0.9999999 og ikke en hel. Men dette er kun første del af svaret. Vi må længere ind.. Der findes to typer af løsninger. * Den mest åbenbare er at undlade at arbejde med tal hvori der indgår decimaler * Den anden er at afrunde og beskære resultatet Decimaler eller floating point er i sagens natur upræcise. De bør undgås hvis der i løsningen skal indgå super præcise svar. Fx ved beløb eller møntenhed kan løsningen være at holde alle en enheder på lavest mulig niveau. Øre frem for kroner. Det virker som en naturlig ting at gøre, specielt hvis man tænker over at vi jo aldrig holder danske kroner i 10 stks pakker. Den anden metode er at skære de sidste mindst betydende decimaler af resultatet. Denne løsning bliver heller ikke præcis fordi der nu skal rundes af og jo flere kald der fortages jo flere metoder vil runde op eller ned ved afkortning af resultatet. Yderligere fejl findes der i de trigonometriske funktioner ikke der ikke er så teoretisk korrekte som man kunne forvente. Dette er et resultat af akkumulerede afrunding fejl i polynomium tilnærmelser der bruges internt til at beregne trigonometriske funktioner og logaritmer. Lad og kigge på "Eulers konstant (e)":http://en.wikipedia.org/wiki/E_(mathematical_constant) E er den matematiske konstant tættest på det unikke reelle tal. <pre> System.out.println(Math.E); # 2,718281828459045 System.out.println(Math.exp(1)); # 2,7182818284590455 </pre> Teoetisk burder disse to være ens i Java for at give resultater der er tæt på det teoretiske forventede. I ruby har Matz afrundet og afkortet en decimal tidligere for at ikke at løbe ind i akkumulerede fejl. <pre> puts Math::E # 2,71828182845905 puts Math.exp(1) # 2,71828182845905 </pre> Log Den "naturlige algoritme":http://en.wikipedia.org/wiki/Logarithm er base e, hvor e er et irrationelt konstant på 2,71828182845905. Den naturlige algoritme er skrevet som ln(x) eller log(x). Logaritmen af et tal til et givet basis er eksponent som base skal hæves for at producere et antal. For eksempel, base-10-logaritmen af 1000 er 3, da 3 er den magt, som ti skal hæves med for at producere 1000: 103 = 1000, så log10(1000) = 3. Logaritmen til x til basen b er skrevet logb (x) eller, hvis basen er implicit, så log (x). Så for en række x, en base b og en eksponent y. <pre> Math.log(Math::E) # 1.00 Math.log10(1000) # 3.00 Math.log10(5000) # 3.60 Math.log10(10000) # 4.00 </pre> Anvendelsen af logaritmer til komplicerede beregninger er en væsentlig motivation i deres oprindelige udvikling og i dette tilfælde antagelse af nye rater. The Power of Math.pow, ^ eller ** betyder alle at opløfte noget i potents. "POW":http://en.wikipedia.org/wiki/Power_(mathematics) beregner den naturlige logaritme af x ved hjælp af polynomiel interpolation, så ganger med p, beregner e til denne opløftning. Den skal også sikre at begge operander er præcise heltal repræsenteret i double samt at resultatet er et heltal der kan repræsenteres i en dobbelt. I Java bør man undgå denne metoder hvis det lader sig gøre. Kildekoden til Math.pow er kompleks og i floating point. Som alle floating point metoder er resultaterne kun omtrentlige. Hvis du ønsker mere præcise resultater kan man bruge BigInteger eller BigDecimal. Ellers brug Knuth side 462 i "The Art of Computer Programming":http://en.wikipedia.org/wiki/The_Art_of_Computer_Programming bind 2 Seminumerical Algorithms. Den metode, der går tilbage til 200 f.Kr. i Indien. Hvorfor er det vigtigt naturlige tal? Forstil dig en konto med pålydende 1,00 kr. og 100% i rente om året. Hvis renten konteres en gang om året bliver værdien fordoblet til 2,00 kroner. Meget flot. Men hvis renten konteres to gange om året bliver regnestykket til kr. 2.25. Hvis samme rente beregnes kvartalsvis ser regnestykke sådan ud: 1.00 × 1.25^4 = kr. 2.44. Månedlige afkast: 1.00 x 1,083^12 = kr. 2,61. Her er simpel konto konteringsberegning i ruby hvori der bruges POW <pre> 1.00 * (1+((100.fdiv(1)) /100)) ** 1 # 2.0 1.00 * (1+((100.fdiv(2)) /100)) ** 2 # 2.25 1.00 * (1+((100.fdiv(4)) /100)) ** 4 # 2.44140625 1.00 * (1+((100.fdiv(52)) /100)) ** 52 # 2.69259695443717 1.00 * (1+((100.fdiv(400)) /100)) ** 400 # 2.71489174438123 </pre> "Bernoulli":http://en.wikipedia.org/wiki/Bernoulli_number bemærkede at denne sekvens har en grænse for flere og mindre konterings intervaller. Læg mærke til at forskel på kontering mellem uge og dag er minimal. Beregning siger at konteringsintervaller med rente på 1/n pr interval er lig store n, altså e. Dvs at kontinuerlig kontering vil aldrig kunne komme over e = 2,71828182845905. Meget interessant hvis man selv kan styre sin bank forretning. Nu til beregningen af formlen. Tallet jeg skal opnå er "929117.930471227". Og formlen ser sådan ud: <pre> P * (1- (1 / (1+R^Y))) / LN (1+R) </pre> Hvis P er kr. 100000, Y er 10 år og R er li 1.5 procent i rente skal udfald være kr. 929118.- afrundet. Ruby som programmeringssprog er et godt udgangspunkt idet sproget har en syntakst som ligger tæt op af de rigtige formler. Bemærk at opløftning i potents sker ved at **. <pre> P * (1 - (1 / ((1 + R) ** Y))) / Math.log(1 + R) </pre> Java er lidt mere omstændelig at arbejde med men det går sålænge man holder sig til double notationen. <pre> P * (1 - (1 / (Math.pow((1 + R), Y)))) / Math.log(1 + R); </pre> Java med BigDecimal er næsten ulæselig og ser slet ikke ud som base formlen mere. <pre> new BigDecimal(P).multiply(ONE.subtract(ONE.divide((ONE.add(new BigDecimal(0.015))).pow(10)))).divide(new BigDecimal(Math.log(ONE.add(R)))); </pre> Javascript har en lidt anderledes med parenteser og det kan let blive kompliceret. Iørigt lod jeg mærke til at forskellige browser implementation beregnede forskellige hvis der fantes for mange indlejrede parenteser. <pre> var P = 1 - (1 / Math.pow((1 + R), Y)); var balance = P / Math.log((1 + R)); var d = balance * amount; </pre> Oversigt over de resultater fra eksekvering af formlen på de forskellige platforme. | Platform | format | Result | | Javascript | 64-bit IEEE 754 | 929117.9304712246 | | ruby loat | 64-bit IEEE 754-2008 | 929117.930471227 | | java double | 64-bit IEEE 754 | 929117.9304712268 | | java BigDecimal | 64-bit IEEE 754 | 929117.9282152719 | | java BigDecimal | 128-bit IEEE 754 | 929117.9282152719097211956977844238 | Så mens sneen har lagt sig udenfor og temperaturen er langt under frysepunktet kan jeg samle mine tanker. Alle skriver og skriger om at man skal bruge BigDecimal, og tilsvarende ting i andre programmeringssprog, til ting som skal være præcise og især indenfor finans og økonomi. Det er den største gang vrøvl! IEEE 754 floating-point-tal som double og float er perfekte til næsten alle former for beregninger og formler. De tilbyder en vilkårlig præcision og god kompromis mellem hastighed og præcision. Alle beregninger med naturlige tal bruger flydende tal ligesom økonomiske prognoser basseret på trigonometriske funktioner og logaritmer. Det eneste sted jeg kan komme på hvor man gad at bruge BigDecimal er ved møntenhed. I de tilfælde har man nemlig brug for at kunne afrunde med en bestemt afrundingstrategi. Når man operere med naturlige tal går det faktisk ud over præcisionen ved de ikke trivielle beregninger ln, potents, cosinus. På en computer finders der ikke en nøjagtigt metode til at beregne flydende tal. At folk anbefaler at bruge bigdecimal til at udregne kvadratroden vha. Newtons metode der udspringer af konvergerende sekvens af tilnærmelser(konto), knuser min tro på den menneskelige intelligens. Jeg foretrækker at bruge IEEE dobbelt numre, velvidende at jeg kan stole på kun så mange cifre i det endelige resultat, end lever med en illusion af vilkårlig præcision, der bare ikke findes. Du kan skabe en illusion af vilkårlig præcision ved at skære decimalerne af for at løse gåden om 0.1 + 0.1 + 0.1 = 0.3! Når jeg laver prognoser over mit aktieafkast vil jeg have alle decimaler med. Tak. 2010-02-09T13:31:38Z 158 158 true 14 2010-02-10T08:04:27Z Jeg skal udstille en SOAP WebService fra et et lagacy system. Det er en forholdsvis triviel proces med enkelte retninglinjer men bliver ofte til noget overengineered markværk. Min tanke er at det må kunne gøres på en let og clean måde. Efter min mening er begrebet service i forbindelse med IT er desværre druknet i forretningprocesser og total mangle på vision. Mine forbehold er enkle! Jeg gider ikke skrive en WSDL fil og jeg vil helst ikke compilere tusindvis af filer flere måneder før jeg kender kravene til applikationen. Under normale forhold ville jeg være djævlens advokat når det gælder SOA, SOAP, Webservices og andre dødstjerne teknologer. Jeg vil have en service orienteret arkitektur med løs kobling og blød binding mellem komponenterne. Her er klasse med noget opdigtet funktionalitet. <pre> /** * Leagcy business rule */ public class Palindrome { public static boolean isPalindrome(String word) { int left = 0; // index of leftmost unchecked char int right = word.length() - 1; // index of the rightmost while (left < right) { // continue until they reach center if (word.charAt(left) != word.charAt(right)) { return false; // if chars are different, finished } left++; // move left index toward the center right--; // move right index toward the center } return true; // if finished, all chars were same } } </pre> Andrew S. Tanenbaum bog om distribuerede systemer dukker svagt op i min erindring når vi taler om server klient applikationer. Derfor føler jeg det er vigtigt at præcisere context. Det første perspektiv er fra leverandørens(supplier) synspunkt. Rigtig mange problemer opstår i forskellige opfattelse af distribuerede systemer og det kan være svært over tid at skele mellem hvad der er forbruger og leverandør i forskellige forretningsområder. Leverandør processer som har flere afhængigheder fra andre under-leverandører som agere forbruger skal snart omskrives. Første step er at fremstille en service. Jeg kalder processen for BusinessService men i teorien kunne det være hvilken slags forretnings regel eller dataplukning. For at spare taste slag bruger jeg Groovy til service interface. Det statiske metode kald til legacy kassen er verdens værste smutter men sådan er det jo med legacy. <pre> class BusinessService { boolean isPalindrome(String word) { Palindrome.isPalindrome(word) } } </pre> Dette service objekt skal nu omformes til et endpoint. Denne gang bruger jeg groovyWS til at tale SOAP. Bemærk navne-sammenfald i konstruktionen der invokere groovy's dynamiske newinstance metode. Objektet kalder jeg for BusinessServiceEndpoint. Grunden er at jeg forstår at en port på en maskine er et endpoint mens mange forstår alt muligt andet. Måske er jeg for logisk? Logisk er det også at man skal passe meget på sin service stak og ikke mindst rækkefølgen i classpath. <pre> new WSServer("BusinessService", "http://localhost:6900/BusinessService").start() </pre> Det var serverens endpoint. WSDL filen specificere alle nødvendige forhold omkring hvilken muligheder man som WS forbruger kan opnå. Man kan se WSDL filen live på url: http://localhost:6900/BusinessService?wsdl Nu er det tid til at tage det store skridt til højre for at lege forbruger(consumer) af webservice. Som klient modtager jeg en url der peger på et service endpoint. Dette bør være den eneste kobling mellem leverandør og forbruger. Hvis man har brug for mere som fx, et kompilerer jar arkiv, eller andre artifakter er man bundet for hårdt sammen. leverandøren har det med at ændre i sin kontrakt og fjerne dermed grundlaget for alle forbrugere. Løsningen er enkelt, en leverandør push'er successivt alle ændringer til sine forbruger. Eneste forhindring er at man som udstiller af services skal vide hvor mange forbruger man har hvilket totalt ødelægger service tanken. Og Tanenbaum vender sig. * SOA er som et autovaskeanlæg, du kan ikke bruge det uden at vide alt. I morgen er vaskehallen fx kun 1m bred men heldigvis ringer tankpasseren rundt til alle med ændringer. GroovyWS har en fin klient til Webservices. Klienten skal blot have endpoint og en classloader. Instansen kalder jeg proxy fordi den illustrere det objekt som ligger hos udbyderen. Når man kalder initalize generes alle de nødvendige stubs for dig og man kan derefter direkte invokere metoder gennem proxy'en. I dette tilfælde kalder jeg isPalindrome med argumentet otto. <pre> def proxy = new WSClient("http://localhost:6900/BusinessService?wsdl", this.class.classLoader) proxy.initialize() println proxy.isPalindrome("otto") # true </pre> Det fede er naturligvis at der foregår en masse nedeunder som jeg ikke engang gider ta mig af. Men dette var ret nemt fordi jeg jo blot bruger samme teknologi på begge sider af ledningen. Lad og prøve at skifte hele servicestakken på forbruger siden med noget helt andet. I teorien vil leverandøren gerne ha at så mange så muligt benytter de udstillede services fra så mange platforme som muligt. Dette er en af de gode grunde til at man ikke skal lade sine EA kommer med alt for mange gode ideer når de udvikler meget komplekset WSDL'er. Sikkerhed består ikke kun af kompleksitet. Ruby har en 'soap/wsdlDriver' indbygget man kan bruge til at tilgå soap endpoints. Syntakstisk minder det noget om groovyWS og man operere også direkte på en proxy uden at tænke på at afkode WSDL filen manuelt. Evt kan man se metodernavnen i browseren for derefter at invokere dem. Bemærk at argumentet i ruby er en hash fremfor en typed parameter. Hvis servicestakken ændres kan man risikere at skulle bruge andre navne end arg0, arg1 osv. <pre> require 'soap/wsdlDriver' proxy = SOAP::WSDLDriverFactory.new("http://localhost:6900/BusinessService?wsdl") proxy.create_rpc_driver puts proxy.isPalindrome("arg0" => "jruby-yburj") </pre> Indtil nu har vi kun kørt med SOAP version 1.1. Måske er det tid at udstille en soap service i version 1.2. En ESB kan nemt udstille services af begge versioner og det ville være ret cool fremfor at en central admin bestemmer at der kun findes SOAP version 1.2. Ved en sådan fremgangsmåde bliver man ramt af en alt for kraftig binding mellem endpoints og services og har voldsomme implikationer for alle forbrugerne. GroovyWS er ikke klar til soap version 1.2 ud af boksen og det kræver for mange omgåelser så det er tid at skifte til Metro 2.0 for at udstille vores næste service som sjovt nok også er palindrome. Legacy klassen er stadig den samme men service wrapperen er udskifte til en POJO java klasse med JAXB annotationer. Service endpoint interface(SEI). For ethvert defineret interface i WSDL filen kan man generer en SEI. Fra et Java perspektiv kan man sige at wsdl:porttype mapper lige over til en implementation med annotationen @webservice hvor hver operation defineret i wsdl mapper til en metode i SEI. Bemærk at SOAP 1.2 support is added til JAX-WS 2.2 <pre> /** SOAP 1.2 WS service */ @WebService @BindingType(value = "http://java.sun.com/xml/ns/jaxws/2003/05/soap/bindings/HTTP/") public class PalindromeService { @WebMethod public boolean isPalindrome(String word) throws PalindromeServiceException { if (word == null || word.length() < 2) { throw new PalindromeServiceException("No word added!", "Must have a word with length over 2 chars."); } return Palindrome.isPalindrome(word); } } </pre> Nu er den samme legacy kode altså dækket af flere service wrapper med forskellige egenskaber. Jeg kan bedst li Java klasse uden "det tredie sprog" annotationer men okey, det er bedre en rå xml konfiguration. Her er tilføjet en eksplicit exception og et par valideringsregler. Nu kan vi gå direkte til endpoint som også er en Java klasse som kalder et JAX-WS endpoint og publicer en ny service. <pre> public class PalindromeServiceEndpoint { public static void main(String[] args) throws Exception { Endpoint.publish("http://localhost:8080/business/ispalindrome", new PalindromeService()); } } </pre> Grunden til at dette er i Java fremfor Groovy er at jeg ikke vil lade JAXB binde superclass metoder. En groovy klasse har et metaClass interface og det kan JAXB ikke håndter. Dette kan afhjælpes ved brug af af en ekstra annotation. Det virker dog ikke særligt robust på den nye metro distribution og jeg synes det forurener koden at man skal fortælle hvilken objekter der er root. Nuvel, nu findes en service udbyder som har publiseret en service i SOAP version 1.2. Men behøver man ikke vide om den. Vel? Det er nu vigtig at pointere at jeg har kaldt denne post "dynamic" fordi jeg ikke vil tilgå services med en binær afhængighed. Det er ikke hensigten at modtage en *jar fil fra serviceudbyderen som jeg skal lægge i min classpath og kode imod fordi jeg ikke vil rammes af namespace ændringer overalt i min kodebase når næste version kommer. Mit udgangspunkt er at alle i teorien kan benytte denne service ligegyldigt hvilken platform og hvilken teknologi de fortrækker. Jeg vil betragte denne service(endpoint) som et sted at starte og jeg håber at wsdl filen fortæller mig om de næste skridt jeg kan tage. Jeg høre til den nysgerrige type og vil forsøge at forbruge denne service med med udgangspunkt i SOAP beskeden selv, altså "the Envelope". I konvolutten ligger information om sikkerhed, transaktioner og andre, for mig, ligegyldige ting. Klient koden til en soap 1.2 besked med standart Java 1.6 indbygende features. <pre> QName serviceName = new QName(service_namespace, service_name); QName servicePort = new QName(service_namespace, service_port); // Create a service and add at least one port to it. Service service = Service.create(serviceName); service.addPort(servicePort, SOAPBinding.SOAP12HTTP_BINDING, service_endpoint); // Create a Dispatch instance from a service. Dispatch<SOAPMessage> dispatch = service.createDispatch(servicePort, SOAPMessage.class, Service.Mode.MESSAGE); // compose a request message MessageFactory mf = MessageFactory.newInstance(SOAPConstants.SOAP_1_2_PROTOCOL); // Create a message with the SOAPPART. SOAPMessage request = mf.createMessage(); SOAPPart part = request.getSOAPPart(); // Obtain the SOAPEnvelope and header and body elements. SOAPEnvelope env = part.getEnvelope(); SOAPHeader header = env.getHeader(); SOAPBody body = env.getBody(); // Construct the message payload, ant binding type value SOAPElement operation = body.addChildElement(business_method, "ns1", service_namespace); SOAPElement value = operation.addChildElement("arg0"); value.addTextNode(business_args); request.saveChanges(); // Invoke the service endpoint. SOAPMessage o = dispatch.invoke(request); // Get reply content Source sc = o.getSOAPPart().getContent(); </pre> I dette eksempel var en IDE nødvendig både fordi der er alt for meget kode og fordi JAXB bibliotekerne i denne EA version er noget forskellige fra den tidligere. Et par ting der er værd at lægge mærke til: Jeg må bygge et soap xml request på Java's kedelige set get'er metodik. Ydermere, tiltrods for at jeg selv har konstrueret denne service må jeg ind i wsdl filer for at finde navnet hvori input består, isPalindrome(String word) er altså blevet til en række af inputparameter med fortløbende arg0, arg1 osv. Væk er det fine proxy objekt med stub'ens metode navne og hele interaktionen er alt for lowlevel for min smag. Og man bliver nu nødt til at bruge en Transformer for at MOF'e til et model objekt. Klient koden til en soap 1.2 besked med Java 1.6 + Apache CXF. <pre> JaxWsDynamicClientFactory dcf = JaxWsDynamicClientFactory.newInstance(); URL serviceEnpoint = new URL(service_endpoint); QName serviceName = new QName(service_namespace, service_name); QName servicePort = new QName(service_namespace, service_port); // create proxy and genered classes from wsdl Client proxy = dcf.createClient(serviceEnpoint, serviceName, Thread.currentThread().getContextClassLoader(), servicePort); // call method on proxy Object[] res = proxy.invoke(business_method, business_args); // use the new genered class in this classloader Object palindrome = Thread.currentThread().getContextClassLoader().loadClass(business_class).newInstance(); p(palindrome.getClass()); p(palindrome.getClass().getMethods() ); </pre> Ahhh, noget mindre kode men stadig langt mere verbose en klienten med groovyWS. Men jeg fik min dynamiske proxy som svare til objektet på den anden side og det er muligt at kalde metoder direkte på proxy objektet. Hvor kom klient objektet fra? Tja de blev generet af wsgen udfra wsdl filen på samme måde som man ville gøre på normal vis blot runtime. Ved den traditionelle metoder vil model være dekoreret med referacer fra wsgen på compiletidspunkt hvor man med denne metoder først kender service objekterne runtime, dvs at ens model er uden reference til de generede service objekter. Hvilket påpege et helt nyt spørgsmål. Vil jeg arbejde på med en masse generede filer fra WSDL import eller vil jeg mappe en masse værdier i wrapper klasser? Sjovt nok er der ikke en perfekt løsning på nogen af disse problemer. Når et projekt i start fasen beslutter at bruge SOA/Webservices er det ikke fragmenteringen af service der kommer i første række. En regel siger at gamle udkørte lagacy systemer, og forretningens forældede tanke mønstre, specificere det nye service layout. Lad mig gætte, dine services er store WS beskeder og det er kun nødvendigt at kalde ca 5 service for at udføre alle forretnings processer. Hvis du kan svare ja til forgående sætning har du en hård kobling i dit system. Din udviklingsgruppe generet en domain model ud fra WSDL'er og der findes tusindvis af referencer til dine proprietære domain model. Den hurtige siger: vi har en rig domain model med et mapping layer! Okey, fint men samme problematik. Så hvordan opnår man en løs kobling med SOA og WebServices? Kom til at tænke på at man også kunne omskrive legacy klasse til groovy.. <pre> def isPalindrome(String word) { word == word.reverse() } </pre> 2009-09-16T07:45:30Z 147 147 true 14 2009-10-14T11:58:59Z Java er en superstærk platform. Java som programmeringssprog er derimod ved at være rigtig godt slidt. Sun er klar over at deres bedste “cash cow” er ved at løbe tør for fodre, måske derfor de kalder den JDK7 og ikke Java7. Men et er sikkert, Java’s økosystem er en attraktiv platform og den vil overleve i bedste velgående. På denne solide platform kan hostes en masse nye og smarte sprogvariationer som alle har det tilfælles at de kan eksekveres i en Java Virtuel Maskine(JVM). Disse nye sprog åbner op for en masse nye muligheder for vækst mens tidligere investering i platform og infrastruktur kan bevares. Nu er det muligt at vælge platform og programmeringssprog uafhængigt af hinanden og man kan lade applikationens specielle krav om ydelse, hastighed eller samtidighed indgå i valg af programmeringssprog. # Development speed (websites, business) # Parallel computing (mathematical finance) # High volumen applications (twitter, flickr, finance) Ovenikøbet kan de forskellige programmeringssprog kombineres, fx kan man bruge ruby for at speede den daglige udvikling og benytte jruby til at overføre ruby koden til JVM’en for at hente en ydelsesmæssige fordel. Ruby on Rails applikationer kan også bruges som glaslagsapplikationer der ikke kræver ændringer af en eksisterende Java-baserede infrastruktur. Produktive teams kan bruge denne fremgansmåde for at minimere teknisk "friktion" i processerne men også for at opnå de ydelsesmæssige fordele af JVM'en. Twtter applikationer benytter RubyOnRails til UI og Scala til de mest betydningsfulde programdele for at kunne lade dem skalere til maximum. De enkelte dele er løs koblede og kan skaleres og deployes efter specielle egenskaber. Enhvert moderne programmeringssprog bør som minimum have en read-eval-print loop (REPL) hvori man kan skrive evolutionary kode. Om sproget er dynamiske eller statisk, objektorienteret eller funktionelt betyder ikke så meget men de bør være udformet som scriptsprog. Herefter løber vandende hver sin vej hvad angår enkelthed og indlæringskurve. Nogle af de nye sprog tager udgangspunkt i enkelthed og at "de gør som man forventer" mens andre er designede til at undgå sideeffekter for samtidig eksekvering mens andre igen understøtter fx metaprogramming. Ting man kunne klassificere et sprog efter: # Interoperability: Hvordan sameksistere med Java platformen. # Programmringsparadigme: Objekt eller funktionel model. # Trends: Hvilken core egenskab har programmeringssproget. # Integrated: Hvordan integreres med XML, SQL, DSL osv. # Stability: Hvordan er stabiliteten. # Performance: Hvordan er hastigheden i programmeringssproget. # Adoption: Hvor stejl er indlæringskurven # Tool support: Hvad med IDE 's, kode dækning osv. # Deployment : Hvordan fungere det med build, deploy og udrulning En af de sjove ting som skiller sig ud, er tanken om at bidrage med nye ideer og former til programmørene. Java verden lever med den absurde tanke at framework løser alle dine problemer uden man behøver at forstå alle tankerne bagved enhver problematik. Heldigvis finder der en form for udvikling sted. Nogle af de nye “ideer” i de enkelt sprog kan være af stor værdi for udviklingsprojekterne eller/og selve platformen. JRuby JRuby er nok det mest populære alternativ til et JVM sprog. JRuby drives i høj grad af interesse i Ruby og Ruby on Rails miljøet. Ruby's programmeringsmodel og objektmodel er lidt anderledes end Java. Det er nemt at kalde Jruby fra Java og også omvend gennem JSR 223 scripting interface. JRuby kan kompiler ruby kode til Java-bytecode. Ruby’s objekt model understøtter mixin moduler som har samme adfærd som Java interfaces men med implementation. JRuby har også closures, en meget ønsket funktion som der ikke er med i JDK7. Med closures kan man opnå en række functional-style iterative operationer som mapping, filtering, og reducing/folding. Ruby har åbne klasser gennem virtual class og man kan tilføre en metode til en enkelt instans af en klasse. Ruby understøtter ikke funktionel programmering og giver ikke ekstra til samtidigheds problematikken. Ruby er dynamisk og kan udnytte metaprogramming faciliteter. Ruby tillader nem adgang til XML og databaser. Ruby on Rails er legendarisk for at forbedre produktiviteten i web portaler og lettere applikationer. Ruby er et af de bedste sprog til definition af "Intern DSL”. JRuby er stabilt og meget brugt i produktionsmiljø og JRuby menes at være den beste performing ruby platform, bedre end selv Metz native. Ruby syntaks er under forandringer med version 1.9 men migration ikke er nogen udfordring for et åbent sprog. Ruby er let at lære, superb til undervisning og studier. Ruby vil udbygge ens viden om objektorienteret tankgang. Anvendelse af avancerede teknikker såsom metaprogramming kræve dog lidt mere tid. Rubys specelle idioms er lette at forstå og er ret veldokumenteret. Ruby oplever en enorm vækst i nye værktøjer fra fx IntelliJ, NetBeans og Eclipse der alle arbejder på Ruby support og JRuby brugere kan udnytte mange eksisterende Java-værktøjer. Kode analyse og test værktøjer (TDD and BDD) er langt bedre end Java's. JRuby applikationer, og selv Ruby on Rails applikationer, kan indpakkes og deploy som jar eller war arkiver og kræver ikke ændringer af den eksisterende Java-baserede infrastruktur. JRuby er java-bytecode på runtime og kan derfor debugges med JMX osv. Groovy Groovy er et objektorienteret sprog for JVM'en og er et godt alternativ til Java sproget. Groovy er designet specielt til interoperabilitet med Java. Det vil appellere til teams, der ønsker en dynamisk-skrevet sprog, der er tættere på Java end Ruby. Med web frameworket grails, har man en kombination som er sammenlignelig med Ruby on Rails. Groovy er dynamisk typed med egenskaber som ellers findes i python, ruby, perl og smaltalk. Groovy kan bruges som et scriptsprog for Java med en Java li "curly bracket" syntaks der bliver dynamisk kompileret til bytecode og fungere gnidningsfrit med anden Java kode og Java biblioteker. Groovy kompilere kan generer standard bytecode, altså class filer som kan bruges af rene Java projekter. Det mest Java kode er også valid groovy kode. Groovy sproget er stor set et subset af Java. Faktisk kan man omdøbe en .java fil til .groovy fil og den vil med få undtagelser virker. Groovy har en række supercool features som Java ikke kan håndterer. Indlæringkurven for Java programmører er næsten nul, eller nil om man vil. Java folk kan uden videre gå i gang med at lære en mængde nye ting som gør hverdagen meget nemmere. Det er både statiske og dynamiske syntaks, fx metode definitionen def, closures, operator, overloading og native list og associative arrays, maps. Groovy kan gøres langt mere kompakt end Java. Groovy supportere en mængde forskellige integrations komponenter som markup, XML, dom der kan manipulere mange typer af hetrogene data struktureret på en koncis måde. Groovy er fuldt ud stabilt og alle nye landvindinger synes ikke at være et problem idet sprogkernen ligger fast og nye ting berøre kun bibliotekerne. Clojure også har de færreste kendte produktion implementeringer. Performance er i top men kræver et udviklingsteam som kan lide Lisp. Hvis dette tilfældet kan projektledelsen regne med høj produktivitet. Lisp er kendt for at være simpelt sprog, hvor den egentlige læring kommer i at forstå, hvordan man bruger det effektivt! Scala Scala er et statisk-skrevet sprog som understøtter en forbedret objekt model med fuld mixin mekanisme og fuld støtte til funktionel programmering. Scala navnet er en sammentrækning af "skalerbare sprog". Syntaksen ligner en krydsning mellem Ruby (metode definitioner starter med def) og Java (krøllede parenteser). Type inferencing og andre syntaktisk konventioner betydeligt reducere "cluuter", såsom antallet af eksplicitte type erklæringer "annotationer" i forhold til Java. Scala syntaks er meget kortfattet, undertiden endnu mere end ruby! Scala og Java passer godt samme pga “static typing” og “closed” klasser. Det er trivielt at importere og bruger Java API. Direkte API-kald fra Java til Scala understøttes også. Udvikleren har behov for at vide, hvordan navnene på Scala metoder kodning i byte kode. fx Scala metoder kan have "operatør" navne, som "+". I byte-kode, er det "$ plus". Scala's objekt model extends Java's model med traits, som er flexble mixin composition, samme som moduler i ruby. Traits opfører sig som interfaces med implementation. Scala objekt model bidrager med avancerede funktioner til opbygning af "skalerbare” applikationer. Scala understøtter funktionel programmering til JVM, herunder first-class funktion og closures. Andre aspekter af funktionel programmering, som immutable variabler uden side-effekter. Dog er Scala ikke et rent funktionelt sprog. Funktionel programmering er meget effektiv strategi for at skrive treads-safe-programmer der kan håndtere mange samtidige processer. Scala benytter Actor Pattern fra Erlang der er en besked-baserede concurrency model. Actor modellen er nok den bedste general-purpose tilgang til concurrency med multi-threaded processer som skal eksekvere samtidigt. Scala har meget god støtte til opbygning af interne DSL 's, men det er ikke helt så god som Ruby. Scala har et “combinator parser” bibliotek der gør, at man kan konstruere eksterne DSL forholdsvis let. Scala tilbyder også på nogle innovative API 's for XML forarbejdning og Swing udvikling. Scala er over 5 år gamle og er meget stabilt. API og syntaks udvikle sig men alle ændringer sker i biblioteker og ikke det sproget grammatik. Der er nogle velkendte “big load” applikationer fx Twitter der benytter Scala for high performance og volumen. Scala giver sammenlignelige resultater til Java, da det er meget tæt "strukturelt" til Java-kode på byte-kode niveau. Derfor Scala kan udnytte JVM optimeringer, der ikke er tilgængelige til dynamisk-typed sprog. Men Scala vil også drage fordel af planlagte forbedringer for at støtte dynamisk-skrevet sprog, såsom hale-call optimeringer. Derfor har Scala sandsynligvis en marginalt bedre ydeevne end JRuby. Hvis det er sandt, Scala kan være mere tiltrækkende end JRuby som generelt sprog hvor udførelsen er kritisk. Scala er sværere at lære end JRuby fordi det er et mere omfattende sprog. Ikke kun pga af en sofistikeret objekt model men også fordi der understøttes funktionel programmering, type inferencing osv. Efter min mening er den ekstra indsats vil blive belønnet med en højere produktivitet. Også, fordi det er tættere på Java end JRuby og Clojure vil nye brugere vil være i stand til at begynde at bruge det hurtigt som et "bedre objektorienterede Java", mens de fortsætter med at lære de mere avancerede funktioner, som f.eks funktionel programmering, som vil fremskynde deres produktivitet på lang sigt. Scala IDE findes ikke endnu men der er gode plugins. Maven og ANT er almindeligt anvendt som bygge redskab til Scala applikationer ligesom der er adskillige fremragende TDD og BDD biblioteker tilgængelige. Scala applikationer pakkets og installeres ligesom Java-programmer. En Scala runtime jar er påkrævet. Lift er et helt nyt imponerede og elegant framework til webenabling af højtydende applikationer. Lift er bygget omkring vigtigheden af sikkerhed, vedligehold, skalerbart og høj ydeevne. Derudover har Lift stor fokus på høj udviklingsproduktivitet. Lift låner fra de bedste eksisterede frameworks som fx. Seaside og andre egenskaber fra som time to market, CRUD, templates osv. Lift er skrevet i Scala kan man benytte alle Java's API mens deployment og udrulning er lig Java. Clojure Clojure er den af de nye sprogversioner der mindst minder om Java. Sproget bliver kaldt Lisp 2 på grund af sin lisp syntaks og innovative "programmerings model". Clojure er et rent functional sprog uden side effekter. Der findes kun immutable data strukture. Clojure har dynamisk kode fortolkning men er meget hurtigt. Det er den nyskabende og spændende nye JVM sprog syntaks som gør Clojure interessant for mange mennesker. Clojure interop med Java-kode, men skal bliver betragtet som et funktionel programmeringsprog og supportere ikke object-orienteret programming. I stedet beror Clojure på mekanismer som multi-metoder og makroer til at behandle design problemer. Clojure er bygget med transaktions memory der bruger en database-stil transaktion styring til samtidige ændringer af in-memory ændringer. STM. Clojure har også andre innovative metoder til at støtte "principfast" modifikation af mutable data samtidig med at brugen af immutable data. Disse funktioner med STM er grundlaget for Clojure's tilgang til robust concurrency. Clojure har gennemført flere kompiler optimeringer der er vigtige for funktionel programmering, såsom optimering “tail call recursion”. Clojure kan nemt sameksistere med Java men det er svært at kalde fra Clojure til Java, der må man lave proxyies på Clojure siden for at generere den bytecode som Java kræver. Clojure største bedrift er at bringe functional programming med en smart List syntaks til JVM’en med multi-methods, metaprogramming og sikker concurrency. Clojure's kortfattede syntaks og indbygget i biblioteker gøre forarbejdning af XML kortfattede og effektivt ligesom DSL støttes af lisp mekanismer. Clojure er den nyeste scriptsprog på JVM’en men er fuldt ud stabilt og alle nye landvindinger synes ikke at være et problem idet sprogkernen ligger fast og nye ting berøre kun bibliotekerne. Clojure også har de færreste kendte produktion implementeringer. Performents er i top men kræver et udviklingsteam som kan lide Lisp. Hvis dette tilfældet kan projektledelsen regne med høj produktivitet. Lisp er kendt for at være simpelt sprog, hvor den egentlige læring kommer i at forstå, hvordan man bruger det effektivt! Mange Java-værktøjer kan anvendes sammen med Clojure men typisk arbejder man med Emacs som har fremragende lisp støtte. Clojure deployering synes at være så ligetil som for de andre sprog. En Clojure runtime jar er påkrævet. Lidt fra hver Alle sprog kan let kaldes fra eksistere Java kode men det er lidt mere omstændig at kalde fra de respektive sprog til Java. Tættes på er Scala med en objekt model der ser ud som ruby/java layout. Naturligivs gør ruby’s dynamiske giver sproget karakter. Begge extends Java objekt model med mixin komposition gennem modules og traits. Clojure er helt anderledes, med en vægt på funktionel programmering og ikke direkte støtte til objektorienteret programmering. JRuby bringer produktivitet og effekter af et dynamisk-skrevet sprog til JVM, ligesom Groovy. JRuby har også nogle funktionelle idiomer. Scala og Clojure har fuld støtte til funktionel programmering. Scala har en komplet Actor model for concurrency implementeret som bibliotek. Clojure har software transaktionshåndtering af hukommelse og andre nyskabelser som ganranteret robust samtidighed i applikationer. JRuby og Ruby ikke tilføje noget specifikt for concurrency. JRuby og Ruby er specielt god til at skrive interne DSL's. Scala er også meget god og Clojure har fordelene fra lisp's til DSL oprettelse. Alle sprog implementeringer er af høj kvalitet med Scala som den mest modne mens JRuby er mest adopteret i produktion. Performance bør være sammenlignelige for alle, men JRuby og Clojure har at gøre med en vis ineffektivitet ved at eksekvere dynamiske sprog på JVM. Undgå "tidligt optimering", når de skal vælge et nyt sprog. Ofte er team produktivitet og "time to market" langt vigtigere end rå ydeevne. Scala har den laveste barriere for adoption fordi det er det sprog, der mest ligner Java "filosofisk", med statisk typing og vægt på objektorienteret programmering. Nye tilkommer kan starte med Scala som et "bedre Java" og gradvist lære de avancerede funktioner som mixin og funktionel programmering. Scala vil appellere til de fleste teams der foretrækker statisk-skrevet sprog men alligevel ønsker nogle af fordelene ved dynamisk-skrevet sprog, og gerne en kortfattet syntaks. Men Scala er det mest komplekse af de tre sprog, mens Clojure kræver det største begrebsmæssige spring fra Java. Clojure vil appellere til hold som er villige til at udforske mere gennemgribende afvigelser fra det de gør nu. Implementering er nemt med alle tre sprog. Scala er som Java hvor man kompilere koden til class-filer. JRuby og Clojure koden kan fortolkes på kørselstidspunktet eller blive kompileret. Alle udviklingsteams der vil noget mere kan drage fordel af et eller flere moderne sprog men alligevel fuldt ud udnytte de eksisterende investeringer i Java platform. Efter min mening er Groovy er det sejeste sprog ovenpå Java og tilbyder en lang række cool stuff. Scala er måske det nemmeste at vende sig til. JRuby bringer den pulserende Ruby verden til JVM. Clojure tilbyder den mest innovative tilgang til JVM'en. Men der findes et par interessante variationer til: # Fan – En hybrid af den objektorienterede og funktionelle verden. Mange lighedspunkter med Scala, føles ligesom et scripting-sprog. Har en helt anden indgangsvinkel til deling af state og låsning af fælles resources. De fleste andre performance sprog undgår sideeffekter ved at ikke dele state overhoved men FAN er mere som Java hvor flere processer kan dele resourcer og som følge deraf må man låse adgang til dissse resourcer. FAN har Mixins og protype, functions og closures. FAN er hverken statisk eller dynamisk typed, men et sted derimellem. Sproget er ideelt for deklarativ programmering. # Ioke – Et innovativt sprog udviklet af Ola Bini med kæmpe potentiale. Ioke er et stærkt typed dynamisk, prototype baseret objektorienterede sprog. Ioke er bygget med indflydelse fra er Io, Smalltalk, Self, Ruby og Lisp. Sproget eksekveres på en JVM men Ola regner med at kompilere det til JavaScript V8 inden længe. Sproget er specielt udformet til at kunne håndtere “Intern DSL”. Programringssproget skal komme mindst muligt i vejen men også være kraftfuldt nok til at udføre opgaver på højt niveau. Nogle vil måske finde makro-systemet vanvittigt og Ioke er sikkert for udfordrende for gennemsnittet af Java udviklere. # Fortress – Et sprog tænkt som en erstatning for højperformante FORTRAN til industrielle og akademiske "number crunching". og videnskablig ingeniørkunst. Fortress ligner mest Scala Standard ML og Haskell. Sproget er designet til parallelitet med rig funktionalitet i biblioteker. 2009-04-05T23:25:05Z 138 138 true 14 2009-04-10T23:17:29Z Titlen på denne post har jeg snuppet fra et ”white paper” om hastighedsoptimeringer i forskellige J2e applikationsserverer. For nogle år tilbage stod den helt store kamp på applikations markedet mellem ret enkelte egenskaber såsom hastighed, kapacitet eller robusthed. Denne gang har jeg kun fokus på hastighed og specielt en applikationsserver har forsøgt at markere sig som den absolut hurtigste. Under udviklingen nedsatte de nogle gruppe som udelukkende koncentrerede om at finde og afhjælpe hotspots for at finde yderligere hastighed. Under denne arbejdsindsats fandt de på mange tricks og metoder man kan gøre for at optimere både selve serveren men også i de applikationer som hostes af serveren. Konklusionerne er omfattende og komplekst men en enkelt tese munder ud i denne sætning: ”Det koster mere at skabe en ny instans af en klasse, end det koster at have en instans og lave et antal kopier.” Det konkredte problem er at jeg har et ”Command Pattern” der har indkapslet et beregningsmodul. En hver beregning er isoleret og kan leve uden sideeffekter eller delt hukommelse under afvikling. Det uheldige er at beregningerne er koblede gennem et lag med serialisering/deserialisering. Som serialisering tool er valgt XMLBeans og mere end 95 procent af tiden går med at instantiere XMLBeans objekter. Det er ikke et problem jeg vil løse ved at konstruere en ny applikationsserver men blot bruge samme analogi. Jeg har med succes implementering metoden flere gange og fundet betragtelige hastighedsoptimeringer. Hemmeligheden er hotspot compileren. Jeg vil ha hotspot til at clone objekter fremfor at new objekter. Metoden provokere hotspot til at lave effektive genveje melle bytecoden og basic CPU instruktioner. <pre> /** * Static references optimizer * @see http://en.wikipedia.org/wiki/Java_bytecode */ class StaticReferencesOptimizer { private static XMLBean xmlbean = new XMLBeansDummey.create \AllBeans(); } </pre> Ved applikations start vil disse notificeret beans blive instantieret og ved service kald vil compileren blot lave en kopi. Millionvis af kopier med 90 til 95 procent bedre hastighed end ved at lave nye instanser. Det var alt. Alle de XML beans som skal benyttes skal ind i sådan en klasse i en statisk kontekst og den hastighedsoptimering du kan opnå ved så simpelt indgreb vil overraske dig. Selv om dette trick er utroligt enkelt er det langt fra alle mainstream Java programmører som forstår de mekanismer som sker i hotspot compileren. Og heldigvis for det. Fra Java's perspektiv ses en klasse som ikke har referencer til eller fra andre klasser. Det mest normale er at en novice programmør sletter filen. Her kommer disciplin og dokumentation ind i billedet men det er en anden sag. 2009-02-01T04:38:56Z 133 133 true 14 2009-02-01T08:08:52Z Jeg har to problemer! Jeg vil kunne tilføre nye regler og undtagelser dynamisk i en process. Min kode, eller notation skal være sprogneutral og den skal uden videre kunne læses af forretningskyndige. Dette er et par ydmyg krav og opgaven er at overføre policer fra et system til et andet. Konverteringsprocessen løber over flere dage og undervejs vil der komme undtagelser på enkelte policer og nye forretningsregler vil opstå. Det er ikke en option at stoppe, restarte eller deploye applikationen igen for at realisere evt nye regler. Jeg har valgt at isolere en process omkring en pensions-regel på laveste niveau. En pension kan bestå af dusinvis af disse niveauer og en samling af dem udgør en fuld pension. Jeg tager udspring en den eksisterende kode. Det kan være Java, .NET eller andre sprog som er konstrueret i samme programmering model. <pre> DummyPolice police = new DummyPolice(); PoliceLevel level = new PoliceLevel(); level.setPolice(“150364xxxx”); level.setGrundlag(“omregning”); level.setProcent(3); level.setGrundform(212); level.setYdelse(123.340,25); police.add(level); </pre> Udviklere fra den dynamiske eller funktionelle verden er ikke imponeret. En af de første ting man kunne fornemme er en høj grad af syntaktisk støj. I denne situation findes to slags støj, unødvendige forstyrrende elementer, som parenteser, semikolon og lodret skrivemaskineapostrof/tegnsætningsapostrof, og en del repeterende kode som fx “set”. <pre> level.police “150364xxxx” level.grundlag “omregning” level.procent 3 level.grundform 212 level.ydelse 123.340,25 </pre> Hvordan skeler man mellem “set” kontra “get” metode signaturer. En “set” metode modtager input hvorimod en get metode afgiver output! Hvordan bestemmes hvilken type som bliver overført i beskeden mellem objekterne? Når man arbejder med dynamiske sprog er en af de første ting man bemærker og sætter pris på, den mindre betydning som typer udgør. Med mindre systemet fejler er man faktisk ligeglad. Fx police identifikator er en integer, biginteger eller en streng når man som her indføre “xxx” som erstatning for de 4 sidste tal. Hvis man vil have en numerisk værdi skulle “xxxx” udskiftes med “0000”. Denne kode er en Intern DSL hovedsagligt opbygget gennem “DSL Method Chaining” med en tydelig kontekst(DSL Context). Konteksten er en police på laveste niveau. Det betyder at når linjen “procent 3” eksekveres er det af en regel på et police niveau. <pre> police 150364xxxx grundlag omregning procent 3 grundform 212 ydelse 123.340,25 </pre> Ved denne transformation har jeg nu noget business like kode som forretningens domain eksperter kan fortolke. Det er sprog neutralt og fungere som en pensions DSL input. Nu mangler jeg blot at skrive selve DSL fortolker koden, men det vil jeg ikke komme ind på i denne post. De yder omstændigheder gør at dette skal eksekveres på en JVM og med Java SE kan det ikke lade sig gøre. Med Java’s Scripting API JSR223 kan det lade sig gøre. JSR223 Scripting API’et gør det muligt at eksekvere mange former script-sprog på Java platformen. Jeg gider ikke fortælle om de små detaljer da frameworket er ganske lille og super enkelt. Java SE 6 indeholder en javascript-engine baseret på Rhino og det betyder at man kan fortolke dynamisk javascript i Java koden uden at addere ekstra jars. Hvorfor vil man eksekvere script kode internt i Java kode? * Java mangler en dynamiske tilgang * Man kan skabe nye variabler uden at definere en type, man kan skifte type undervejs, typekonvertering sker i mange tilfælde helt automatisk. * Man kan edittere kode og eksekvere, uden brug af rekompilering. * Man kan eksekvere konfiguration scripts, forretningslogik/regler og matematiske udtryk for finansielle applikationer fra en ekstern kontekst. * Man kan invokere “shell” scriptsekvenser i kørende applikationer. Hvis man vil have fortolket andre script-sprog, fx ruby i Java applikationen kræver det at man lægger en jar fil med ruby-script engine i classpath. se nederst på siden for andre muligheder. Når man skal fortolke script sprog undervejs er hastigheden ikke fantastisk! Derfor er der indbygget mulighed for at kompilere et script til bytecode og optimere hotspots. Alle binære script-engiens er bygget med Java SE 6 hvilket gør bagudkompatibilitet irriterende besværligt. Med Java 1.4 er det nærmest umuligt idet der i implementationen er brugt varargs fra Java 5. I Java7 er flere dynamiske API’er på vej fx JRuby, Jython og Beanshell. Det betyder at det er muligt at skrive fx ruby kode i Java kode. Faktisk mangler man så kun at kunne at kunne markere blokke med ruby koden med tags direkte i Java koden. På samme måde som Pascal kunne håndtere assembler i sin tid. Tilbage til eksemplet. Jeg vil udnytte groovy’s smarte og lette notation til denne opgave i en kørende Java applikation så lad os antage at jar filer og fortolker er tilstede i projekt konfigurationen. I teorien kunne det være hvilken af de scriptsprog som understøttes. Nu vil det være muligt at skrive denne kode: <pre> public void run_groovy_code(Sting code) throws Exception { ScriptEngineManager factory = new ScriptEngineManager(); ScriptEngine engine = factory.getEngineByName("groovy"); Object ret = engine.eval(code); assertEquals('this is groovy code', ret); } run_groovy_code("return 'this is groovy code'") </pre> Nu er det altså muligt at overføre kode som eksekveres “on the fly”. Lad os nu antage at Java processen har kørt i flere timer og der kommer forskellige fejl. De bliver listet i en kø og kan browses med en gui. Man kan hente hver enkelt ind og se beskeden og fejl beskeden. Der er også mulighed for at indtaste en regel som kan løse netop denne situation. Det modtagende system kan ikke modtage 212 for ægtefælder, den skal konverteres til 216. <pre> rule if grundlag == omregning && grundform == 212 then grundform 216 </pre> Nu findes den nye regel i systemet og policen kan reeksekveres igen. Hvis køen er smart konstrueret opdager den selv at en ændring er sket og policen submittes ind i systemet mens den nye regel bytter 212 ud til 216 som det modtagne system kan håndtere. Hvis man betragter applikationen som ren scaffolding for forretningsprocesser og forretningsregler kan man invokere et meget tættere samarbejde med de forretningskyldige. Ligeledes kan man separerer/abstrahere forretningsspecifikke regler fra applikationer og dermed også de lange round-trips som vi lider under. En af de store nøgler er at isolere enkelte processer til en niveau hvor det er muligt at skrive en DSL og skabe en mere deklarativ måde at anskue problemerne på-. Processen kan ovenikøbet være interaktiv og tillade at tilføre regler undervejs, måske af forretningen selv. Skønt! JSR223 gør det muligt! Her er en kort liste med et par af de script-sprog som kan eksekveres i Java med JavaScripting API. * BeanShell - Small, free, embeddable Java interpreter * FreeMarker - Java-based general purpose template engine * Groovy - Groovy is an agile dynamic language for the Java * Jaskell - Lazy functional programming language * JavaScript Rhino 1.6R7 based JavaScript script engine. * JEP - Parsing and evaluating mathematical expressions * Jexl - Java Expression Language, expression language engine * JudoScript - Scripting language built on top Java * JUEL - Java Unified Expression Language * OGNL - Object-Graph Navigation Language * Ruby - Best language ever * Scheme - multi-paradigm programming language, one of two main dialects of Lisp * Tcl - Tool Command Language * XPath - Finding information in an XML document * XSLT - language for transforming XML * JavaFX Script - Declarative scripting language * AppleScript - The Language of Automation * Bex script * OCaml - fast, concise and powerful language * PHP * PHP * Python * Smalltalk - Dynamically typed, reflective programming language * CajuScript - Powerfull script to use with Java. 2009-01-16T01:28:21Z 131 131 true 14 2009-03-21T01:40:47Z Jeg er midt i en debugsession i en Java applikation som nægter at virke. Maskinen er en 64bit server med 16 fysiske CPU'er. Efter et par timer går det op for mig at Java’s threadlocal er årsagen. Applikationen køre fint på en dual core maskine hvor CPU’er har fælles hukommelse men kan ikke køre på en maskine hvor alle CPU’er har hver deres hukommelse. Jeg går ud fra at det underliggende operativsystem skifter CPU hvorefter min Java proces mister sin kontekst. ThreadLocal er en slags global variable allokeret til en tråd på en måde så den er synlig for alle objekter der eksekveres i denne i denne tråd. Denne metode benyttes ofte til at binde fx bruger-id eller transaction-id til en tråd og i meget sjældent tilfælde en database forbindelse. I dette tilfælde er det det sidste. Hvis man kigger ind i threadlocal klassen finder man en nøgle med værdien 0x61c88647 og alle nye objekter af denne type tildeles værdien hash_increment plus værdien 0x61c88647. Altså, værdien 0x61c88647 er jo et tal i 16tals formatet og hvis man omsætter det til et decimaltal får man enten 2654435769 eller -1640531527. Det er en 32-bit signed version af den usignerede 2654435769 og er den faktiske værdi som Java bruger til at beregne hash. Tallet repræsenterer ”The Golden Section” eller den gyldne ratio(sqrt (5) -1) gange to til potensen af 31. Check Dr Ron Knott algoritmer og Donald Knuth, de bøger hører hjemme hos en enhver seriøs programmør. Måske også Merck Manual ”adorns your health practitioner's”. Koden for threadlocal en smule kompliceret og jeg må ty til Dr Heinz for en forklaring. Tanken bag tidligere versioner af Java threadlocals var at dele state mellem flere tråde hvilket gør dem praktisk talt ubrugelige for multi-core-applikationer. I Java 1.4, blev et nyt design introduceret hvori threadlocals blev opbevaret direkte i den eksekverede tråd. Når man kalder metoden get() sker det på tråden og der returneres en instans af threadlocalmap som er en slags indre klasse af threadlocal. I teorien skulle en udgående tråd fjerne sine threadlocal værdier lige før garbage collection kaldes med exit() metoden. Hvis vi derimod glemme at fjerne en threadlocal er den stadig berettiget til automatisk garbage collection. Det skyldes en weak references intern i threadlocal til threadlocalmap der har normalt stærke henvisninger til værdier. Et threadlocal objekt bliver garbage collected når den eksekverede tråd dør. Undtagen hvis tråden er blevet trukket ud af en objekt pool som fx i nogle applikationsserverer, i disse tilfælde bliver værdierne aldrig garbage collected. Når et threadlocal objekt bliver garbage collected bliver den svage reference threadlocalmap ryddet. Hvornår bliver det så virkeligt slettet fra threadlocalmap. Når vi kalder get() metoden på en indgang i java.util.WeakHashMap fjernes alle gamle indgange. Hvis vi kalder get() på threadlocalmap går det hurtigere men kan give forældet poster og dermed memory leaks. Når man kalder ThreadLocal set() kan det falde ind under disse kategorier: # hvis værdi ikke findes indsættes den. # hvis vi finder vores nøgle, byttes den med ny værdi. # hvis der ikke er plads til flere værdier. Denne fase bruger en O(log2n) algoritmen i første omgang. # hvis en nøglen er fjernet så er posten slettet. Hvis du ønsker flere oplysninger om, hvordan det virker, kan du få nogle ideer fra Knuth 6.4 AlgoritmeR. Best Practices hvis du absolut vil bruge threadlocals skal du sørge for at fjerne de indsatte værdier når du er færdig med dem, og helst inden du afleverer din tråd til en tråd pool. Den bedste måde at gøre dette på er at bruge metoden remove() i stedet for set(null) som vil medføre at weak reference mappe bliver fjernes straks sammen med værdien. 2008-11-17T22:19:08Z 126 126 true 14 2008-11-17T22:21:13Z Jeg skal hastighedsoptimere en Java applikation. Den skal performe max på kortest mulige tid. Den kan ikke skalere udad som man normalt ville ønske men kun opad. Det vil sige en enkelt supermaskine med 16 CPU'er og 16G ram i 64bit software. I de senere år er kravet om hurtigere CPU hastigheder er faldet mens kravet om antal CPU'er er steget. Grunden er at en hurtig processor bruger mere strøm end to processorer på den samme kraft og man udnytter altså forholdet mellem ydeevne og forbrug. Problemet med at skalere en Java applikation er først og fremmest at Java ikke kan udnytte en ægte multicore arkitektur så den ønskede effektivitet kan opnås. Man kan tilføre så mange CPU'er man vil men Java kan ikke udnytte dem. Dog kan man sige at sige at Java processerne får mere frihed idet de andre processer på maskinen som fx databaser kan køre på andre cores. Selve Java applikationen er en heterogen monolitisk struktur og den skal eksekveres som en 32bit applikation. Det vil sige at den kun kan udnytte 2G hukommelse eller mindre. Det betyder desværre også at man skalere på den laveste fællesnævner. Men hvad sker der når man flytter en applikation fra en dual core maskine til en ægte fysisk 16 core maskine? Min interesse i sagen er kun henvendt på i hvilken udtrækning Java kan udnytte de mange processorer. Hvis Java kun kan udnytte en processor må applikationen kunne køre på samme vis som på andre duals maskiner. Hvad ville der ske hvis Java kunne udnytte flere CPU’er og de enkelte processer udsættes for ægte samtidighed, altså potentielt mange samtidige eksekvererne tråde i samme objekt? To ting vakte min opmærksomhed. Dels en memory leak og dels en slags forvirring omkring konfiguration og resourcer som fx databaseforbindelser. Memory leaks i applikationen skyldes bla ikke frigjorte værdier fra hukommelsen. Den andre adfærd var mere underlig. Applikationen kunne køre skiftevis langt før en tilstand reageret på manglede resourcer. Til min store overraskelses opdager jeg efter flere timers debug session at problemet ligger i ThreadLocal objektet i Java eller rettere dem måde man bruger dem på. Applikations designeren binder databaseforbindelser i disse tråd relaterede objekter. Når en container tråd dør tager den de lokale objekter med sig. Men når 64bit maskinen bestemmes sig for at skifte CPU mister alle threadlocals konteksts. Det betyder at konfiguration og resources bliver frigivet midt i kørselen. ThreadLocal har været en meget brugt strategi gennem mange år og benyttes til at bære fx et ID gennem en applikation både i en tråd men jeg vil påstå at det er et antipattern at benytte den til andet fx databaseforbindelser. læs: Thread-local storage Efter udbedrelse af problemerne køre softwaren fint på 64bit maskinen. Java installationen bruger to, måske tre CPU'er til at eksekvere Java softwaren. Når man skalere er det ønskeligt at kunne skalere lineært, altså ved en fordobling af kraft forøger man hastighed gange to. Reelt set køre denne Java applikation på en af de 16 hurtige CPU ad gange og udnyttelsen af den fine hardware stinker max. Hvis man vil kunne skalere sine applikationer må man skrive dem til multicore. "Small Things, Loosely Joined, Written Fast":posts/122-Small-Things-Loosely-Joined-Written-Fast 2008-11-01T09:51:34Z 124 124 true 14 2008-11-02T22:50:31Z En Java proces har et lineart stigende hukommelsens forbrug. En uheldig arkitektur beslutning afstedkommer en konstant øgning af hukommelses forbrug ved eksekvering af processen. Beslutningen resulterer i en begrænset køretid afhængigt af den valgte mængde af hukommelse hvori processen eksekveres. En proces med ca. 4000 enheder optager ca. femhundrede megabytes. Et anslået estimat på ca. 10.000 enheder vil optage ca. femtenhundrede megabytes og så fremdeles. Det betyder at man skal bruge virkeligt meget hukommelse for at køre programmet færdig. Kan det lade sig gøre og hvad er hukommelse? Alle Java processer eksekveres i en JVM, container, som har automatisk hukommelsesstyring. Den allokerede mængde hukommelsen som er afsat til at indeholde programmet kaldes Heap Memory. Denne container kan dekoreres med flag som bestemmer fordelingen mellem de enkelte hukommelsesområder der allokeres til hver applikation. Der findes forskellige områder eller pools under den fælles betegnelse Heap Memory. Nogle af disse områder holder på nye objekter og andre på gamle. Heap er delt op omkring to hovedområder, heap space og non heap space. * Eden Space - Pulje, hvorfra hukommelse er oprindelig blev tildelt for de fleste objekter. * Survivor Space - Pool indeholder objekter, der har overlevet GC for Paradis rummet. * Tenured generation - Pool indeholder objekter, der har eksisteret i nogen tid i den overlevende plads * Faste Generation - Besidder alle de reflekterende data i den virtuelle maskine selv, såsom klasse og metode objekter. Med JVMs at bruge klasse deling af data, denne generation er opdelt i read-only og read-write områder. * Code cache - Memory anvendes til udarbejdelse og opbevaring af native kode * Perm Gen – Stak eller information om alle de objekter som er placeret i hukommelsen. Den fælles samlede mængde hukommelse er den vigtigste faktor. Men hukommelsen har også direkte indvirkning på garbage collection. GC er den proces som administrer hukommelsen og sikre at de programmører som skriver Java kode ikke behøver at vide noget om allokering af hukommelse. Ydeevnen ved garbage collection hænger tæt sammen med hukommelsen. Når hukommelsen når en vis udfyldings grænse kaldes GC af systemet med jævne mellemrum. Under en garbage collection re-allokeres alle objekter i heap. Nogle objekter flyttes mellem forskellige pools mens andre fjernes helt. Heap vokser eller falder ved hver GC for at bibeholde forholdet mellem fri plads og de levende objekter. Fx indeholder Perm information om objekter i Eden og dermed kan man begynde at ane et mønster om relationer mellem de enkelte rum. Normalt er det god skik at stille JVM MIN til 512m og MAX til det samme. Ved denne indstilling kan systemet starte hurtigt og bruger ikke tid på store re-allokeringer af hukommelse ved GC. <pre> -Xms512m -Xmx512m </pre> Hvis applikationen hænger eller får en ”java.lang.OutOfMemoryError” har man et heap problem. Typisk vil applikationer blot standse helt eller delvist. Hvis man angiver for stor hukommelse vil det tager langt tid at køre GC og derved vil applikationen opleve ”stop and go” funktionalitet med alvorlig forringelse i ydeevne. Applikationer med dynamisk kode og mange klasser som fx GEN, JSP, groovy osv kan blive nødt til at øge MaxPermSize. Den default JVM størrelse for stakken er 64 megabyte. <pre> -Xms512m -Xmx1024m -XX:MaxPermSize=128m </pre> Hukommelsen gemmer objekter og stakken holder styr på oplysninger om objekter. Derfor, jo flere objekter, der findes, jo mere information finder der og jo større stak skal gennemløbes ved hver GC. Efter denne logik fyldes Perm hurtigere hvis din applikation indeholder mange små class-filer frem for få store class-filer. Hvordan sikre man at disse opstarts parameter rent faktisk virker? I Java 5.0 findes et omfattende overvågnings og ledelsesmæssig værktøj. Jconsole er en grænseflader indtil Java Virtual Machine men giver også out-of-the-box fjernbetjening, overvågning og forvaltning. Den bruger omfattende instrumentering af JVM for at give oplysninger om ressource forbrug af applikationer ved hjælp af Java Management Extension (JMX) teknologi.. Man kan lave sine egne beans til overvågning og styring af selvbyggede processer i JVM. En bean skal følger og opfylde JMX design mønstre. En bean kan repræsentere et program eller en ressource som skal forvaltes. Intern i bean findes læse og skrive attributter samt metoder til invokation. En bean kan også udsende meddelelser ved at foruddefinerede begivenheder. Hvis man vil monitorere en remote proces i en JVM kan man tilføje disse –D parameter. <pre> -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=[port] -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false </pre> Derefter er at blot at starte Jconsole og connected under remote fanen. Der findes en række parameter man kan overføre til JVM via -D argument. Men måske må du ser realiteten i øjne og erkende at din applikation har alvorlige fejl som bør løses. * Xmx1500m # Heap size på 1500 MB * Xincgc # Incremental low pause collector. Løbende oprydning af tenured space. * XX:GCTimeRatio=24 # lad JVM selv bestemme sit footprint ud fra en målsætning om at bruge 4% af tiden på GC * Xmn1g # newsize på 1GB, svarer til ratio på 2/3 på jespers server (?) * Xss128k # reducerer størrelsen af stakken ifht. det vi kører med nu mhp. at skabe mere plads til hoben. * XX:+UseConcMarkSweepGC # Concurrent mark sweep collector * XX:SurvivorRatio=10 # Survivor space 1:10 * XX:TargetSurvivorRatio=90 # Bedre pladsudnyttelse af survivor space * XX:MaxTenuringTreshold=15 # Objekter kan overleve flere sweeps førend de bliver flyttet til tenured 2008-10-14T03:32:26Z 123 123 true 14 2008-10-22T22:32:12Z Jeg har lige modtaget en java kildefil fra en kollega med ca. 300 linjer. Jeg vil ikke vise den fordi den er alt for verbose eller lowlevel. Der er en main metode og et par metoder med noget dato fis. I teorien skulle klassen kunne beregne børneydelse og er en del af en større skattepakke der er baseret på Magnus og kan beregne både skat og budget. Det var faktisk noget jeg skulle ha brugt min tid på men min kollega kunne bare ikke gøre for det. Opgaven er jo faktisk sjov når man kan de ret enkelte regler som udgør denne ydelse. Og Java klassen regner rent faktisk korrekt. Det giver til gengæld mig en god mulighed for at abstrahere lidt over noget kode hvilket jeg synes er sjovt. Der hvor kæden hopper af for mig er mængden af kodelinjer brugt på simple konstruktioner. Fint nok, jeg bruger da koden i det forretningsmodul hvori denne funktionalitet skal være men kan ikke lade være at tænke over de implikationer det har på for eksempel drift, vedligehold, videreudvikling osv. Hvad betyder det når få og ret enkelt regler bliver implementeret og fragmenteret ud i 300 linjer procedural kode? Ja til at starte med er det jo ikke enkelt mere. Jo jeg medgiver at alle os der arbejder professionelt med Java tendere til at gøre alting mere komplekst end det i virkeligheden er. Selv vores projektledere kan ikke genkende selv simple opgave efter vi har fundet en lille variation af et kendt teknisk problem som vi lige skal løse først, alle opgaver ender med at være Java problemer. Et andet problem er læsbarhed. Kan jeg i det hele taget forstå koden. Kan koden klassificeres efter kravet om beautyful code (en anden post). Nej, allerede efter ca. 40 linjer gider jeg ikke læse mere. Giver det fremtidige problemer? Ja, for reaktionen er jo at jeg selv vil bygge en helt ny udgave når der kommer en mindre tilføjelse. "Beautyful code":http://www.frankvilhelmsen.com/posts/71-Beautyful-code Et at de vigtigste objektorienterede principper er genbrug. Men meget få tænker i de baner når de udvikler software. Ofte er undskyldningen at der ikke er tid! Pis, hvis der er tid til dårligt design er der også tid til bedre design. Hvordan organiseres logiskesammenhørerne sprog konstruktioner? Skal man fokusere på sproget eller på forretningen? Et andet objektorienteret princip omhandler adfærd og måske ville det være nyttigt at bruge de gamle dyder og give objektet mulighed for at løse sine egen opgaver ved at implementer disse egenskaber i klassen selv. Sproget betyder mindre hvis man implementerer efter objektorienteret paradigmer. Hvis man vil lave god software mener jeg at man må forstå præmisserne om opgaven. En ting som undrede mig var at der i Java koden ikke er brugt datastrukturer til at repræsentere fx, perioder, årgange og kvartaler. Ca. 25% er brugt til simple traversering af dato. Det kan jeg gøre bedre. Faktisk vil jeg definere alle de ting som jeg med sikkerhed ved fra start og binde dem i strukturer. Et andet sted hvor jeg virkelig kan gøre en forskel er omkring selve algoritmen som beregner de næste 12 måneders børneydelse. Java klassen har defineret 100 linjer til denne metode alene. Først findes de næste 4 kvartaler. Dernæst det ultimative stopkriteriet som er at børneydelsen udløber den dag man fylder 18. Sjovt er det at man begynder først på den 20 i næste kvartal efter fødsel. Til slut er det blot at plukke de respektive beløb. <pre> module Childcontribution class Calculate_benefits def initialize(child) @child = child @petite_18_teen_birthday = Date.new(y=@child.year+18, m=@child.month, d=@child.day) @today = Date.today periods quarters ranges end def payment_next_12_month @ydelse = Hash.new(0) @quarters.each do |quarter| y = calculate_age(quarter, @child) if y == 18 if birthday_in_last(quarter) @ydelse[quarter] = calculate_speacial_case(quarter) else @ydelse[quarter] = 0 end else @ydelse[quarter] = @ranges[y] end end @ydelse.each_pair do |key, value| puts "Ydelse pr. #{key} kr. #{value} " end amount = 0 @ydelse.values.collect {|value| amount += value } amount end private def birthday_in_last(quarter) start = @periods[@periods.rindex(quarter)-1] is_birthday_in_last = start < @petite_18_teen_birthday && quarter > @petite_18_teen_birthday end def calculate_speacial_case(quarter) start_date = @periods[@periods.rindex(quarter)-1] puts day_pay = @ranges[@ranges.size-1] / 90 # 2515 / 90 days = @petite_18_teen_birthday - start_date day_pay * days end def calculate_age(quarter, birthday) (quarter - birthday).to_i / 365 end def ranges @ranges = Hash.new(0) (0..2).each { |n| @ranges[n] = 4039 } # 0-2- Årige (3..6).each { |n| @ranges[n] = 3198 } # 3-6- Årige (7..17).each { |n| @ranges[n] = 2516 } # 7-17 Årige end def periods @periods = Array.new() for y in [2007, 2008, 2009, 2010] for m in [1, 4, 7, 10] @periods << Date.new(y=y,m=m,d=20) end end end def quarters @quarters = Array.new(0) # Hash.new(0) for i in 0...@periods.length if @periods[i] > @today for n in i...i+=4 @quarters << @periods[n] end break end end end end end child = Date.new(y=1991,m=1,d=1) calc = Childcontribution::Calculate_benefits.new(child) puts "Next 12 month #{calc.payment_next_12_month}" </pre> 11 2008-06-09T02:52:00Z 112 112 false 14 2008-06-11T22:10:05Z Jeg sider på et projekt og abstrahere nogle skatteberegninger som skal eksekveres i Java. Alt det kryptiske gøjl omkring opsætning og små ligegyldige spidsfindigheder er på plads. Det som holder mig vågen er hvordan jeg skal synliggøre eller promote grænsefladen til disse beregninger for en stribe udviklere. Jeg kan jo bare lade dem konstruere en stribe objekter og invokere set metoder på objekterne. Det er bare så almindeligt og jeg er dødtræt af hele termologien omkring set og get metoder. Jeg kunne også bruge injection framework eller måske factory metoden. Flere af beregninger kan udføre alene men nogle andre er afhængige af delberegninger. Hvordan udtrykker jeg det på en simple og hensynsfuld måde? Alle beregninger kræver forskellige input og nogle resultater er input til andre hvilket medfører en bestemt rækkefølge. Fluent interface kunne være en løsning nu da platformen er Java. Martin Fowler har skrevet flere blogs omkring emnet og de er for det meste fornuftige. Et sandt fluent interface kan være en fornøjelse at bruge. Man behøver ikke huske alle mulige ting om implementeringen og man kan direkte fortolke lingo’en. Fluent interface har levet i lange tider i dynamiske sprog men gode eksempler er der ikke mange af. Fluent interface kan tvinge en til at tænke hårdt over selve forretningen og det det er der jo aldrig tid til. Så hellere lave én dårlig løsning. Nå det handler om Lingo. <pre> Beregn beregn new BeregnImpl(); beregn.befordring(). beregn.fribil(). beregn.skat(); </pre> Dette er en fin løsning og næsten helt deklarativ programmering, men tager ikke højde for input/output og heller ikke for selve eksekveringen. Fluent interface er måske den bedste metode til at gøre statiske Java til et DSL sprog? Måske ikke helt men næsten, der er stadig de grimme parenteser alle vegne og lidt gentagelse men det kan lade sig gøre at skrive noget kode som næsten lader sig læse som plain sprog. Når man arbejder med fluent interface drejer det sig om at opbygge en kontekst der kan opereres på. Så fribil er altså en metode på beregn og fribil returnere samme kontekst osv. At designe et fluent interface er svært, at implementere bibliotekerne bag er endnu sværere. * Skjul dit arbejde. Hvis du hele tiden føler dig nødsaget til at fortælle hvor langt du er kommet er der noget galt. * Hold din kontekst for dig selv. Klienten må naturligt kunne fornemme konteksten. * Eksponer ikke din implementation. Klienten må kun se de valg som findes netop i denne kontekst. * Brug lang tid på navn konvention. Perspektivet er klientens og DSL’en skal udtrykke forståelige koncepter. * Lav flere design. Fly ikke med det første. * Lad aldrig klienter gentage sig selv. Lad mig prøve at gøre det lidt bedre: <pre> Beregn().befordring().fribil().skat(); </pre> Gentagelserne er væk. Desværre kan jeg ikke styre eksekveringen, skal hver metoder invokere en del beregning? Og hvad med input og det faktum at befordring er en del af skatberegningen. Vil jeg sætte input på Beregn(), så input gælder alle beregninger? Behøver jeg en metode til sidst som eksekvere koden? Hvad er output? Mens jeg tænker over dette har min kollega lavet denne presentation om fluent interfaces. "Fluent interface for SQL in Java":http://docs.google.com/Presentation?id=dckns5q8_86hff23tcw 11 2008-05-16T05:44:00Z 111 111 true 14 2008-05-27T00:45:10Z I Java er string konstanter gemt i en intern tabel. Også hvis konstanten findes i flere klasser. Når der findes flere samtidige eksekverende tråde er det udviklerens opgave at beskytte de fælles ressource imod korruption eller sideeffekter. Hvis man har interesse i systemernes performance starter man typisk med at se på CPU, disk, IO og memory forbrug. Hvis ser pænt ud går man videre til at se på tråde og garbage collector aktivitet. Hvis der stadig ikke er fundet en flaskehals har vi med stor sandsynlighed et stridsspørgsmål mellem individuelle tråde. Så lad os kigge på et par problem omkring synkronisering: <pre> String LOCK = "LOCK"; synchronized(LOCK) { ... } </pre> Denne konstruktion er helt normal i Java og beskytter beskytter imod forurening i kodeblokken. Men den fungerer også som flaskehals idet den låser for parallel eksekvering af flere tråde. Java string konstanter bliver gemt i en intern tabel og hvis LOCK objektet eksistere i to klasser vil de realiteten pege på samme instans af string, værdien LOCK. <pre> public class One { private String LOCK = "LOCK"; } public class Two { private String LOCK = "LOCK"; } (one.LOCK == two.LOCK) # true </pre> Her er to klasser med hver deres instans af LOCK, altså to objekter men de peger på samme string. Hvis man produceret String LOCK objektet med metoden new ville det stadig været to forskellige objekter med hver deres string. Men det er stadig en dårlig metode til objekt låsning. <pre> public class One { private String LOCK = new String("LOCK"); } public class Two { private String LOCK = new String("LOCK"); } (one.LOCK == two.LOCK) # false (one.LOCK.intern() == two.LOCK.intern()) # true </pre> De to strenge er forskellige ved sammenligning men hvis vi kalder metoden string.intern() kan man se at det stadig er en reference til selv samme objekt. Det betyder at vi ville med denne fremgangsmåde synkronisere hele systemet på dette ene objekt. Java har mulighed for atomics referencer eller atomics primitiv. Atomics benytter Compare-And-Swap fremgangs måden. Fx med metoden addAndGet(int num) der som udgangspunkt er en optimistisk metode. Hvis der ikke er en konflikt vil den sætte værdien num men hvis der er en konflikt vil den prøve igen. På denne måde kan vi have thread sefe kode uden eksplicit låsning. Men der er stadig et problem idet feltet inden i en atomic er markeret volatile for at forhindre at den bliver sat. Der er dog flere metoder til at minimere risiko for korruption. Fx ved brug af Concurrent-klasserne under collention i stedet for de gamle HashMap, HashTable osv. En ConcurrentHashMap kan partitioneres i buckets for deling mellem klienter. Både synkroniseret metode og synkroniseret blok er til for at kunne låse et objekt. # Synchronized metode En synkroniseret metode vil låse alle objekter. Anvendes når man er sikker på at alle tilfælde vil arbejde på det samme sæt af data via samme metode. # Synkroniserede blok En synkroniserede blok vil låse et bestemt objekt. Synchronized blok anvendes når man bruger kode som vi ikke kan ændre sig selv og tredjepartskode osv. Både synkroniseret metode og blokke bruges til at erhverver en lås til et objekt. Men kontekst kan varierer. <pre> private Object LOCK = new Object(); static ConcurrentLinkedQueue list = new ConcurrentLinkedQueue(); public String getText(@PathParam("cpr") String cpr) { synchronized(LOCK) { list.add("element"); } } </pre> ConcurrentLinkedQueue FIFO (first-in-first-out) er et godt valg når man vil dele adgang til en fælles liste samtidigt fra mange tråde. 11 2008-01-22T00:05:00Z 94 94 false 14 2010-01-15T10:53:16Z Jeg ser frem til at afprøve alle de nye features i Java 7 som snart kommer i de første prebuilds. Men inden da vil jeg her give min sidste uforbeholdne mening om Java op til version 6 som jeg ser det. h4. Stabiliser Java Java som sprog trænger til at blive stabiliseret. En bred skare af personer arbejder på nye sprogkonstruktioner til Java men efter min mening bør de overføre de gode tanker til et nyt sprog. Brug alle dejlige forsøg med closures til Groovy og Scala. Rens ud i boilerplate kode som get/set paradimet, anonyme inner klasser, de lange type deklarationer og dårlig generics. Mit liv er for kort. h4. Java’s anden storhedstid Den ene ting som kunne eksplodere interessen omkring Java igen er at lade JVM’en overtage alle aspekter omkring multithreaded programmering og samtidig deprecare samtlige current pakker. Alle vi programmører har ødelagt nok med vores sublime tanker om samtidighed. Jeg vil eksekvere kode på Intel med 16 cores. h4. The web Indfør én stateful måde at udvikle webapplikationer som kan appellere til 90 procent af brugerne. Web programmering i Java er knækket og stinker big time. Konklusionen er at jeg fra dd. ikke gider Java pre 7. 7 2008-01-15T23:18:00Z 92 92 false 14 2008-01-23T05:30:13Z