doloop

Det har undret meg litt lenge nå.

 

Det er to type threads? Application based og CPU based? Kinda? For CPU'en har, såvidt jeg har fått med meg, som regel 2 threads pr. core.

Men i programmene mine kan jeg jo lage så mange threads som nødvendig. (Man skal vel egentlig klare seg med worker og UI thread, men optimalisering er ikke min greie ).

 

Så er Application Threads og CPU threads to separate ting, og hvordan fungerer det?

Du lager aldri tråder som går på cpuen (med mindre du ligger på os laget). Det er operativsystemet som til enhver tid bestemmer hvilken tråd som kjører. Om du lager 2 eller 400 tråder spiller liten rolle. Du kan som regel hinte til oset hvilket prioritet den bør gi til en tråd, men du kan aldri garantere når den kjører på vanlige operativsystemer.

Som nevnt er Java bakoverkompatibelt, noe annet ville være det samme som å slutt å prøve å være en seriøs aktør i programvarebransjen. Det sagt er det fint mulig for et program å kalle opp funksjoner som er tilgjengelig i gamle java versjoner, men som ikke er tilgjengelige i nye versjoner (feks sun.awt.shell.ShellFolder). Disse klassene får du meldig om å ikke bruke, så en utvikler som velger å bruke disse bør da vite og ha full kontroll over hvilken JRE som blir brukt på maskinen (noe et skrivebordsprogram/applet aldri vil ha).

Det sagt så er det rapportert enkelte bugs med den nye JRE'n som er for aggressive på optimalisering (feks http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7070134) for enkelte litt "sære" programmer. Det er jo mulig bankid benytter et 3djeparts bibliotek som krasjer eller ikke virker korrekt.

Anon derimot velger å være anonyme og de bruker ikke sivil ulydighet som første og ikke siste utvei. Hvis det er slik at man skal bli DDOS'a av en bøling fordi man uttaler seg på en måte eller gjør noe den bølingen ikke liker så vil jeg kalle dem bøller, ikke aktivister.

 

Om målet er å skape en holdnings eller adferdsendring det å fyre opp LOIC like effektivt som å kaste egg på huset til vedkommende. Hvis målet er å føle makt og flokktilhørighet - mission accomplished.

 

Hvis Anon virkelig vil oppnå noe så kan de fjerne maska og organsiere seg, se f.eks Piratpartiet. Evt. kan de fortsette i samme løypa som er ca. like virkningsfullt som facebookgruppeaktivisme.

Du tror vel virkelig ikke anon alltid er anonyme? Det er vel heller man tyr til anonymitet når man har forsøkt alle andre former for protest man man føler man har. Slik som f.eks. å danne et piratparti eller starte en lekkeside.

Det er veldig naivt å tro at alle som er bruker denne aksjonsformen er unge pøbler som ikke er ute etter annet enn å knuse McDonalds ruter eller stenge internettsider. Jeg utelukker ikke at det finnes noen av de også, men det virker veldig usannsynlig at brorparten av disse passer inn i denne kategorien.

Ser ikke helt problemet med det i den store sammenhengen, i norge nektes overføringer til netkasinoer da det er ulovelig. Det wikileaks var inblandet i var også ulovelig i de fleste land inklusive norge.

For øverig tror jeg mesteparten av presset kommer pga sony hackingen, det var grov kriminalitet som påførte selskapet store tap.

 

Internett har gått fra å være en lekegrind til å være en strategisk kominikasjons kanal tilsvarende båter og tog. Er da naturlig at du går etter de som driver med hærverk.

 

Nei å tagge ned t-banen er ikke en godkjent protestform for at billetene er for dyre.

Hvilke ting er det wikileaks er innblandet i som er kriminelt i de fleste land? Wikileaks som organisasjon er jo ikke veldig forskjellig fra feks NTB. Greit de selger ikke nyhetshistoriene sine de gir dem bort, samt kildematerialet som lar leser ikke journalist avgjøre troverdigheten til historien.

Det er greit nok at feks USA ikke liker at deres hemmelige dokumenter blir sluppet til pressen, men Wikileaks som organisasjon gjør ikke noe ulovelig i å slippe nyhetene. Pressens jobb er ikke å beskytte statshemmeligheter, det er statens jobb. Pressens jobb er å fortelle mennesker hva som skjer i verden. Ofte er det mest interessante nettopp ting andre ville holdt hemmelig (feks pentagon papers som New York Times laget historie om i 1971 mens de fortsatt var hemmeligstemplet).

Om protestformer på internett:

Nå er vel det og DDOSe en side litt mer som å binde seg fast til inngangsdør til en forretning eller feks som disse protestantene mot de skumle monstermastene gjør, hindrer andre i å utføre jobben sin. Det er da gyldig protestformer det?

Jeg finner det forøvrig helt ubeskrivelig teit at staten skal være min barnepasser. Jeg satt i forrige uke på Schiphol å ventet i 5 timer på et fly. Jeg så de hadde kasino der, men for at jeg kunne ta ut en 100€ og ha det gøy måtte jeg gå ut av casino til minibanken ved siden av. Hvorfor i allverden skal staten fortelle meg at nei dette er farlig. Dersom en handling ikke skader andre burde det ikke finnes en lov mot den. Om jeg taper 100€ skader ikke det noen andre (ok kanskje indirekte ved at jeg fører verdier ut av norge og inn i Nederland, men om du tenker i disse baner burde vi jo gjøre det ulovlig å reise ut av landet, eller handle fra andre land også).

@doloop: SMART er en protokoll. Dataene som sendes over protokollen er ikke standardiserte, det er et problem. Men nå er opphavet til hele denne diskusjonen at Apple ikke bruker SMART for temperaturstyrt vifteregulering i iMac, derav den noe spesielle løsningen - som OWC faktisk mener kan være et utgangspunkt for utvikling av bedre standarder, om du leser sitatet lenger oppe.

Da er spørsmålet, hva tjener Apple på å istedenfor å tilpasse seg en standard, eventuelt samarbeide med en leverandør (som de gjør med den nye kabelen også) å tilpasse viftestyringen dataene denne leverer. Jeg kjøper ikke engang at dett er et argument, du bytter ikke bort fra sata kabel for å få temperatur levert på en annen måte, da monterer du heller en egen sensor, billigere og enklere for forbruker å forholde seg til. Da får kunden muligheten til å velge andre leverandører, og slipper å kjøpe en disk som ikke koster like mye som ram per gb.

Det er helt åpenbart at Apple ikke har laget denne modifiserte strøm/sensortilkoblingen og harddisk-firmwaren for å "låse meg inne", men for ytterligere å forbedre temperaturstyring, pålitelighet og støynivået i iMac. Apple har ingen ting å tjene på å velge en slik fordyrende løsning, utover at de kan levere et bedre produkt.

Det er vel helt åpenbart at Apple som eneste leverandør enten ikke aner hva de driver med, eller gjør dette akkurat for å låse kundene sine valg inn mot akkurat det de ønsker. Dette tjener Apple på å ikke følge resten av industrien:

1) De låser kunden inne å tvinger han til å betale 2-10 ganger mer enn de måtte på pc plattform.

2) De kan overbevise slike som deg om at Mac er kjempegode på viftekontroll

3) De effektivt kan kontrollere hvem som får lov til å reparere og oppgradere Macer, og dermed kan også ta seg betalt for å bli autorisert "forhandler".

Du får gjerne "peke ut feilene som dukker opp når det oppstår diskusjoner om det rent tekniske rundt mac mot pc" - jeg venter i spenning...

 

Jeg venter også i spenning på at du skal komme med noe med mer substans enn din kones valg av vesker...

 

Forklar gjerne også hva jeg har forsøkt å innbille deg at Apple er, som det ikke er. Der ble jeg usikker på hva du mente, gitt.

Du får komme med noe teknisk annet enn at du synser rundt hva SMART er og leverer.

Jeg føler jeg kommer med langt mer substans når jeg forklarer hva en protokoll er og hvordan kildedataene ikke endrer seg ved å endre protokoll. Hva jeg antydet er at det virker som du tror alle imitasjonene som Apple lager på sine produkter er som følge av at de er mer "avanserte" enn hva konkurrentenes produkter. Dette er rett å slett feil. Du får ha det gøy i fantasiverdenen din.

Newton,

Dette faller vel litt på sin egen urimelighet. Du sier S.M.A.R.T. ikke gir god nok data fra alle produsenter, men SMART er jo kun en protokoll for disken å dele informasjon. Som ATW påpeker blir ikke dataen bedre av å sende den over en annen protokoll. Akkurat som du får samme resultat om du laster ned en fil fra HTTP eller FTP.

Jeg tror virkelig ikke du tror på det du sier selv. Du vet selv at Apple gjør sitt for å låse deg inne. Det er greit, det er jo ikke noe kriminelt i det. Det er tydelig mange forbrukere som er fornøyd med apple. Omfavn det, ikke prøv å bortforklar det, et av apples mange slagord er jo "It just works". Finn heller sterke sider ved Apple istedet for å prøve å bortforklare ting som er helt tydelig for alle.

For meg virker det som fin favoritt teknologiprodusent oppfører seg mer som en moteselger enn noe noe annet, det er greit jeg skal ikke stoppe deg fra å kjøpe det. Men jeg vil peke ut feilene som dukker opp når det oppstår diskusjoner om det rent tekniske rundt mac mot pc.

Vi har alle forskjellig grenser for hvor og når vi velger branding fremfor funksjon, vi er alle forskjellige, jeg ville aldri betale 5000 kroner mer for en veske fordi det står et spesielt navn på den, men min kone kunne finne på dette. Hun prøver dog ikke å fortelle meg at den har plass til så mye mer eller at den tåler så mye mer etterpå. Hun sier hun vil ha den fordi det er det som er inn.

Hvorfor prøver du å innbille oss at Apple er noe det ikke er? Er du usikker på ditt valg?

Du har sagt følgende (du har sikkert sagt mye mer men dette er hva jeg husker)

1) Java brukes ikke i forretningskritiske transaskjoner

Som en som lager ERP system i akkurat java kan jeg fortelle at alle forretningkritiske transaksjoner til de 1000+ selskapene i Norge som kjører vårt system går igjennom vårt Java lag. Det er selvsagt løsninger fra BBS og andre store selskaper involvert også, men alle transaksjoner går igjennom vårt Java lag, og om java laget vårt feiler går de nok ganske raskt konkurs, eventuelt får besøk av staten. Dette inkluderer for eksempel nettbutikker(b2b), vanlig butikker(den største her hadde ommsettning på 200+ millioner i 2009, dette er absolutt et godt antall transer =)), og mindre selskaper.

Dette betyr jo selvsagt ikke at bruken er utstrakt blant andre selskaper, men med tanke på artikkelen om java på Wikipedia høres det ut som bevisbyrden ligger på deg.

http://en.wikipedia.org/wiki/Java_(software_platform)#Web_server_and_enterprise_use

2) Java støttes ikke en i rekke servere (hp, ibm)

Her har du motbevist deg selv

3) Klientsiden er viktig nok for Java til at når en ny konkurrent dukker opp endres hele Java sitt forretningsgrunnlag.

Dette må du faktisk dokumentere, selvfølgelig java vil ha klientsiden, men å hevde at Silverlight kan ha en stor påvirkning på Java sin hele forretningsplan(open source java) er veldig drøyt. Her gjenstår det for deg å komme med dokumentasjon.

Jeg skjønner virkelig ikke hvordan zTPF betyr at java ikke brukes i forretnings-kritiske transaksjoner, men du kan kanskje forklare dette bedre.

z/TPF er noe jeg skal innrømme jeg ikke har mye peiling på, men har nå undersøkt en del de siste 2 timene ihvertfall, i tilegg til å lese litt har jeg snakket med et par som jobber med disse tingene(dog ingen av mine "bekjente" har jobbet mot z/TPF). Jeg har lært følgende (om du har ekspertise på dette område må du gjerne rette meg):

Enhver hardware som kjører z/TPF kan også kjøre z/OS dermed støtter alle IBM server java. Det også vanlig å kjøre z/OS sammen med z/TPF, i en konfigurasjon som lar z/TPF kalle opp z/OS applikasjoner.

Videre forstår jeg zTPF er i prinsippet et minimalt operativsystem for ruting av meldinger til applikasjoner eller for å gå direkte på databasen via småprogrammer (typisk under 4kb i assembly, men større C programmer støttes også nå). Typisk bruk vil være å laste opp en liten blokk assembly kode som skal prosessere en bestemt meldingstype, prosesseringen kan være alt fra å skrive den til permanent lagring, eller å prosessere den for så å sende ut nye meldinger selv. For eksempel meldinger som skal sendes til en java applikasjon. Java applikasjonen kan enten kjøre på samme hardware eller eksternt.

Plattform uavhengihet

Dette var da voldsomt, at java gir deg et lag over os for kall betyr da absolutt at den er mer plattform uavhengig enn for eksempel c++. Ja du kan compile samme kildekode mot forskjellige operativsystemer, gitt at du ikke bruker noen os kall eller biblioteker som bruker os kall. Java har gitt deg et lag som gjør at du aldri trenger å gjøre os kall. Write once run anywhere argumentet er jo absolutt er godt argument. Oracle står for testing av at oppførselen til ditt program vil være lik uansett plattform.

Du er kanskje ikke klar over at IBM er en av de største om ikke den største java støttespilleren utenfor Oracle?

Og jo java støttes i zOS

http://www-03.ibm.com/systems/z/os/zos/tools/java/index.html

Jeg vil legge til det er selvsagt flott at android støtter java så mye som den gjør =)

god natt

Databaser:

Jeg har siden første stund sagt at java ikke kjører på de store databasene i dag, jeg ga deg dog et par eksempler på databaser som kjører java for å vise at det er mulig.

Om IBM og java:

Hva var det med lagdelingen

Java

Os

Hardware

du ikke skjønte?

Silverlight

bla bla bla jeg har rett så det så

Android

Fakta:

• Android kjører ikke java runtime
  
• Android kjører ikke java byte code
  
• Android kan kodes med feks c/c++ via NDK
  
• Android er google
  

• Android gir deg en god del av java bibliotekene
  
• Android kan oversette Java kode til Dalvik kode og kjøre det(såfremt du ikke bruker biblioteker som ikke er tilgjengelig på android)
  
• De fleste koder i Java for så å oversette koden til Dalvik(gjøres gjerne automatisk av IDE)
  

J2mee

Du har forsåvidt rett i at det er et angrep på j2me, men dette er en plattform jeg ser på som omtrent død i dag, og ikke på grunn av silverlight. Det er sikkert fortsatt en del som utvikler mot nokia etc fortsatt, men silverlight er ikke et angrep på ikke smart phone segmentet.

Forøvrig er all annen diskusjon om treghet eller hva annet det skal være det reneste tullball når man tar utgangspunkt i premisser uten rot i virkeligheten.

Det er vel strengt tatt du som setter opp ytelsespørsmålet til å dreie seg 1 kb med kode for å flytte bytes fra a til b. Jeg diskuterer reell ytelse i et stort program, ikke kode som kan spesialsys i assembly etc. Det området som java faktisk lever i. Det er du ikke vi som prøver på dra diskusjonen over på områder som gjelder kanskje 1 promille av kode som er i et prosjekt. Om du skal skrive kode osm skal flytte bytes fra a til b og ingen ting annet, ja da er sikker assembly det smarte. Go for it.

Silverlight har også lite med java å gjøre, det er heller et forsøk på å angripe flash, samt kanskje gi en fremtidig plattform for mobilapplikasjoner.

Jeg ville heller si javaFX var et forsøk fra Sun sin side å angripe Microsoft og Adobe enn at silverlight var et angrep på Java.

.Net var uten tvil et angrep på java, silverlight var ikke det i hovedsak (selfølgelig, alle nye verktøy til en plattform gjør den mer attraktiv, men det var nok ikke tanken "NÅ SKAL VI TA SUN" som lå bak planleggingen av silverlight).

noen banktransaksjoner kjører på den arkitekturen, mens andre ikke gjør det. banker er ganske konservative og mange transaksjoner prosesseres fortsatt på stormaskin f.eks.

OK, la meg prøve en gang til. Så enkelt som jeg overhodet kan få det til:

1. HP's non-stop er ikke den eneste, men det er det beste eksempelet. IBM har naturligvis en konkurrent i dette markedet også. Les mer om det produktet her:

http://www-01.ibm.com/software/htp/tpf/pages/Ztpfoverview.htm

les til øyene dine blir våte om Java-støtten hos IBM.

2. Sannsynligvis kjører alle vesentlige banktransaksjoner i verden på denne type systemer av åpenbare grunner som jeg allerede har forklart deg i klartekst i forrige post.

3. Dette er stormaskiner. Dette er kremeksempler på stormaskiner. Gettit? Når folk du møter referer til stormaksiner er det akkurat slike (eller beslektede systemer med mindre RAS) det er snakk om.

din påstand var at microsofts døende silverlight-teknologi var den viktigste årsaken til at sun åpnet java. min påstand er at jeg ikke tror det stemmer da java-markedet serverside er mye mer verdt og det begynner det å se ut som du også begynner å ta inn over deg.

Når du spurte, sa jeg

Silverlight er siste skudd fra MS for å fremme .net. I det ligger det en umiddelbar erkjennelse av at det er den siste i en rekke skudd mot Java, hor .Net er rammeverket som skal ta Java. Klientsiden representert ved blant annet Android i dag, viser at klientsiden er viktig. Akkurat hvor viktig klientsiden er trenger du litt større briller for å se. Både Canonical og Microsoft innså tidlig at veien til serverrommet gikk via klient. Sun gjorde også i stor grad det, noe som vises ved satsingen på OpenOffice (hvor bruk av Java faktisk har vært omdiskutert, en liten interessant avsporing). Uten klientsiden tror jeg Java ville gått en sakte død i møte, så ja, jeg mener klientsiden faktisk er viktigst.

#1)

Nei java er ikke database språket, ikke vet jeg hva dette har med diskusjonen å gjøre heller.

#2)

Hvilken IBM server støtter ikke java? Java ligger som et lag oppå operativsystemet, du finner java støtte på alle store operativsystemer.

JAVA

OS

HARDWARE

ikke

JAVA

HARDWARE

For litt enklere løsninger enn top 500 maskiner(ingen banker kjører top500 maskiner for banktransaksjoner) har jo iBM også JBOSS, en applikasjons-server som out of the box tar seg av clustering uten noe hassel for utvikler. Det å prosessere banktransaksjoner er ei heller noe som er ekstremt ytelseskrevende (i forhold til feks simulasjoner)

Du kan nå nyte godt av java sin parallellprogrammering (nå har vi jo Clojure også) i motsetning til C.

#3)

Du ser veldig bekymret ut over transaksjonstid, eg vet ikke om du har hørt om JRockit jeg? Transaksjonstid vil typisk ikke bety noe når det er IO involvert. Det er snakk om at java out of the box ikke egner seg på programmer som krever nøyaktighet på millisekundet, ikke for nettverkstransaskjoner.

#4)

Disse diskusjonene har da ingen ting med den originale diskusjonen: Er java et tregt språk?

Til det svarer jeg fortsatt:

Nei java er ikke et tregt språk. Det kan konkurrere med c/c++ kode, dog jeg innrømmer i de fleste tilfeller vil c++ kode yte noe bedre på enkle operasjoner, men du kan finne eksempler der JIT vil la java faktisk slå den. Sitter du å bruker oljefondet på utvikling av programmet kan du sikkert klare å optimalisere koden perfekt i c, eller kanskje bare skrive alt i assembly? Vi må holde oss til den virkelige verden dog.

Den enorme fordelen med java fremfor c og c++, som også er hvorfor det er et av de språkene med mest aktivitet i dag [1], er at det har betydelig lavere utviklingskostnader. Parallellprogrammering er ikke enkelt i noe språk, men java gjør det ihvertfall enklere enn c og c++. Jeg sier ikke at java vil knuse c eller c++ kode (eller c#), jeg sier at det ikke er et tregt språk.

1 = http://lang-index.sourceforge.net/

Morroklump. Det var du som fremhevet forretningskritiske transaksjonsystemer som (det eneste?) markedet Java befant seg i. At java brukes som web-grensesnitt til diverse formål er en ganske annen sak.

Jeg ga faktisk opp å diskutere med deg på grunn av slike holdninger. Du har ingen anelse om hvor java er plassert i markedet, og referer til stadighet til nettbanken din sin innlogging. Dette blir for dumt og useriøst. Du referer også il stråmenn nå ser jeg, men du er jo mesteren av stråmenn; web broser plugin til java funker ikke hos meg, eller java appleten til BBS er dårlig.

Hei

Koden min består av 600 linjer så langt, så poster bare det viktigste her.

 

Her viser jeg bildet kart-final.gif inni en JLabel, som legges direkte inn i en borderlayout senere i programmet.

ImageIcon icon = new ImageIcon("kart-final.gif");
kart = new JLabel(icon);
kart.setBounds(new Rectangle(0, 0, 100, 500));

 

Det jeg har lyst til er å tegne oppå dette bildet. Firkanter som skal representere et areal på kartet. Må jeg bruke BufferedImage? Er ikke redd for å lete opp løsningen selv, men hadde satt stor pris på et hint om hva jeg burde lete etter..

dersom du absolutt vil gjøre custom painting kan du override paint metoden på JLabel

En bedre løsning ville nok være å ikke bruke label til bilde, men heller et panel, for deretter å adde labeles på kordinatene du ønsker som er gjennomsiktige med en border. Da vil du når du møter på neste problem ha (nesten) ferdig løsning for å dra eller velge firkantene etc.

Stigma, implementasjonene er der ute ja, men det er ikke mange som forstår den teoretiske matten som ligger bak rutinen. Hvem som helst kan laste ned kildekoden å se at det virker, å forstå hvorfor er derimot ikke like enkelt.

Det er vel her man kan mistenke at NSA har noen som faktisk forstår matten bak og kan vise til en mulighet for å finne krypteringnøkkelen ut ifra det krypterte innholde uten bruteforce.

Antall kodelinjer betyr jo ikke allverden, men jeg ser ikke helt grunnen til å plassere veldig avanserte programmer på en android plattform. Plassere altfor mye kode ut slik vil jo uansett gjøre jobber tyngre for utvikler enn den trenger å være.

Jeg har planer om etter hvert å tilby mine kunder enkel fakturering og ordre registrering over android (jobber i dag som utvikler på et ERP system), og jeg ser ingen problem med dette. Hva slags avansert funksjonalitet er det du har planer om å plassere på android?

Høres egentlig ut som det er noe som egentlig burde ligge på en server der android kun er en lett gui på toppen av det hele =)

Når det kommer til valgene google har tatt regner jeg med fokus har vært å gjøre ting enklet for relativt ferske utviklere. Regner med de erfarte hvor mye bedre det er å gjøre ting enkelt for nye utviklere enn det er å gjøre det kjempeavansert, men vansklig å starte. Se feks mot iphone og symbian, er helt klart hvilken retning som viste seg best der =)

Hei,

 

Under session 7 ca 5 min ut i filmen løser han 3 problemer under public class BookTest ved hjelp av Quick Fix.

 

Når jeg prøver på det samme får jeg bare opp alternativet

"remove argument to match 'book()'" og rename in file på de andre.

 

Har prøvd å spole litt fram for å se hva han har endt opp med som resultat, men har ikke skjønt helt hva som har skjedd

 

Session 7

Lær deg java ikke snarveiene i en IDE først =)

http://download.oracle.com/javase/tutorial/

Du kan som sagt tideligere ikke sende objekter som parameter igjennom android. Å klage på dette er som å klage på at du ikke kan overstyre operatorer eller arve fra flere klasser. Uansett hvor godt argument eller work around du prøver å finne støttes ikke rutinen. Adapt =)

Dersom du på død å liv ønsker en slags fake constructor kan du subklasse Activity og intent, og sørge for at intenten setter ressursen (til feks en statisk hashmap) og passer nøkkelen til activity, I activityen henter onCreate den opp ressursen for nøkkelen og setter til et felt. onDestroy kan frigjøre ressursen igjen. Generics kan benyttes for å holde rede på Objekt typen om du ønsker å gjøre dette "dynamisk" også, uten tap av ytelse (at det ikke er tap av ytelse tar jeg som en selvfølge, men jeg kjenner ikke google sin implementasjon godt nok til å kunne bevise det).

Dog jeg ville ikke anbefale noe slikt, bare deal med det å benytt enten en global modell alle activities jobber mot eller en dedikert modell for hver activity, der en slags master kan til slutt sy sammen dataen når det trengs.

Hei.

 

Jeg har nå holdt på en stund med en applikasjon. Den sender og tar i mot instruksjoner over Ethernet. Jeg bruker en socket for å få dette til. Jeg lurer nå på om det er noen som har en god metode for en socket reconect? Er det best å lage en metode som sjekker om socketen er aktiv etter en gitt periode, eller er der en metode som automatisk ser at connection er brutt og da kjører aktiverings prosessen på nytt?

 

 

 

Takker på forhånd for svar.

dersom en socket er disconnected når du prøver å skrive til den skal det kastes en IOException

http://download.oracle.com/javase/tutorial/

Har alt du trenger for å lære grunnleggende java. På samme måte som du ikke lærer poker av å lese en bok lærer du ikke java av å lese en bok. Bøkene kan du legge til når du har forstått det grunnlegende og begynner å skrive programmer på mer enn 10 klasser =)

Jeg har utviklet et par enkle programmer, og som du sier er static resource managers eller singletons tingen du er ute etter.

Jeg har ihvertfall i mine android programmer benyttet meg av statiske ressurser. I dag om en use case ikke kan beskrives i en aktivitet ser jeg grundig igjennom om denne usecasen ikke bør endres, men jeg er helt enig at androids måte å håndtere ressursdeling er noe snodig, men tror dette kun er fordi det er annerledes enn hva jeg er vant til.

Ellers her finner du jo hva google sier du skal løse det:

http://developer.android.com/guide/appendix/faq/framework.html

Ellers ville jeg råde deg til å legge igjen avanserte patterns og best practices fra andre språk når du kommer over på android. Lag enkel kode; programmet ditt skal ikke utvides i det uendelige, på mitt første program på android gikk jeg i fellen for å prøve mvp, det endte med at jeg måtte bite i gresset å se hva plattformen var ment for. Det endte opp med kun en model (som jeg holdt statisk), og en viewcontroller per aktivitet. Siden du velger et (i dag ihvertfall) primært mobilspråk er det ikke lagt til rette for og egner seg ikke til avanserte programmer med n funksjoner og egenskaper.

Sun hadde alltid problemer med å ta skrittet helt ut i forhold til åpning av Java-plattformen, og med søksmålet Oracle nå fremmer mot Google er det lite som tyder på at det punktet blir bedre. Språk som C og C++ er derimot svært uavhengige av de store selskapene, selv om VS har vist svak evne til å følge standard innimellom, og stor evne til å putte sine egen bibliotek og utvidelser i miksen.

For det første.

1) Sun har gjordt java apiene opensource, dere applikajsonsserver opensource, deres IDE er opensource, deres database... du ser hvor dette går.

2) Oracle saksøker ikke google for bruk av opensource, de saksøker google fordi de mener Google selger programvare de har gjordt opensource. De ønsker en royalty på googles virtual machine siden de hevder google har kopiert mye av deres VM kildekode. Ikke at jeg er enig i søksmålet, men det er ganske vanlig at man ikke aksepterer at andre selger ditt opensource prosjekt. Dette er heller ei en et angrep på åpen kildekode. Jeg kan dog legge til at oracle og sun er ganske forskjellige selskaper, og at oracles holdning til opensource etter oppkjøpet gjenstår å se.

Det blir svært slitsomt når du forsøker å kverulere deg ut av en så enkel observasjon. Java ble valgt som løsning for bankid, og det nettopp på Java sin hjemmebane, nemlig web-løsninger. Det funker elendig, og er i praksis på ingen måte plattformuavhengig. Det bør du være i stand til å absorbere. Selv nå flere år etter er det 50/50 om bankid funker med åpen java i form av icedtea. Selv med Sun sin egen implementering har jeg (og stort sett hele den norske befolkning som bruker annet en windows) opplevd store problemer.

Mitt poeng er simpelt at vi må skille serverside fra klientside her. Klientside er ikke java veldig god på(og alle er enig i at java applets ikke er noe spesielt bra, dog du finner noen bra her også. Feks NASAs World Wind opengl applet), og bruker som de fleste andre språk vanligvis HTML + javascript for presentasjon. Det er også serverside som er viktig siden HTML +css i dag brukes så å si av alle uavhengig av om det er java, php eller ruby (på .net finner du jo litt silverlight)

Kryptisk betyr ikke nødvendigvis langt, men inkrementeringen du viser der burde få utvikleren til å lure på hva han/hun egentlig forventer at den skal gjøre. Med overlagring av operatorer - noe som mangler helt i Java - så er dette antakeligvis ikke engang overraskende.

Dette har lite med operatoroverstyring, og er en diskusjon jeg ikke ønsker å ta opp siden det finnes like mange meninger som mennesker. Det er uansett frivillig å benytte. Mitt poeng er at kode som har funket i 3 år kan plutselig slutte å gjøre det du forventer.

Når du leser kode er det ikke lett å se slike ting som

i=i++; på linje 412 inne i en loop

Orginalforfatter av koden kan være long gone, eller det kan ha vært deg selv før du visste bedre, det er irrelevant. Problemet oppstår i at feilen kan oppstå lenge etter koden ble skrevet. Det blir vanskelig å finne årsaken til slike feil i ettertid, uavhengig av om orginalforfatter skulle visst bedre. Det naturlige når et program går i stykker er å sjekke de siste endringene.

Da vil jeg heller hevde at det er mer problematisk å skjønne hvordan kopiering av objekter utføres i forhold til tildelingsoperator, kopikonstruktør og med manuell minnehåndtering. Bland inn unntakshåndtering og pthreads, og man har en oppskrift på et tidkrevende mareritt i debuggeren dersom ikke alt er gjort riktig. Likevel så er atferden til disse veldefinert.

Å kopiere objekter i java krever at du forstår hva en referanse er, ikke noe mer. Det burde du forstå før du skriver kode andre skal bruke =)

Jeg misforstod ikke. Bankid har vist at Java sin plattformuavhengighet er rimelig skjelven. Så lenge du holder deg til windows går det gjerne greit. OSX, linux, solaris etc. har vært sjansespill, for ikke å snakke om de forskjellige nettleserne.

Jeg regner med du sikter til Java appleten som nordea blant annet benytter, ikke selve bankid løsningen fra BBS. Det å støtte java applets i en browser har lite med plattformuavhengihet, og mye med integrasjon mot spesifikke programmer. JREen kjører fint, men at browseren er integrert på en god måte er ikke sikkert. Vet ei heller hvem som står for integrasjonen der, om det er sun/oracle eller det er hver og en browser som gjør det selv.

Det sagt skal jeg gledelig innrømme at java applets er elendige; det har heller så å si ingen ting å si i dagens web. Faktisk er Nordeas bankid den eneste appleten jeg kan huske å ha kjørt de siste 5 årene. Du må gjerne kritsere Java applets, men jeg tror ikke du finner så mange som motsier deg.

Jeg har satt meg inn i det du sa. Statistikken du referer til kan ikke oversettes i linjer kode, og dette er gjort klart i lenken. Det som derimot er viktigere er at Java av forskjellige årsaker ofte ender opp som stand-alone prosjekt med lite kodedeling. For meg som foretrekker åpen utvikling er Java en katastrofe, hvilket betyr at alle sitter på hver sin haug og koder opp de samme snuttene om og om igjen. Dette er forsåvidt ikke språket sin feil i seg selv, men det betyr at du finner en rikere verdikjede hos C og C++. Du kan også observere hvilken positiv betydning dette har hatt for Perl og nå har for Python.

Antall linjer kode er et ganske dårlig tegn på populæriteten til et språk, men la gå.

http://www.ohloh.net/languages/compare?measure=loc_changed

Det å anklage java for å være fiendtlig mot open source er jo også en litt snodig anklage...