mboost-dp1
Flickr - Johnnie W@lker
http://www.bphx.com/en/Solutions/Products/Pages/AppBuilder.aspx skrev:
Because AppBuilder uses a platform independent model and generates code for COBOL, Java/J2EE, and C#, your application is easier to maintain for years to come without being dependent on any particular technology.
Hmmm.... et abstraktions lag til sprog der bliver fortolket af en VM- jeg er skeptisk.
Lad os nu se hvor smooth konverteringen går.
Og jeg forstår ikke hvordan man bliver indenpendent af nogle teknologier af det, bliver man ikke nemligt bundet til deres teknologier?
Hvad tilbyder det som java ikke kan?
Jeg stoler på at java også lever om 50 år, og det er til at finde udviklere til. Det gør jeg ikke ved deres appbuilder
Og når java bliver helt open source kan det portes til alle arkitekturer.
Gad vide om de for problemer med performance efter skifter. Alle de steder jeg hsr oplevet et skift fra mainframe til en wintel server løsning er performance faldet drastisk - i enkelte tilfælde til det ubruglige.
Så måske et det billigere i kroner og øre her og nu men over tid vil det blive dyrere fordi det tagere længere tid at lave det samme stykke arbejde......
Så måske et det billigere i kroner og øre her og nu men over tid vil det blive dyrere fordi det tagere længere tid at lave det samme stykke arbejde......
vagn (9) skrev:ja ja lad os nu se der er også andre steder hvor det offentlige kunne spare masser af millioner når så det kommer til stykket så bliver det kun en stor udgift hvor der ikke er en skid der virker og så er der smidt en 500 til 600 millioner væk
Hvilken relevans har det offentlige med en privat virksomheds beslutning om at skifte til et wintel setup fra en mainframe?
COBOL i dag er jo mere batch kørsler, end nyudvikling af hele applikationer.myplacedk (7) skrev:#6
Det lykkedes COBOL. Jeg kan ikke se hvorfor Java ikke skulle. (Jeg ville dog ikke stole på det.)
Java er anderledes. Og med den hastighed JCP kører i, så tror jeg at ikke at Java kommer til at leve længere end 10 år mere.
Men at man bliver ved med at vedligeholde gamle applikationer er et fænomen der ikke ændres ved.
#Java & Open Source
Java er i bund og grund en specifikation.
Men SUN's Java implementation blev open sourcet som OpenJDK med enkelte dele erstattet fordi SUN ikke havde mulighed for at open source dem.
I juni 2008 bestod OpenJDK (i Redhat distrubution) bestående af 100% open source Java 1.6 TCK, hvilket betyder at det er en komplet Java 1.6 implementation.
Java er i bund og grund en specifikation.
Men SUN's Java implementation blev open sourcet som OpenJDK med enkelte dele erstattet fordi SUN ikke havde mulighed for at open source dem.
I juni 2008 bestod OpenJDK (i Redhat distrubution) bestående af 100% open source Java 1.6 TCK, hvilket betyder at det er en komplet Java 1.6 implementation.
#fortsat
Hvis man kan leve med ikke certificeret Java, så er der adskillige andre open source implementationer.
Meste kendte er:
* GCJ & Classpath fra GNU
* Harmony fra Apache
Den sidste er faktisk ret seriøs. Det er primært IBM og Intel som står for udviklingen. Og Google bruger deres library sammen med deres egen Dalvik JVM i Android platformen.
Hvis man kan leve med ikke certificeret Java, så er der adskillige andre open source implementationer.
Meste kendte er:
* GCJ & Classpath fra GNU
* Harmony fra Apache
Den sidste er faktisk ret seriøs. Det er primært IBM og Intel som står for udviklingen. Og Google bruger deres library sammen med deres egen Dalvik JVM i Android platformen.
Windcape (17) skrev:Er målet med Harmony ikke at være certifikeret Java?
Jo.
Men ASF (Apache) og SUN har haft kørende en lille krig omkring adgangen til TCK, så indtil videre er det ikke sket.
Windcape (17) skrev:Og i så fald kan de jo ikke lave forbedringer, da Java specifikationen ikke tillader udvidelser som ikke er godkendt af JCP.
Det mener jeg ikke er korrekt. JCP bestemmer hvad der er Java standarden. Implementeringer som har alt det som er standarden og kan bevise det ved at bestå TCK kan få lov til at kalde sig Java. Men der er ikke noget til hinder for at lave sine egne udvidelser. Selv SUN's implementering kommer med nogle com.sun klasser som man kan bruge hvis man ikke går op i portabilitet.
#Java om 50 år
Det er meget svært at spå om hvordan IT ser ud om 50 år.
Men givet at Fortran, Lisp og COBOL stadig eksisterer idag, så er det vel en rimelig antagelse at Java også eksisterer om 50 år.
Jeg tvivler dog på at det vil være specielt udbredt. Det vil forlængst være erstattet af andre sprog til nyudvikling. Der er simpelthen for hård konkurrence på markedet for den slags sprog.
Sandsynligheden for at Java platformen stadig vil være almindelig til nyudvikling er noget større.
Det er meget svært at spå om hvordan IT ser ud om 50 år.
Men givet at Fortran, Lisp og COBOL stadig eksisterer idag, så er det vel en rimelig antagelse at Java også eksisterer om 50 år.
Jeg tvivler dog på at det vil være specielt udbredt. Det vil forlængst være erstattet af andre sprog til nyudvikling. Der er simpelthen for hård konkurrence på markedet for den slags sprog.
Sandsynligheden for at Java platformen stadig vil være almindelig til nyudvikling er noget større.
Windcape (14) skrev:Og med den hastighed JCP kører i, så tror jeg at ikke at Java kommer til at leve længere end 10 år mere.
Jeg er ikke så overbevist om at:
- sprog der kan alt er godt (PL/I, Ada, C++ er ikke de sprog alle bruger idag på trods af at de har enorme feature sets)
- store ændringer i sprog er godt (Ada83->Ada95, TurboPascal->Delphi, Fortran 77->Fortran 9X var store udvidelser af sprogene, men udbredelsen af sprogene styrtdykkede efter ændringerne, formentligt fordi nye sprog designet fra scratch var bedre end gamle sprog med nye features klistret på)
#24
Det skaffer glade samarbejdspartnere.
SUN kunne sikkert udvikle Java hurtigere, hvis de diktatorisk bestemte alt.
Men det ville koste dem vigtige samarbejdspartnere.
Open source verdenen ville blive ret fornærmede, fordi de er vandt til at alle bliver hørt (lidt forskelligt alt efter hvilket open source prokjekt).
Google satser en del på Java. Det tror jeg ikke at de ville gøre hvis ikke de havde mulighed for også at have indflydelse.
IBM og Oracle har nok ikke rigtigt nogen valgmuligheder idag - de er knyttet til Java for good and for worse. Men da de beslutninger blev truffet for 10+ år siden var muligheden for indflydelse formentligt også en vigtig faktor. JCP havde ganske vist ikke den samme magt dengang, men IBM leverede faktisk 80% af arbejdskraften til de første udgaver af J2EE specs.
Det skaffer glade samarbejdspartnere.
SUN kunne sikkert udvikle Java hurtigere, hvis de diktatorisk bestemte alt.
Men det ville koste dem vigtige samarbejdspartnere.
Open source verdenen ville blive ret fornærmede, fordi de er vandt til at alle bliver hørt (lidt forskelligt alt efter hvilket open source prokjekt).
Google satser en del på Java. Det tror jeg ikke at de ville gøre hvis ikke de havde mulighed for også at have indflydelse.
IBM og Oracle har nok ikke rigtigt nogen valgmuligheder idag - de er knyttet til Java for good and for worse. Men da de beslutninger blev truffet for 10+ år siden var muligheden for indflydelse formentligt også en vigtig faktor. JCP havde ganske vist ikke den samme magt dengang, men IBM leverede faktisk 80% af arbejdskraften til de første udgaver af J2EE specs.
Men Google laver de udvidelser vi har som default i C#/.NET som biblioteker til Java.arne_v (25) skrev:Google satser en del på Java. Det tror jeg ikke at de ville gøre hvis ikke de havde mulighed for også at have indflydelse.
Hvilket gør det meget kluntet at bruge. F.eks. Google Collections er fantastisk, og indeholder ting SUN burde have haft med for 5-8 år siden.
SUN har jo pga. deres økonomiske problemer sat JCP i still-stand i hvad, 5 år nu? Det er dybt problematisk, og giver sproget en dyster fremtid.
Som den anden diskussion kørte på, hvis Microsoft havde gjort .NET multiplatform og Open Source, så ville Java jo netop være "the new COBOL" i dag.
Windcape (26) skrev:
Men Google laver de udvidelser vi har som default i C#/.NET som biblioteker til Java.
Hvilket gør det meget kluntet at bruge. F.eks. Google Collections er fantastisk, og indeholder ting SUN burde have haft med for 5-8 år siden.
Hvis andre er enige kommer de vel også med.
Men indflydelse er jo ikke en ensrettet vej.
Google får indflydelse, men andre får også indflydelse på Googles ideer.
Windcape (26) skrev:SUN har jo pga. deres økonomiske problemer sat JCP i still-stand i hvad, 5 år nu? Det er dybt problematisk, og giver sproget en dyster fremtid.
JCP, SUN og Java har jo ikke stået stille i 5 år.
Java EE 1.5 - Maj 2006
Java SE 1.6 - December 2006
Portlet 2.0 - Juni 2008
JavaFX 1.0 - December 2008
JavaFX 1.1 - Februar 2009
JavaFX 1.2 - Juni 2009
JCR 2.0 - September 2009
Java EE 1.6 - December 2009
Men du kan godt sige at Java SE har været nedprioriteret i forhold til JavaFX og JavaEE.
Og SUN's økonomiske situation har uden tvivl været en medvirkende faktor til at de ikke kunne det hele på samme tid.
#on topic
Er der nogen som har et link til noget mere detaljeret teknisk info.
Artiklen er ret tynd.
Som jeg læser den vil de skifte fra:
4 GL kode---(HPS/AppBuilder)--->IBM Cobol kode---(IBM Cobol compiler)--->mainframe binary
til:
4 GL kode---(HPS/AppBuilder)--->.NET Cobol kode---(Fujitsu Cobol compiler)--->MSIL binary---(.NET CLR)--->Windows binary
Er det korrekt?
Hvad skifter de fra og til som database?
Hvad hardware skal det køre på? (jeg tvivler nemlig på at AppBuilder kan omskrive en failover app til en loadsharing app !!)
Er der nogen som har et link til noget mere detaljeret teknisk info.
Artiklen er ret tynd.
Som jeg læser den vil de skifte fra:
4 GL kode---(HPS/AppBuilder)--->IBM Cobol kode---(IBM Cobol compiler)--->mainframe binary
til:
4 GL kode---(HPS/AppBuilder)--->.NET Cobol kode---(Fujitsu Cobol compiler)--->MSIL binary---(.NET CLR)--->Windows binary
Er det korrekt?
Hvad skifter de fra og til som database?
Hvad hardware skal det køre på? (jeg tvivler nemlig på at AppBuilder kan omskrive en failover app til en loadsharing app !!)
arne_v (29) skrev:#on topic
Er der nogen som har et link til noget mere detaljeret teknisk info.
Artiklen er ret tynd.
Som jeg læser den vil de skifte fra:
4 GL kode---(HPS/AppBuilder)--->IBM Cobol kode---(IBM Cobol compiler)--->mainframe binary
til:
4 GL kode---(HPS/AppBuilder)--->.NET Cobol kode---(Fujitsu Cobol compiler)--->MSIL binary---(.NET CLR)--->Windows binary
Er det korrekt?
Hvad skifter de fra og til som database?
Hvad hardware skal det køre på? (jeg tvivler nemlig på at AppBuilder kan omskrive en failover app til en loadsharing app !!)
Ifølge den her meget lidt informative artikel er det standard server hw de vil flytte det over på
http://www.version2.dk/artikel/14391-banker-droppe...
Windcape (14) skrev:COBOL i dag er jo mere batch kørsler, end nyudvikling af hele applikationer.
Bare på min arbejdsplads har vi flere hundrede COBOL-udviklere. Jeg ved godt COBOL ikke fylder meget i forhold til Java og C#, og sikkert især ikke i din verden. Men der er nu ganske mange aktive COBOL-udviklere verden over, og arbejdsløsheden blandt COBOL-udviklere i Danmark er MEGET lav.
Windcape (14) skrev:Java er anderledes. Og med den hastighed JCP kører i, så tror jeg at ikke at Java kommer til at leve længere end 10 år mere.
Jeg tror nu mest det er en del af de yngste udviklere (som dig), som går så højt op i den slags.
Mange virksomheder prioriterer det absolut ikke højt at have nyeste version, og klarer sig ganske glimrende.
Jeg glæder mig da også til at vi opgraderer fra Java 1.4 på min arbejdsplads, og kan da godt argumentere for nogle fordele ved det. Men fordelen i forhold til arbejdsindsatsen er ret lav, i forhold til så mange andre ting vi kan gøre. Hvis vi faktisk skal have nye features og noget rigtigt brugbart ud af det, skal vi have gang i en større indsats med rettelser i byggesystemet og udviklingsværktøjerne, udformning af standarder og uddannelse. Og den mølle kan vi sagtens tage uden at opgradere udviklingssproget. (Og vi gør det konstant.)
Windcape (14) skrev:Men at man bliver ved med at vedligeholde gamle applikationer er et fænomen der ikke ændres ved.
Hvor går grænsen mellem vedligehold og udvikling? På min arbejdsplads har vi da flere COBOL-udviklere, end COBOL-forvaltere (så vidt jeg ved). Og selv forvalterne bruger en del tid på nyudvikling, mens de venter på problemer der skal løses.
Et stort computer-system bliver typisk aldrig færdigt. Vores system har været under udvikling i over 40 år, og i al den tid er der kun sket mere og mere udvikling. Bare fordi projetet er over et år gammelt, betyder det ikke at der ikke sker nyudvikling.
In 1997, the Gartner Group reported that 80% of the world's business ran on COBOL with over 200 billion lines of code in existence and with an estimated 5 billion lines of new code annually.
Kort sagt: COBOL er over 50 år gammel, og der er LANGT mellem opgraderingerne. Men selv om der ikke startes mange nye COBOL-projekter i dag, så er sproget langt fra dødt. Og jeg vil slet ikke udelukke at det samme kan ske for Java.
I har mange aktive COBOL udviklere, men arbejder de fuldtid i COBOL? Jeg tvivler.myplacedk (32) skrev:Bare på min arbejdsplads har vi flere hundrede COBOL-udviklere. Jeg ved godt COBOL ikke fylder meget i forhold til Java og C#, og sikkert især ikke i din verden. Men der er nu ganske mange aktive COBOL-udviklere verden over, og arbejdsløsheden blandt COBOL-udviklere i Danmark er MEGET lav.
Derudover er arbejdsløsheden meget høj for COBOL udviklere. Fordi de fleste af dem er over 50, og deres viden er meget områdespecifikt, så der er ingen der gider ansætte dem. Virksomhederne vil hellere ansætte en Java/.NET udvikler, og omskole dem.
Og netop fordi COBOL udviklerne typisk er ældre mennesker med familie og børn, kan de heller ikke flytte til de 3 finansbyer, hvor bankerne har deres IT-afdelinger. Det er netop Finansforbundets medlemmer der i stor grad bruger COBOL.
ERP systemerne der i sin tid var bygget på COBOL er mere eller mindre totalt oversæt til Java nu. Der var blandt andet en række projekter hvor COBOL og ALGOL blev maskinoversat til Java.
Nu er bankerne endnu værre end alle andre til at "komme videre". Jeg ved ikke med den bank du arbejder i, men f.eks. i Danske Bank mener ledelsen stadigvæk at IT ikke er centralt for deres virksomhed, og derfor er det ikke særlig højt prioriteret.myplacedk (32) skrev:Jeg tror nu mest det er en del af de yngste udviklere (som dig), som går så højt op i den slags.
Mange virksomheder prioriterer det absolut ikke højt at have nyeste version, og klarer sig ganske glimrende.
Hvilket virker helt urealistisk, da alting kører vha. IT!
Performance, færre fejl, bedre concurrency, og mere moderne arbejdsgange?myplacedk (32) skrev:Jeg glæder mig da også til at vi opgraderer fra Java 1.4 på min arbejdsplads, og kan da godt argumentere for nogle fordele ved det.
Ja, f.eks. at gå over til IBM Rational Developer (= Eclipse) i stedet for en OS/400 terminal. At benytte VSS frem for ikke at bruge VSS, strømline testmiljøer så de er minder besværlige at bruge?myplacedk (32) skrev:Hvis vi faktisk skal have nye features og noget rigtigt brugbart ud af det, skal vi have gang i en større indsats med rettelser i byggesystemet og udviklingsværktøjerne, udformning af standarder og uddannelse.
Der er også flere grunde end hvad du kan forestille dig. Moderne arbejdsgange gør det hurtigere for nye medarbejdere at tilpasse sig, og være produktive.
Og som det er i dag, tager det over et år før at nye medarbejdere kan være produktive i bankernes regi. Det kan sagtens forbedres.
Tænk dig om. Grunden til at bankerne hyrer os i første omgang, er for at vi kan komme med input og viden til forbedringer af arbejdsgangene. Ikke for at vi bare spiller underdanig, og acceptere alting uden kritik.
Så du har faktisk et medansvar for at få indført mere moderne arbejdsgange på din arbejdsplads.
Hvis vi tager de 3 store:
Danske Bank
- Brabrand, Århus
- Ejby (Glostrup), København
Jyske Bank
- Silkeborg
Nordea
- København
Hvilket til sammen sandsynligvis er landets største aftagere af mainframes og COBOL udvikling.
Så at arbejdsløsheden for COBOL udviklere er mindre for folk i region hovedstaden er måske sandt. Men her i Jylland er det langtfra sandt.
Danske Bank
- Brabrand, Århus
- Ejby (Glostrup), København
Jyske Bank
- Silkeborg
Nordea
- København
Hvilket til sammen sandsynligvis er landets største aftagere af mainframes og COBOL udvikling.
Så at arbejdsløsheden for COBOL udviklere er mindre for folk i region hovedstaden er måske sandt. Men her i Jylland er det langtfra sandt.
Windcape (33) skrev:I har mange aktive COBOL udviklere, men arbejder de fuldtid i COBOL? Jeg tvivler.
Det gør du jo altid når jeg fortæller dig noget.
De arbejder lige så meget "fuldtid" i sit system, som udviklere til andre systemer gør. (Og ja, vi har også nogle som arbejder med flere systemer, så vi har fleksibilitet alt efter hvor vi har mest brug for arbejdskraften.)
Windcape (33) skrev:Derudover er arbejdsløsheden meget høj for COBOL udviklere. Fordi de fleste af dem er over 50, og deres viden er meget områdespecifikt, så der er ingen der gider ansætte dem. Virksomhederne vil hellere ansætte en Java/.NET udvikler, og omskole dem.
Vi har nu ellers svært nok ved at finde nogen. Og jeg har i hvert fald sit min andel af gråhårede nyansatte COBOL-udviklere, som ikke har forstand på netop vores system.
Da vi havde problemet for ikke så længe siden, kan jeg roligt påstå, at hvis der var arbejdsløse COBOL-udviklere tilbage i Danmark, var det af andre årsager. Måske ville de ikke køre efter det. (Vi har folk fra Esbjerg, København, Hobro og alt der imellem. Men jeg har da fuld forståelse for at ikke alle vil køre lige langt for at slippe for arbejdsløshed.) Måske er de personlige kvalifikationer ikke gode nok. Hvad ved jeg.
Jeg ved ikke om vi mangler lige nu og her, men i det store billede: Er du en dygtig COBOL-udvikler, og vil du køre efter det, kan du få job hos os.
(Og vi er ikke på Sjælland, så den kan du ikke bruge.)
Windcape (33) skrev:Jeg ved ikke med den bank du arbejder i, men f.eks. i Danske Bank mener ledelsen stadigvæk at IT ikke er centralt for deres virksomhed, og derfor er det ikke særlig højt prioriteret.
Jeg arbejder ikke i en bank, jeg arbejder i en IT-virksomhed. IT er vores eksistensgrundlag. Og i hvert fald vores største kunde (noget der ligner halvdelen af vores indtægter) mener også at (vores) IT er eksistensgrundlag for dem selv.
Windcape (33) skrev:Performance, færre fejl, bedre concurrency, og mere moderne arbejdsgange?
Performance kan vi forbedre på langt bedre måde, end at opgradere Java. Færre fejl, ja, men dælme ikke mange. Jeg tror jeg er stødt på under 1 fejl om året, som ville have været løst nemmere eller undgået helt med en nyere Java. (Og jeg hjælper mange med at løse besværlige fejl.) Concurrency? Nej. Mere moderne arbejdsgange? Nej.
Et mere moderne sprog, som gør nogle udviklere lykkelige i et par dage, og mange andre frustrerede over ændringer. Det er hvad vi får ud af det, på kort sigt.
På længere sigt får vi mulighed for at lave nogle fancy ting, men det er altså meget meget lidt vi får ud af ændringen i sig selv.
Windcape (33) skrev:Ja, f.eks. at gå over til IBM Rational Developer (= Eclipse) i stedet for en OS/400 terminal. At benytte VSS frem for ikke at bruge VSS, strømline testmiljøer så de er minder besværlige at bruge?
Really? Prøver du at komme med forslag til forbedring af et system du absolut intet aner om?
RAD/Eclipse: Bruger vi allerede.
VSS: Haha.
Strømline ting/gøre ting nemmere at bruge: Jeg vil strakt fortælle vores personaleafdeling om dine nyskabende ideer. Forvent et telefonopkald inden kl. 9 på mandag.
Windcape (33) skrev:Moderne arbejdsgange gør det hurtigere for nye medarbejdere at tilpasse sig, og være produktive.
Stating the obvious. Men jeg kan ikke se hvordan opgradering af Java fra 1.4 skulle hjælpe os.
Windcape (33) skrev:Og som det er i dag, tager det over et år før at nye medarbejdere kan være produktive i bankernes regi. Det kan sagtens forbedres.
Jeg tror vi regner med at en helt grøn datamatiker kan tjene sin løn hjem efter et halvt år. Det er det sidste jeg hørte.
Windcape (33) skrev:Tænk dig om.
Det er det jeg siger, dine ideer er nyskabende og revolutionerende. Min aftenbøn vil i dag handle om at jeg vil være mere som dig.
Windcape (33) skrev:Grunden til at bankerne hyrer os i første omgang, er for at vi kan komme med input og viden til forbedringer af arbejdsgangene. Ikke for at vi bare spiller underdanig, og acceptere alting uden kritik.
Og det betyder at man skal opgradere Java, uden at overveje om man kunne få mere ud af indsatsen ved at forbedre andre områder?
Windcape (34) skrev:
Danske Bank
- Brabrand, Århus
[...]
Jyske Bank
- Silkeborg
[...]
Så at arbejdsløsheden for COBOL udviklere er mindre for folk i region hovedstaden er måske sandt. Men her i Jylland er det langtfra sandt.
Og hvis man kan nøjes med at arbejde for den 4. største bank:
Bankdata (Sydbank og mange andre) i Fredericia.
Og hvis man går endnu mindre op i bankens størrelse:
BEC i Herning.
Med Århus, Silkeborg, Herning og Fredericia skulle jeg mene det meste af Jylland er dækket ind, hvis man ikke er kræsen med at køre eller flytte.
COBOL er mest benyttet til batch i dag.myplacedk (35) skrev:De arbejder lige så meget "fuldtid" i sit system, som udviklere til andre systemer gør. (Og ja, vi har også nogle som arbejder med flere systemer, så vi har fleksibilitet alt efter hvor vi har mest brug for arbejdskraften.)
Så hvis du koder 80% Java, og 20% COBOL, så er du vel ikke fultids COBOL programmør?
myplacedk (32) skrev:Jeg ved godt COBOL ikke fylder meget i forhold til Java og C#, og sikkert især ikke i din verden. Men der er nu ganske mange aktive COBOL-udviklere verden over, og arbejdsløsheden blandt COBOL-udviklere i Danmark er MEGET lav.
En hurtig søgning på divce.com siger:
Java 12786
C# 5970
Cobol 594
Men givet at:
- det meste af Cobol udvikling sker i firmaer som har kørt Cobol i mange år
- Cobol udviklere har en relativ høj gennemsnitsalder og skifter mindre job end mange andre kategorier
så er det rimeligt at antage at andelen af Cobol udviklere er markant større end andelen af Cobol jobopslag.
myplacedk (32) skrev:Jeg glæder mig da også til at vi opgraderer fra Java 1.4 på min arbejdsplads, og kan da godt argumentere for nogle fordele ved det. Men fordelen i forhold til arbejdsindsatsen er ret lav, i forhold til så mange andre ting vi kan gøre.
1.4.2 til 1.5 kan godt give lidt arbejde, hvis det skal gøres ordentligt.
Det er næppe et stort problem at rette brug af variabel navn enum, men hvis man principielt vil undgå warnings, så skal der tilrettes en masse kode som bruger collections.
Hvor tit vil man det? Java har så mange latterlige krav for at der ikke er warnings.arne_v (42) skrev:Det er næppe et stort problem at rette brug af variabel navn enum, men hvis man principielt vil undgå warnings, så skal der tilrettes en masse kode som bruger collections.
Windcape (33) skrev:Derudover er arbejdsløsheden meget høj for COBOL udviklere.
myplacedk (35) skrev:Vi har nu ellers svært nok ved at finde nogen.
Mit indtryk er at Cobol viden:
* var stærkt efterspurgt omkring år 2000
* var rimeligt efterspurgt i opgangstiden
* ikke er helt så efterspurgt her under krisen (finanssektoren har strammet noget)
* og vil være ekstremt efterspurgt i fremtiden når en masse Cobol folk går på pension
Windcape (33) skrev:Nu er bankerne endnu værre end alle andre til at "komme videre". Jeg ved ikke med den bank du arbejder i, men f.eks. i Danske Bank mener ledelsen stadigvæk at IT ikke er centralt for deres virksomhed, og derfor er det ikke særlig højt prioriteret.
Danske Bank bruger ca. 5 milliarder kroner om året på IT.
Det synes jeg tenderer at være centralt.
Den warning opstår på samtlige Java klasser, ligegyldig om det er meningen de skal serialiseres eller ej!arne_v (48) skrev:Den warning antyder at nogen persisterer en klasse uden at have gjordt sig nogen overvejelser omkring versions kompabilitet.
Det er fjollet og unødvendigt, og burde håndteres af kompileren.
Java har også andet idioti (typisk i forbindelse med deres elendige implementering af generics), så jeg har svært ved at se hvordan et stort projekt kan være warning fri.
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Nyheder
Gå til bund