---

Jeg er ved at lave en hjemmeopgave i Java. (nybegynder)

Jeg har fx
===============
public class Ansatte {
String navn;

Ansatte() {
navn = new String("unknown");
}
void setNavn(String na) {
navn = na;
}
===============

Dette virker bare ikke. Er der en måde hvorpå jeg kan få ændret en oprettet
String? Hvis jeg bruger StringBuffer virker det fint men den passer ikke
særlig godt til ddet jeg skal lave + opgaven er stillet med klassevariablen
navn som String. Der forskrives også at "navn" skal have en set funktion.

Så mit egentlige spørgsmål er hvordan jeg får lavet en set funktion for en
variable af typen String.

Mvh
Anders

---

Jeg ved ikke helt hvor den er gået galt for dig, men jeg har tilladt mig at
kopiere din kode ind i en fil:

---------------
public class Ansatte {
String navn;

public Ansatte() {
navn = new String("unknown");
}
public void setNavn(String na) {
navn = na;
}
public String getNavn()
{
return navn;
}

public static void main(String[] args)
{
Ansatte a = new Ansatte();
a.setNavn("Kaj");
System.out.println(a.getNavn());
}
}

--------------------

Dette virker fint.

> Jeg har fx

Måske hvis du gav os en direkte kopi af hvad du har, i stedet for
eksempelkode, så kan vi hurtigere finde frem til en eventuel fejl.

--
"Sic gorgiamus allos subjectatos nunc"
Lars 'Trygleren' Winther

www.hesteskelet.dk

---

"Flare" <dct_flare@hotmail.com> wrote:

> Jeg er ved at lave en hjemmeopgave i Java. (nybegynder)
>
> Jeg har fx
> ===============
> public class Ansatte {
> String navn;
>
> Ansatte() {
> navn = new String("unknown");
> }
> void setNavn(String na) {
> navn = na;
> }
> ===============
>
> Dette virker bare ikke. Er der en måde hvorpå jeg kan få ændret en oprettet
> String?

Nej, men du kan sagtens tildele en anden String til en variabel, og det gør
du korrekt.

Den længere forklaring er, at objekt-variable i virkeligheden er en peger
(pointer) til et objekt, så selvom man ikke kan ændre i objektet kan man
godt få objekt-variablen til at pege på et anden objekt.

Hvad er det, der ikke virker? Oversætter det ikke?

Andre forslag:

Jeg ville nok lade konstruktøren og setNavn være public og huske den sidste
"}", men ellers burde det da oversætte.

Desuden kan du i konstruktøren i stedet for at skrive

navn = new String("unknown");

nøjes med at skrive

navn = "unknown";

Da "unknown" er en String. Normal ville man nok også lade konstruktøren
tage navn som parameter, så objekter altid er i en ordentlig tilstand. Og
så ville jeg personligt kalde klassen for Ansat, da hvert objekt kun
indeholder data for én ansat.

> Så mit egentlige spørgsmål er hvordan jeg får lavet en set funktion for en
> variable af typen String.

Som du har gjort.

--
Niels, The Offspring Mailinglist www.image.dk/~teglsbo

---

Ved sgu ikke hvad jeg har lavet. I min egen kode virkede det ikke. Men hvis
jeg selv kører det jeg skrev virker det. Så OK. Sowy.

> navn = new String("unknown");
> nøjes med at skrive
> navn = "unknown";

Hvad er forskellen ved disse to måder? Hvis der er en altså.

Anders

---

"Flare" <dct_flare@hotmail.com> writes:

> Ved sgu ikke hvad jeg har lavet. I min egen kode virkede det ikke. Men hvis
> jeg selv kører det jeg skrev virker det. Så OK. Sowy.
>
> > navn = new String("unknown");
> > nøjes med at skrive
> > navn = "unknown";
>
> Hvad er forskellen ved disse to måder? Hvis der er en altså.

"unknown" er implicit en String. new String("unknown") laver
altsaa 2 objekter: Strengen "unknown" og derefter kalder du
copy-constructor String(String) og faar endnu et String objekt.

F.eks. "unknown".indexOf("u") er validt.


Mvh, Soren.

---

soren wrote:

> F.eks. "unknown".indexOf("u") er validt.

Eller "".equals(strVar), som er handy hvis man ikke er sikker på, om strVar
er null eller ej. Dermed undgår man NullPointerException.


--

Martin

---

"Flare" <dct_flare@hotmail.com> wrote:

> > navn = new String("unknown");
> > nøjes med at skrive
> > navn = "unknown";
> Hvad er forskellen ved disse to måder? Hvis der er en altså.

I Java er "unknown" en nem måde at oprette et objekt af typen String med
det givne indhold.

new String("unknown") bruger Strings konstruktør:

public String(String original)

der tager en String og laver en ny String med samme indhold.

Men hvis man allerede har en String, er der ingen grund til at kalde
Strings konstruktør for at få en ny String med samme indhold, man kan jo
lige så godt bruge den String man har i forvejen.

--
Niels, The Offspring Mailinglist www.image.dk/~teglsbo

---

> Men hvis man allerede har en String, er der ingen grund til at kalde
> Strings konstruktør for at få en ny String med samme indhold, man kan jo
> lige så godt bruge den String man har i forvejen.

Aha. Takker til jer alle.

Mvh
Anders

---

Flare wrote:

>> navn = new String("unknown");
>> navn = "unknown";
>
> Hvad er forskellen ved disse to måder? Hvis der er en altså.

Forskellen er, at du opretter to String instanser. Den ene med "new
String(...)" og den anden med "unknown". Det er no-no - det må du ikke.
Hvis du gør det samme i en løkke, kan du ende op med millioner af String
instanser til ingen verdens nytte.

Så derfor: metode 2 er den eneste rigtige.


--

Martin

---

On Thu, 30 Jan 2003 20:07:02 +0100, Martin Kofoed wrote:

> Flare wrote:
>
>>> navn = new String("unknown");
>>> navn = "unknown";
>>
>> Hvad er forskellen ved disse to måder? Hvis der er en altså.
>
> Forskellen er, at du opretter to String instanser. Den ene med "new
> String(...)" og den anden med "unknown". Det er no-no - det må du ikke.
> Hvis du gør det samme i en løkke, kan du ende op med millioner af String
> instanser til ingen verdens nytte.

Er du sikker på det?

Skriver man "unknown" bliver den vel på compile-time puttet i en
litteral-pool og gør derfor ingen skade. Og new String(et eller andet)
kan jo garbage-collectes? Vi kan hurtigt blive enige om fordelen ved
StringBuffer!! Jeg prøver bare at forstå...

--
Jesper
Der ikke har taget en Java-certification

---

Jesper Lillesoe wrote:
> On Thu, 30 Jan 2003 20:07:02 +0100, Martin Kofoed wrote:
>
>
>>Flare wrote:
>>
>>
>>>>navn = new String("unknown");
>>>>navn = "unknown";
>>>
>>>Hvad er forskellen ved disse to måder? Hvis der er en altså.
>>
>>Forskellen er, at du opretter to String instanser. Den ene med "new
>>String(...)" og den anden med "unknown". Det er no-no - det må du ikke.
>>Hvis du gør det samme i en løkke, kan du ende op med millioner af String
>>instanser til ingen verdens nytte.
>
>
> Er du sikker på det?
>
> Skriver man "unknown" bliver den vel på compile-time puttet i en
> litteral-pool og gør derfor ingen skade. Og new String(et eller andet)
> kan jo garbage-collectes? Vi kan hurtigt blive enige om fordelen ved
> StringBuffer!! Jeg prøver bare at forstå...
>

Prøv at de-compile noget kode der gør ovenstående..

/ Michael

---

Jesper Lillesoe <jesper@FJERNveloce.dk> wrote:

> Skriver man "unknown" bliver den vel på compile-time puttet i en
> litteral-pool og gør derfor ingen skade. Og new String(et eller andet)
> kan jo garbage-collectes?

Men man spilder bare en masse tid i garbage-collectoren som man lige så
godt kunne hare sparet.

--
Niels, The Offspring Mailinglist www.image.dk/~teglsbo

---

In <qhdl3v856dsh00jrnv2gdfrdmpgulsfm4u@news.image.dk> Niels@fabel.dk (Niels Teglsbo) writes:

>Jesper Lillesoe <jesper@FJERNveloce.dk> wrote:

>> Skriver man "unknown" bliver den vel på compile-time puttet i en
>> litteral-pool og gør derfor ingen skade. Og new String(et eller andet)
>> kan jo garbage-collectes?

>Men man spilder bare en masse tid i garbage-collectoren som man lige så
>godt kunne hare sparet.

En moderne java-compiler burde genere samme bytekode for disse
to saetninger:

1. String One="one";
2. String One=new string("one");

/Martin

---

tusk@daimi.au.dk (Martin Moller Pedersen) wrote:

> En moderne java-compiler burde genere samme bytekode for disse
> to saetninger:
>
> 1. String One="one";
> 2. String One=new string("one");

Hverken SUNs javac eller IBMs jikes laver samme class-filer, og en
dekompilering af de 4 resulterende class-filer er nærmest identisk med
kildekoden, altså med henholdsvis uden og med brug af Strings
String-konstruktør.

--
Niels, The Offspring Mailinglist www.image.dk/~teglsbo

---

"Niels Teglsbo" <Niels@fabel.dk> skrev i en meddelelse
news:00dm3vo26ocgnja20bkqkadb34b61b2re4@news.image.dk...
> Hverken SUNs javac eller IBMs jikes laver samme class-filer, og en

Nej, selvfølgelig ikke... Filerne indeholder vel noget info om compileren
samt tidspunkt, et id osv. (???)

/ Michael

---

"Michael Banzon" <anyone@anywhere.anyhow> wrote:

> "Niels Teglsbo" <Niels@fabel.dk> skrev i en meddelelse
> news:00dm3vo26ocgnja20bkqkadb34b61b2re4@news.image.dk...
> > Hverken SUNs javac eller IBMs jikes laver samme class-filer, og en
> Nej, selvfølgelig ikke... Filerne indeholder vel noget info om compileren
> samt tidspunkt, et id osv. (???)

Muligvis, men dekompileringen viste, at forskellen også var måden strengen
blev lavet på.

Oprindelig kode:

class String1 {
   public static void main(String args[]){
      String One="one";
      System.out.println(One);
   }
}

class String2 {
   public static void main(String args[]){
      String One=new String("one");
      System.out.println(One);
   }
}

Oversat til class-filer, der så er dekompileret:

----------- String1.class ---------

import java.io.PrintStream;

class String1 {
   
   
   public static void main(String args[]) {
      String s = "one";
      System.out.println(s);
   }
}

----------- String2.class ---------

import java.io.PrintStream;

class String2 {
   
   
   public static void main(String args[]) {
      String s = new String("one");
      System.out.println(s);
   }
}

-----------------------------------

Er der nogen, der ved hvorfor "import java.io.PrintStream;" er med? Man kan
også se "java/io/PrintStream;" i class-filen.

--
Niels, The Offspring Mailinglist www.image.dk/~teglsbo

---

"Niels Teglsbo" <Niels@fabel.dk> skrev i en meddelelse
news:77pn3v4dllcuhud8u5tahcq98aerhepjbj@news.image.dk...
> "Michael Banzon" <anyone@anywhere.anyhow> wrote:
>
> > "Niels Teglsbo" <Niels@fabel.dk> skrev i en meddelelse
> > news:00dm3vo26ocgnja20bkqkadb34b61b2re4@news.image.dk...
> > > Hverken SUNs javac eller IBMs jikes laver samme class-filer, og en
> > Nej, selvfølgelig ikke... Filerne indeholder vel noget info om
compileren
> > samt tidspunkt, et id osv. (???)
>
> Muligvis, men dekompileringen viste, at forskellen også var måden strengen
> blev lavet på.
>
> Oprindelig kode:
>
> class String1 {
> public static void main(String args[]){
> String One="one";
> System.out.println(One);
> }
> }
>
> class String2 {
> public static void main(String args[]){
> String One=new String("one");
> System.out.println(One);
> }
> }
>
> Oversat til class-filer, der så er dekompileret:
>
> ----------- String1.class ---------
>
> import java.io.PrintStream;
>
> class String1 {
>
>
> public static void main(String args[]) {
> String s = "one";
> System.out.println(s);
> }
> }
>
> ----------- String2.class ---------
>
> import java.io.PrintStream;
>
> class String2 {
>
>
> public static void main(String args[]) {
> String s = new String("one");
> System.out.println(s);
> }
> }
>

Hvilken compiler+decompiler bruger du??

/ Michael

---

"Michael Banzon" <anyone@anywhere.anyhow> wrote:

> Hvilken compiler+decompiler bruger du??

Jikes 1.17 og Decafe Pro 3.9. Samme resultat med Suns javac, der følger med
Java SDK 1.4 både med og uden -O.

--
Niels, The Offspring Mailinglist www.image.dk/~teglsbo

---

"Martin Moller Pedersen" <tusk@daimi.au.dk> skrev i en meddelelse
news:b1enqd$mok$1@news.net.uni-c.dk...
> En moderne java-compiler burde genere samme bytekode for disse
> to saetninger:
>
> 1. String One="one";
> 2. String One=new string("one");

Bytecode er en ting, en anden ting er en ordentlig JIT compiler i den
virtuelle maskine. Den skal nok sørge for at optimere den ekstra objekt
allokering væk når programmet køres.

/Anders

---

"Anders K. Olsen" <akol_dk@hotmail.com> wrote:

> "Martin Moller Pedersen" <tusk@daimi.au.dk> skrev i en meddelelse
> news:b1enqd$mok$1@news.net.uni-c.dk...
> > 1. String One="one";
> > 2. String One=new string("one");
> Bytecode er en ting, en anden ting er en ordentlig JIT compiler i den
> virtuelle maskine. Den skal nok sørge for at optimere den ekstra objekt
> allokering væk når programmet køres.

Jeg bruger

java version "1.4.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-b92)
Java HotSpot(TM) Client VM (build 1.4.0-b92, mixed mode)

og har oversat:

------------------------------
class Ekstraobjekt {
private static long iterationer = 100*1000000;

private static void udenEkstraObjekt(){
for(long i=0; i<iterationer; i++){
String s = " davs ";
}
}

private static void medEkstraObjekt(){
for(long i=0; i<iterationer; i++){
String s = new String(" davs ");
}
}

public static void main(String args[]){
long start = System.currentTimeMillis();
udenEkstraObjekt();
long slut = System.currentTimeMillis();
System.out.println("Uden ekstra objekt tog det: "+(slut-start)+
" millisekunder");

start = System.currentTimeMillis();
medEkstraObjekt();
slut = System.currentTimeMillis();
System.out.println("Med ekstra objekt tog det: "+(slut-start)+
" millisekunder");

}
}
------------------------------
> javac -O Ekstraobjekt.java

> java Ekstraobjekt
Uden ekstra objekt tog det: 3020 millisekunder
Med ekstra objekt tog det: 23070 millisekunder

> java Ekstraobjekt
Uden ekstra objekt tog det: 3030 millisekunder
Med ekstra objekt tog det: 22900 millisekunder


Det er selvfølgelig en meget tænkt test, men den funktion med det ekstra
objekt bruger klart mere tid end den uden. Udover det burde oversætteren da
kunne se, at s i begge funktioner ikke bruges til noget, og kunne helt have
været udeladt, så for-løkkerne ville være tomme og dermed også begge
funktioner. JIT har vel også en mulighed for at lave samme slags
optimering.

--
Niels, The Offspring Mailinglist www.image.dk/~teglsbo

---

"Niels Teglsbo" <Niels@fabel.dk> skrev i en meddelelse
news:dejo3v88le3or0fgrcermtidldl8art1ie@news.image.dk...

> Det er selvfølgelig en meget tænkt test, men den funktion med det ekstra
> objekt bruger klart mere tid end den uden. Udover det burde oversætteren
da
> kunne se, at s i begge funktioner ikke bruges til noget, og kunne helt
have
> været udeladt, så for-løkkerne ville være tomme og dermed også begge
> funktioner. JIT har vel også en mulighed for at lave samme slags
> optimering.

Jeg har kikket lidt på String klassen og String literals, og jeg kan se, at
jeg tog fejl.

Jeg havde regnet med, at nedenstående ville skrive true ud 4 gange, da de
tre strenge jo bygger på samme String literal, men det gør det ikke (og det
skal det heller ikke):

String a = "dav";
String b = "dav";
String c = new String("dav");
System.out.println(a==b);
System.out.println(a.equals(b));
System.out.println(a==c);
System.out.println(a.equals(c));

Resultatet er:
true
true
false
true

I følge JavaDoc, vil "new String(original)" initialisere en ny String som
representerer den samme sekvens af karakterer som original, altså en kopi af
original. Denne kopiering kan compileren åbenbart ikke optimere væk, selvom
strengen ikke bruges til noget.

/Anders

---

Niels@fabel.dk (Niels Teglsbo) writes:

> Det er selvfølgelig en meget tænkt test, men den funktion med det ekstra
> objekt bruger klart mere tid end den uden. Udover det burde oversætteren da

Meget interessant, da det meget tydeligt anskueliggør at "new" ikke er
en gratis operation.

> kunne se, at s i begge funktioner ikke bruges til noget, og kunne helt have
> været udeladt, så for-løkkerne ville være tomme og dermed også begge
> funktioner. JIT har vel også en mulighed for at lave samme slags
> optimering.

Det afhænger vel af om String-constructoren har sideeffekter. Det kan
JIT'en vel ikke regne ud.
--
Thorbjørn Ravn Andersen
http://unixsnedkeren.dk/ravn

---

Hej Martin!

> En moderne java-compiler burde genere samme bytekode for disse
> to saetninger:
>
> 1. String One="one";
> 2. String One=new string("one");
>

Hm. Kan den nu også tillade sig det?

Det gælder vel kun hvis der antages at jeg ikke selv har lavet en klasse ved navn String (måske ligger den endda i en Import) og at der på runtime tidspunktet ikke findes en klasse i classpath ved navn String. Er det sikkert at opstille sådanne forudsætninger?

Mvh Michael

---

Michael Berg wrote:

> Hej Martin!
>
> > En moderne java-compiler burde genere samme bytekode for disse
> > to saetninger:
> >
> > 1. String One="one";
> > 2. String One=new string("one");
> >
>
> Hm. Kan den nu også tillade sig det?
>
> Det gælder vel kun hvis der antages at jeg ikke selv har lavet en klasse ved navn String (måske ligger den endda i en Import) og at der på runtime tidspunktet ikke findes en klasse i classpath ved navn String.

Så skulle compileren gerne blive forvirret og opgive.

> Er det sikkert at opstille sådanne forudsætninger?

Ja, for java.lang.String burde det være - ikke for andre.

Ulrik Magnusson

---

Ulrik Magnusson wrote:

> Michael Berg wrote:
> > Hej Martin!
> > > En moderne java-compiler burde genere samme bytekode for disse
> > > to saetninger:
> > > 1. String One="one";
> > > 2. String One=new string("one");
> > Hm. Kan den nu også tillade sig det?
> > Det gælder vel kun hvis der antages at jeg ikke selv har lavet en klasse ved navn String (måske ligger den endda i en Import) og at der på runtime tidspunktet ikke findes en klasse i classpath ved navn String.
> Så skulle compileren gerne blive forvirret og opgive.

Heh, jeg misforstod vist lidt- jeg går ud fra at alle compilere er
pålagt altid at have en java.lang.String, og eftersom "one" har
typen java.lang.String kan du ikke tildele denne til variabler
af typen mypackage.String. Mere korrekt var det nok at sige
at følgende burde generere samme bytecode:

java.lang.String s = "";
java.lang.String s = new java.lang.String("");

- hvis du har en mypackage.String i import er du
tvunget til at bruge det fulde navn java.lang.String,

Ulrik Magnusson

---

Ulrik Magnusson <ulrikm@yahoo.com> writes:

> Heh, jeg misforstod vist lidt- jeg går ud fra at alle compilere er
> pålagt altid at have en java.lang.String, og eftersom "one" har
> typen java.lang.String kan du ikke tildele denne til variabler
> af typen mypackage.String. Mere korrekt var det nok at sige
> at følgende burde generere samme bytecode:
>
> java.lang.String s = "";
> java.lang.String s = new java.lang.String("");

Næh..

Forestil dig at du har en metode der sammenligner to strenge med ==
(altså om det er det samme objekt, ikke om det er samme indhold) og hvis
det er den samme gøres en ting, hvis det ikke er så gøres noget andet.

Du instantierer nu to strenge a og b:

String a = "ting";
String b = new String("ting");

og kalder ovennævnte metode med dem som parametre.

"Optimerer" man initialiseringen af b så vil det ændre på programmets
opførsel, ikke særligt fedt! Compileren må kun lave optimeringer der ikke
kan ændre på programmets opførsel, b skal altså være et andet objekt end
a ligesom java-standarden foreskriver det.


Så

java.lang.String s = "";
java.lang.String s = new java.lang.String("");

bør ALDRIG genere samme bytecode.

--
Finn Nielsen - http://www.finnnielsen.dk/

---

Finn Nielsen wrote:

> Ulrik Magnusson <ulrikm@yahoo.com> writes:
>
> > Heh, jeg misforstod vist lidt- jeg går ud fra at alle compilere er
> > pålagt altid at have en java.lang.String, og eftersom "one" har
> > typen java.lang.String kan du ikke tildele denne til variabler
> > af typen mypackage.String. Mere korrekt var det nok at sige
> > at følgende burde generere samme bytecode:
> >
> > java.lang.String s = "";
> > java.lang.String s = new java.lang.String("");
>
> Næh..
>
> Forestil dig at du har en metode der sammenligner to strenge med ==
> (altså om det er det samme objekt, ikke om det er samme indhold) og hvis
> det er den samme gøres en ting, hvis det ikke er så gøres noget andet.
>
> Du instantierer nu to strenge a og b:
>
> String a = "ting";
> String b = new String("ting");
>
> og kalder ovennævnte metode med dem som parametre.
>
> "Optimerer" man initialiseringen af b så vil det ændre på programmets
> opførsel, ikke særligt fedt! Compileren må kun lave optimeringer der ikke
> kan ændre på programmets opførsel, b skal altså være et andet objekt end
> a ligesom java-standarden foreskriver det.

Det har du minsandten ret i - "" tages som en konstant og new String("")
kopierer dennes indhold. Man lærer noget hver dag

Ulrik Magnusson