---

Java programmer kan afvikles nativt under OS X, som er bevidnet i
programmer såsom LimeWire (dårligt eksempel, i know) og Acquisition m.fl.

Men hvorfor som programmør vælge Java, over fx. C++ eller Obj-C i Cocoa?

Derfor: http://www.javaworld.com/javaworld/jw-08-1996/jw-08-gc.html

(Garbage Collection)

Pt. kører OS X med Java 1.3.1, men 1.4 er ude i Developer Preview, og
jeg tror vi kommer til at se en endelig J1.4 med HotSpot (JIT compiler)
tiL WWDC i Maj.

Så kommer der tryk på Java. Som Sun's programmører siger oM java og OS X
- sweeeet combo... =)

DAP

---

Den Anden Peter skrev:

> Men hvorfor som programmør vælge Java, over fx. C++ eller Obj-C i Cocoa?
>
> Derfor: http://www.javaworld.com/javaworld/jw-08-1996/jw-08-gc.html
>
> (Garbage Collection)

Tjoh, det kan da være da meget smart - som programmør - i forhold til
f.eks. Cocoa/Objective-C's "reference counting"-system.

http://www.macdevcenter.com/pub/a/mac/2001/07/27/cocoa.html

"Both of these memory management schemes have advantages and
disadvantages. Automatic garbage collection is easy on the developer
because it's entirely automatic. However, this convenience comes at the
expense of performance and efficiency. Reference counting on the the
hand is very efficient and fast because there is no garbage collector
working behind the scenes using up resources. The flip side of the coin
is that the increased performance and efficiency of reference counting
requires more work on the part of the developer. Fortunately, this is
not difficult once you understand the rules to the game."

Der er i øvrigt også andre udviklingsværktøjer som REALbasic (der kan
lave Carbon-programmer), der har "Garbage Collection".

Well, alt i alt kan jeg ikke se, at det spiller den store rolle, men det
er måske bare min uvidenhed.

--
Mvh.
Jesper Juellund Jensen
http://cyrk.dk/programmer/

---

Jesper Juellund Jensen <jjj@cyrk.dk> wrote:

> Tjoh, det kan da være da meget smart - som programmør - i forhold til
> f.eks. Cocoa/Objective-C's "reference counting"-system.
>
> http://www.macdevcenter.com/pub/a/mac/2001/07/27/cocoa.html
>
> "Both of these memory management schemes have advantages and
> disadvantages. Automatic garbage collection is easy on the developer
> because it's entirely automatic. However, this convenience comes at the
> expense of performance and efficiency. Reference counting on the the
> hand is very efficient and fast because there is no garbage collector
> working behind the scenes using up resources. The flip side of the coin
> is that the increased performance and efficiency of reference counting
> requires more work on the part of the developer. Fortunately, this is
> not difficult once you understand the rules to the game."
>

Ah, interessant. Tak for det link.

> Der er i øvrigt også andre udviklingsværktøjer som REALbasic (der kan
> lave Carbon-programmer), der har "Garbage Collection".

Så er ulempen ved BASIC programmer bare at de fylder som en ond
bondegård.

>
> Well, alt i alt kan jeg ikke se, at det spiller den store rolle, men det
> er måske bare min uvidenhed.

Well, jo mindre arbejde for programmøren, des mere tid til
QUUAAAAAAKKKKKEEEEEE...

;)
--
regards, Peter - +45 5192 3981
http://haxor.dk/about.html

---

jjj@cyrk.dk (Jesper Juellund Jensen) writes:

> because it's entirely automatic. However, this convenience comes at the
> expense of performance and efficiency. Reference counting on the the

Fordelen ved Java's oprydningsmekanisme er at den er så løst
specificeret. Herved kan man lave en hel del optimering, som det fx
er vist i HotSpot med deres "vuggestuer" for objekter, som er RET
effektiv for Java som har mange kortlivede objekter.

Uanset mekanismen, er det en enorm fordel at programmøren ikke selv
skal holde styr på at rydde op efter sig. Kedelige, repetitive
opgaver er noget computeren skal holde styr på.

--
Thorbjørn Ravn Andersen "... plus ... Tubular Bells!"
http://bigfoot.com/~thunderbear

---

Den Anden Peter <nospam@ftc.gov> writes:

> Derfor: http://www.javaworld.com/javaworld/jw-08-1996/jw-08-gc.html

Det alene kan ikke gøre det. En anden grund er også _flytbarheden_.
Det er muligt at udvikle programmer på sin maskine som umiddelbart kan
afvikles på en anden platform (fx mainframe), og det betyder faktisk
en del.

Herudover er Java et læseligt sprog. Du er rimeligt sikker på at ting
gør det der står, og man kan læse nogenlunde ud fra metodenavnene hvad
de gør. Det gør vedligehold nemmere.

> Pt. kører OS X med Java 1.3.1, men 1.4 er ude i Developer Preview, og
> jeg tror vi kommer til at se en endelig J1.4 med HotSpot (JIT
> compiler) tiL WWDC i Maj.

Twewler.

Java 1.3.1 har et seriøst hastighedsproblem under OS X. Det har jeg
beklaget mig over før her i gruppen, men jeg håber at Apple har fået
tunet HotSpot noget mere i 1.4. Jeg vil dog se det førend jeg tror
det.

JDeveloper er iøvrigt kommet i en OS X udgave (let tilrettet, og
pakket ind i en App). Det kører ok, men forventer 512 Mb RAM til sig
selv.
--
Thorbjørn Ravn Andersen "... plus ... Tubular Bells!"
http://bigfoot.com/~thunderbear

---

Thorbjoern Ravn Andersen <nospam0000@unixsnedkeren.dk> wrote:

> Den Anden Peter <nospam@ftc.gov> writes:
>
> > Derfor: http://www.javaworld.com/javaworld/jw-08-1996/jw-08-gc.html
>
> Det alene kan ikke gøre det. En anden grund er også _flytbarheden_.

Jep - protabiliteten, hvilket jeg selvfølgelig glemte at nævne. Men det
er vist underforstået i Java. =)

>
> > Pt. kører OS X med Java 1.3.1, men 1.4 er ude i Developer Preview, og
> > jeg tror vi kommer til at se en endelig J1.4 med HotSpot (JIT
> > compiler) tiL WWDC i Maj.
>
> Twewler.
>
> Java 1.3.1 har et seriøst hastighedsproblem under OS X. Det har jeg
> beklaget mig over før her i gruppen, men jeg håber at Apple har fået
> tunet HotSpot noget mere i 1.4. Jeg vil dog se det førend jeg tror
> det.
>
> JDeveloper er iøvrigt kommet i en OS X udgave (let tilrettet, og
> pakket ind i en App). Det kører ok, men forventer 512 Mb RAM til sig
> selv.

Med dagens hardware er det næppe et problem... vi er jo på vej mod 1 GB
RAM på computer i dag.

--
regards, Peter - +45 5192 3981
http://haxor.dk/about.html
"There's nothing mutual about M.A.D. when the games are turn based!"