Om man vill använda JConsole eller VisualVM för att övervaka en JVM som ligger på en dator som man inte har tillgång till från sin egna dator utan endast via en annan dator som man i sin tur har ssh access till, så kan man sätta upp en lokal SOCKS tunnel som man kör genom mot den remota ssh servern. (Läs mer…)
23 oktober, 2009
VisualVM/JConsole genom ssh SOCKS tunnel
Posted by Anders Hedström under Diverse, J2SE, JMX, Java, Systemutveckling | Etiketter: jconsole, JMX, visualvm |Leave a Comment
17 oktober, 2009
Det finns nu en open-source variant av IntelliJ. Det finns en del begränsningar i den, och när man läser listan förstår man att Jetbrains fortfarande hoppas få in licenspengar från stora kunder: Perforce-stödet (typiskt storprojekts/storföretags-SCM) är ett exempel. Men ändå!
16 oktober, 2009
Vi på Cygni som gillar IntelliJ måste förstås kontra när vi ser sådana här bra Eclipse-tips på bloggen.
Jag kom därvidlag att tänka på s.k. Live Templates i IntelliJ. De är en slags kortkommandon som är kopplade till parametriserade kodsnuttar.
Om man trycker Ctrl+J när man är i en Java-fil, så får man se något i den här stilen:
Listan över Templates
Man kan begränsa listan genom att skriva en del av ett kortkommando (t.ex. ”it”) innan man trycker Ctrl+J. Efter ett tag lär man sig förstås kortkommandona utantill – då är det bara att skriva ”itar” eller vad det nu är och sedan trycka Ctrl+J så får man sin kodsnutt.
Detta vore inte så märkvärdigt om det inte vore för det faktum att man kan skapa sina egna Live Templates.
7 oktober, 2009
Save Actions i Eclipse
Posted by Tommy Wassgren under Eclipse, Java, SystemutvecklingLeave a Comment
Vi har tidigare diskuterat lite sköna snabbkommandon för Eclipse i inlägget Eclipse Tips och Tricks. Då nämndes bland annat Ctrl-Shift+F för att formatera koden och Ctrl+Shift+O för att organisera importer.
I Eclipse finns något som kallas för Save Actions under Window -> Preferences och sedan Java -> Editor -> Save Actions. Där kan man ställa in en hel del saker som automatiskt ska ske när du sparar en fil exempelvis:
- Formatera koden enligt dina inställningar
- Organisera importer / ta bort onödiga importer
- Sortera medlemmar (metoder och attribut)
- Ta bort ”trailing whitespace”
- Fyll ut med måsvingar och parenteser där det saknas
- Ta bort onödiga castningar
- etc
Om du gillar att ha ordning och reda i dina källkodsfiler kan jag rekommendera detta. Det är dock viktigt att man bestämmer vilka formateringsregler som ska gälla i det aktuella projektekt och att alla använder dessa regler. Annars kan filerna förändras för mycket mellan varje incheckning. Om någon exempelvis använder tabbar och någon annan använder mellanslag så kommer filerna att diffa stort fast man kanske bara har gjort en mindre förändring.
Självklart kan detta arbetssätt vara problematiskt ifall du sitter i en existerande kodbas som inte är bra formaterad – varje ”Save” kan leda till att den aktuella filen förändras kraftigt på grund av formateringen och det kan det bli svårt att se vad som egentligen förändrats i filen mellan två versioner. Detta är ju dock ett problem som försvinner över tiden eftersom alla filer så småningom är formaterade.
4 september, 2009
Accesskontroll på paketnivå
Posted by Mikael Thorsson under Diverse, Java, Systemutveckling1 Comment
En av de kraftfullaste delarna av objektorienterade språk är deras väl utbyggda stöd för inkapsling (encapsulation). Inkapsling i sin tur är en av de allra viktigaste sakerna att tänka på när man designar och skriver programkod. En applikation som består av komponenter som publicerar rena gränssnitt och gömmer implementationsdetaljer har oerhörda fördelar framför sådana som inte gör det: Man kan utveckla, förstå, testa, debugga, optimera och underhålla komponenterna separat, vilket gör alla dessa saker mycket lättare.
De flesta javautvecklare känner väl till Javas system med modifierarna public, protected och private samt det implicita ”package private” som man får om man inte skriver någon modifierare alls. Modifierarna fungerar olika beroende på var man använder dem någonstans:
Tabell över modifierare från Suns hemsida
Gundtipset när man väljer modifierare är förstås att välja så låg accessnivå som möjligt. På klassnivå bör instinkten således vara att göra alla medlemmar som inte är en del av klassens API private. Endast om klassen är specifikt avsedd för att ärvas från, sätter man lämpliga metoder till protected. Frågan om arvets vara eller inte vara är en historia i sig – kanske kommer det en artikel om det också.
När jag tittar på kod som andra har skrivit, tycker jag att detta tankesätt verkar vara rätt väl inarbetat – på klassnivå. Och här kommer min huvudsakliga poäng.
Men hur tänker man på paketnivå?
Ofta ser man paketstrukturer av den här typen:
Klassen MainApi exponeras korrekt eftersom den utgör modulens API. ApiImpl är en hjälpklass till MainApi som inte skall exponeras, så den är package private. Paketet com.foo.api.util är konceptuellt ett ”underpaket” till com.foo.api. Underpaketet innehåller en delmängd av den kod som utgör huvudpaketet, men det känns bra att gruppera klasserna på något sätt. Här har vi dock ett problem! För att klasserna i com.foo.api skall komma åt hjälpklassen i underpaketet så måste den vara public
Dessvärre har Java i dagsläget inte stöd för ”underpaket”. Således har vi exponerat en klass som egentligen är en del av vår moduls inre angelägenheter för omvärlden. Hur löser man då detta? Jo:
- Börja med att konstatera att även paket, inte bara klasser exponerar ett API.
- Lägg saker som hör ihop i ett paket. Det finns inga underpaket i Java!
- Kom i håg att så fort du gör en klass
publicså blir den del av paketets API, och utvecklaren blir för evigt styrd av den klientkod som väljer att använda klassen.
…eller så uppgraderar man till Java 7, för där finns något som heter ”super packages”, som troligen löser detta problem en gång för alla.
