Nyhetsflöde

I lösningsförslaget 6.c till tentan från 2012-03-13 står det

"Om (den icke-abstrakta) klassen A ärver från (den icke-abstrakta) klassen B , så kommer ett anrop av en argumentlös konstruktor i A alltid att anropa den argumentlösa konstruktorn i B. Sant"

Men det förutsätter väl att jag inte har deklarerat en argumentlös konstruktor till A i vilken jag anropar super med något argument?

T.ex. ger följande program utskiften "Konstruktor med argument i B":

public class A extends B {
    public A() {
        super(17);
    }
    public static void main(String[] args) {
        A a = new A();
    }
}

public class B {
    public B() {
         System.out.println("Argumentlös konstruktur i B");
    }
    public B(int myArg) {
        System.out.println("Konstruktor med argument i B");
    }
}

Är det något i formuleringen av frågan jag missar?

Du har rätt, strikt sett borde det förtydligats till:

"Om (den icke-abstrakta) klassen A ärver från (den icke-abstrakta) klassen B, så kommer ett anrop av en argumentlös konstruktor i A alltid att anropa den argumentlösa konstruktorn i B, om A:s argumentlösa konstruktor inte explicit anropar en annan konstruktor i B ."

Det här felet uppmärksammades när den kursomgången gick, och vi beslöt att tillåta båda svarsalternativen, även om det senare visade sig inte påverka tentabetyget för någon enda student. Tack för att du pekade ut det, jag ska uppdatera facitfilen för att undvika förvirring mitt i tentapluggandet.

Haha, härligt när ens fråga redan har ställts och besvarats!

Men jag undrar ändå, kan jag inte överskugga konstruktorn (eller vad man nu säger) typ enligt:

public class A extends B {

    int extraField aInt;
    public A() {
        this.aInt = 17;
    }
    public static void main(String[] args) {
        A a = new A();
    }
}

Det vill säga, explicit definiera en ny, argumentlös konstruktor i subklassen och undvika att anropa "super". Anropar detta ändå en argumentlös konstruktor i B, så att säga "innan" min int aInt sätts till 17?

Ja, det gör det. Det kallas constructor chaining och innebär att ingen av superklasserna kommer skapas utan att en konstruktor körs (det är ju ganska rimligt att få en chans att definera alla privata fält i min klass t.ex., även om någon skapar en instans av en underklass). Sista stycket här: http://docs.oracle.com/javase/tutorial/java/IandI/super.html beskriver lite mer vad som händer.

Aha!

Tackar :)

En fråga om 4c på 2012-06-11.
Om man tolkar frågan som att man går in i en try-catch är väl svaret sant?

"The finally block always executes when the try block exits. This ensures that the finally block is executed even if an unexpected exception occurs."

Eller ska man ta hänsyn till: "f the JVM exits while the try or catch code is being executed, then the finally block may not execute. Likewise, if the thread executing the try or catch code is interrupted or killed, the finally block may not execute even though the application as a whole continues."

Saxat från: http://docs.oracle.com/javase/tutorial/essential/exceptions/finally.html

I.o.m. att det står "alltid helt garanterad" så tycker jag att det är rimligt att man ska ta hänsyn till sådana saker. Det kan vara vettigt att vara medveten om att satser i finally inte helt nödvändigtvis körs, om man t.ex. gör nätverksprogrammering mellan klient och server och någon drar ut kontakten ur datorn mitt i ett meddelande kan det vara så att man ändå inte kan sluta snyggt, så man kan inte alltid räkna med det (kopplingen till en klient kan alltså brytas plötsligt om man ser det från serverns perspektiv). Tror det är den (måhända självklara) insikten som efterfrågas.

Just det, man är alltså inte garanterad att finally-blocket körs. Det är viktigt att vara medveten om det om man t.ex vill vara säker på att inte korrumpera logfiler, mm.

På QA-sidan står följande:

"F: När man ansluter till en multipart-konversation, vilket är protokollet för att tala om för servern vilken konversation man vill ansluta sig till?
S: En server kör bara en multipart-konversation. Det är den man ansluter till. Om D vill ansluta till konversationen mellan A, B och C ovan, så gör D detta genom att ansluta på vanligt vis till A. Det finns inget i protokollet som skiljer detta från en anslutning till en annan användare i en tvåpartskonversation. Om man vill kan man låta A skicka ett automatiskt text-meddelande om att D har anslutit till en multipart-konversation med B och C, men det är inget krav."

Dock vill jag från en föreläsning minnas att det sades att en B1-server ska klara att ha både en multipart-konversation och lite singelkonversationer vid sidan av, dvs inte bara vara i "multipart mode". Vilket är det som gäller?

En B1-klient ska kunna köra antingen en multipart, eller flera singel-konversationer.

Om man vill får man lägga till förmågan att ha flera multipart-konversationer, men det är inget krav. Protokollet har inget explicit stöd för att ange vilken multipart-chat man vill ansluta till (bland annat eftersom även en E-klient ska kunna ansluta), så det lämnas till multipart-servern att bestämma självsvåldligt hur den vill hantera inkommande samtal.

"Ett krypterat meddelande ska ha ett okrypterat tagpar av typen <message> som innesluter meddelandet."
Betyder det att man även får lämna attributet "sender='namn'" okrypterat?

Och kan man få anta att alla har unika namn?

Eftersom sender-attributet finns i message-taggen, som ska vara okrypterat, blir alltså även namnet okrypterat.

Man kan inte anta att alla har unika namn. Det är dessutom möjligt att någon bestämmer sig för att byta namn under pågående konversation.

Jag har en fråga om nycklarna för de krypterade meddelandena. Ska man ha en nyckel för varje kryptering (en för AES och en för Caesar) eller en nyckel för varje meddelande, alltså att man genererar en ny nyckel varje gång man krypterar ett meddelande?

Om man skickar med en nyckel i meddelandet så antar man att det är den som ska användas. Om man inte skickar med någon nyckel så antar man att den senast överförda nyckeln används. Om ingen nyckel har överförts, men man vill undvika att skicka med någon nyckel så kan man fråga motparten om en nyckel med en keyrequest. Detta är förstås mest meningsfullt för assymetriska krypton.

En fråga om stilkonventioner. När man kommenterar en rad med kod, får man överstiga 80 tecken per rad eller ska man göra en /* */ kommentar innan raden? Ibland är det svårt att förklara en initiering av något med få tecken.

En längre kommenter skall radbrytas, precis som du föreslår med /*... */

Se utdrag ur stilguiden:

5.1.2 Single-Line Comments

Short comments can appear on a single line indented to the level of the code that follows. If a comment can't be written in a single line, it should follow the block comment format (see section 5.1.1). A single-line comment should be preceded by a blank line. Here's an example of a single-line comment in Java code (also see "Documentation Comments" on page 9):

I C1§5 står "Ett program som stöder kryptering skall givetvis skicka ett lämpligt svar på en nyckelbegäran", betyder det alltså att vi förväntas utöka protokollet på ett lämpligt sätt? Typ lägga till en "keyresponse"-tagg? Eller finns det redan möjlighet att på något sätt meddela alla tänkbara svar på detta, t.ex.:

• stöder inte krypton
• stöder krypton men inte den typen
• stöder kryptotypen, men användaren har inte specifierat (alt. skapat) någon nyckel än (eller ekvivalent använder avbryter specifikationen om man visar en popup)
• stöder kryptot - här är nyckeln

Som jag har förstått det så lades keyrequest-taggen delvis till för att program ska kunna fråga andra program om det stöder krypton, varför är då inte en svarstagg specifierad i protokollet?

En förutsättning är att motparten när som helst (oombedd) kan dela med sig av sina nycklar. Alltså är det ingen skillnad på att besvara en keyrequest och att spontant dela med sig av sina nycklar. Om man stöder kryptot så svarar man med ett meddelande som innehåller en encrypted-tagg, med attributen för typ och nyckel satta.
Om man inte stöder krypto så svarar man helt enkelt inte på keyrequesten, och en timeout tolkas som ett nej. Detta innebär att även E-klienter kan besvara en keyrequest korrekt.
 Acceptabla sätt att besvara era fyra scenarier blir alltså:

• stöder inte krypton: Svara helt enkel inte på keyrequest:en
• Stöder krypton, men inte den här typen: Antingen svarar man inte alls, eller så svarar man med en encrypted med den typen man föredrar.
• Stöder krypton, men har ingen nyckel: Det här borde inte uppstå. Man kan nog anse att programmet inte stöder denna typ förrän nyckel har skapats, se då föregående punkt. Dock tycker jag att ert program alltid borde skapa nycklar vid uppstart.
• Stöder kryptot, här är nyckeln: svara med en encrypted-tagg med rätt typ och nyckel.

Hur man hanterar alternativ 1 och 4 är ganska rättframt. Att det finns flera sätt att besvara alternativ 2 betyder att att man inte kan anta att ett annat program inte stöder krypton alls bara för att de inte besvarar en specifik förfrågan. Ett väluppfostrat program besvarar förstås en keyrequest med en ej stödd sort genom att skicka en nyckel för en typ det stöder.

Hej!

Jag har en fråga gällande disconnect taggen, ska den vara innuti en text tagg eller innuti en message tagg (dvs inte ha någon text tagg i meddelandet)? alltså ska det vara enligt ex 1 eller två (låtsas att attributen till taggarna är ifyllda).

ex. 1 <message><text><disconnect /></text></message>

ex. 2 <message><disconnect /></message>

Hej!
Enligt spec:en blir det tolkning 2.
Om det var otydligt och någon har implementerat enligt tolkning 1, så är det OK, men det borde vara trivialt att ändra i de allra flesta fall.

När är sista datum för att redovisa (eller att för högre betyg kompletteringsredovisa) lab 6 och projektet? 

Sista ordinarie tillfälle är på torsdag, 6:e mars. Om man inte hinner färdigt till dess kan man få redovisa på ett kompletteringstillfälle senare i vår, annars blir det nästa kursomgång, i period 2 i höst.

Och det senare tillfällena gäller även för att höja betyget?

Ja. Dock är det så att om det blir för många som vill redovisa på kompletteringstillfällena, så kommer vi att prioritera de som behöver få godkänt framför de som vill höja ett redan godkänt betyg.

Hej allihop!

När jag tagit emot redovisningar i veckan har ett par problem dykt upp på flera ställen, så jag tänkte att det är lika bra att berätta om dem i förväg. Då kan ni testa och se att det funkar redan innan ni kommer till redovisning ikväll.

• När chatt-klienten kopplar ifrån, ska ett meddelande med <disconnect />-tagg skickas till motparten oberoende av varför programmet kopplar från. Med andra ord, det ska inte spela någon roll ifall användaren avslutar genom att trycka på en JButton, på krysset i hörnet av programfönstret, på Alt+F4, etc... Flera grupper har här antingen krävt att man använder deras Quit-knapp, eller t.o.m. att man kommer ihåg att klicka på en Disconnect-knapp innan man avslutar. Det ska alltså inte krävas - att avsluta programmet på vilket sätt som helst ska fungera likadant.
  
  Om koden är välskriven bör detta vara ett ganska litet ingrepp - se helt enkelt till att koden som skickar <disconnect /> körs när programmet avslutas. Om ni har svårt att få det att fungera, är det också möjligt att deaktivera vissa sätt att avsluta programmet, och t.ex. tvinga användaren att använda er JButton genom att ta bort krysset i hörnet. (Google är er vän...)
  
  
• Flera grupper har också gjort en för enkel lösning på xml encoding, där meddelanden som innehåller taggar skickas och visas korrekt, medan meddelanden som innehåller lite klurigare grejer inte gör det. Ni kan testa med bl.a. föjlande teckensekvenser (en notera att listan inte är uttömmande - det finns andra saker som också ska fungera. Ni måste vara lite smarta! ;) )
• </text>
• &lt;/text>
• <disconnect /&rt;
• &amp;
• &ouml;
• &aelig;

Dessa två grejer ska funka för alla klienter, E-nivå och uppåt. 

Hej! Är övningarna nu i veckan, 27 och 28 januari, "likadana", som under hösten? Dvs en tänkt för fysik och en för CL?

Just det, två för fysik och en för SIMTEK. De tre övningar som går den 27:e och 28:e kommer alltså alla att ha samma innehåll. Enligt schemat är övningen den 28:e avsedd för SIMTEK, men ni är förstås välkomna att komma när som helst.

Perfekt, tack!