<article>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#article09_06_05_1222223</id>
	<title>Java's New G1 Collector Not For-Pay After All</title>
	<author>kdawson</author>
	<datestamp>1244207040000</datestamp>
	<htmltext>An anonymous reader writes <i>"As a follow-up to <a href="http://tech.slashdot.org/story/09/05/29/1711203/Java-Gets-New-Garbage-Collector-But-Only-If-You-Buy-Support">our previous discussion</a>, Sun appears to have quietly edited the <a href="http://java.sun.com/javase/6/webnotes/6u14.html">Java 6u14 release notes</a> language to say now: 'G1 is available as early access in this release, please try it and give us feedback. Usage in production settings without a Java SE for Business support contract is not recommended.' So does this mean it was all one huge typo? Or was Oracle/Sun tentatively testing the waters to see the community's reaction? In either case it's nice to see Java's back on the right path."</i></htmltext>
<tokenext>An anonymous reader writes " As a follow-up to our previous discussion , Sun appears to have quietly edited the Java 6u14 release notes language to say now : 'G1 is available as early access in this release , please try it and give us feedback .
Usage in production settings without a Java SE for Business support contract is not recommended .
' So does this mean it was all one huge typo ?
Or was Oracle/Sun tentatively testing the waters to see the community 's reaction ?
In either case it 's nice to see Java 's back on the right path .
"</tokentext>
<sentencetext>An anonymous reader writes "As a follow-up to our previous discussion, Sun appears to have quietly edited the Java 6u14 release notes language to say now: 'G1 is available as early access in this release, please try it and give us feedback.
Usage in production settings without a Java SE for Business support contract is not recommended.
' So does this mean it was all one huge typo?
Or was Oracle/Sun tentatively testing the waters to see the community's reaction?
In either case it's nice to see Java's back on the right path.
"</sentencetext>
</article>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28231777</id>
	<title>Re:Right path?</title>
	<author>LizardKing</author>
	<datestamp>1244292540000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p> <i>I don't see anything in the article about Java becoming more like Haskell!</i> </p><p>Shurely you meant Scala?</p></htmltext>
<tokenext>I do n't see anything in the article about Java becoming more like Haskell !
Shurely you meant Scala ?</tokentext>
<sentencetext> I don't see anything in the article about Java becoming more like Haskell!
Shurely you meant Scala?</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28221165</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28223519</id>
	<title>Re:Java doesn't fail</title>
	<author>skeeto</author>
	<datestamp>1244220960000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>This means that a resource, other than memory, can't be tied completely to an object. Anything using the object has to handle the resource manually, like basic C++ memory management, breaking the abstraction.</p><p>For example, I might want to tie, say, a database to an object. I create the object which opens/creates a database. I then use the object normally, and it makes transactions with the database as needed, but since finalize() is not reliable I have to explicitly call a close() method before I let the object fall out of scope if I want to keep the database synced up and tidy. And I can't call close() too soon or something else using the object will have a problem. If I have to do that I might as well be managing the memory too.</p><p>This has specifically annoyed me in the past and now, as I continually run into this limitation. It is on my list of "Reasons I Despise Java".</p></htmltext>
<tokenext>This means that a resource , other than memory , ca n't be tied completely to an object .
Anything using the object has to handle the resource manually , like basic C + + memory management , breaking the abstraction.For example , I might want to tie , say , a database to an object .
I create the object which opens/creates a database .
I then use the object normally , and it makes transactions with the database as needed , but since finalize ( ) is not reliable I have to explicitly call a close ( ) method before I let the object fall out of scope if I want to keep the database synced up and tidy .
And I ca n't call close ( ) too soon or something else using the object will have a problem .
If I have to do that I might as well be managing the memory too.This has specifically annoyed me in the past and now , as I continually run into this limitation .
It is on my list of " Reasons I Despise Java " .</tokentext>
<sentencetext>This means that a resource, other than memory, can't be tied completely to an object.
Anything using the object has to handle the resource manually, like basic C++ memory management, breaking the abstraction.For example, I might want to tie, say, a database to an object.
I create the object which opens/creates a database.
I then use the object normally, and it makes transactions with the database as needed, but since finalize() is not reliable I have to explicitly call a close() method before I let the object fall out of scope if I want to keep the database synced up and tidy.
And I can't call close() too soon or something else using the object will have a problem.
If I have to do that I might as well be managing the memory too.This has specifically annoyed me in the past and now, as I continually run into this limitation.
It is on my list of "Reasons I Despise Java".</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28221989</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28221165</id>
	<title>Right path?</title>
	<author>Anonymous</author>
	<datestamp>1244211000000</datestamp>
	<modclass>Funny</modclass>
	<modscore>5</modscore>
	<htmltext><blockquote><div><p> In either case it's nice to see Java's back on the right path.</p></div></blockquote><p>Did kdawson even read the article before writing the summary?  I don't see <i>anything</i> in the article about Java becoming more like Haskell!</p></div>
	</htmltext>
<tokenext>In either case it 's nice to see Java 's back on the right path.Did kdawson even read the article before writing the summary ?
I do n't see anything in the article about Java becoming more like Haskell !</tokentext>
<sentencetext> In either case it's nice to see Java's back on the right path.Did kdawson even read the article before writing the summary?
I don't see anything in the article about Java becoming more like Haskell!
	</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28222283</id>
	<title>Re:But it could be!</title>
	<author>Anonymous</author>
	<datestamp>1244216340000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>What's boring to one person is of great interest to another.  There are piles of interesting problems being tackled in developing garbage collectors - it's one of the areas in computer science that's actively evolving, and it's receptive to new ideas or approaches.</p><p>Also - much of the Java language/libraries were designed with the hope that desctructors would go out of style.  I'm not saying desctructors don't have their uses - a number of core classes have finalizers, proving their use.  You can always write your code so that they aren't required, though.  I have yet to encounter a problem where I've needed one - when I've come close, it's worked out just fine to perform clean-up with a weak reference queue.</p></htmltext>
<tokenext>What 's boring to one person is of great interest to another .
There are piles of interesting problems being tackled in developing garbage collectors - it 's one of the areas in computer science that 's actively evolving , and it 's receptive to new ideas or approaches.Also - much of the Java language/libraries were designed with the hope that desctructors would go out of style .
I 'm not saying desctructors do n't have their uses - a number of core classes have finalizers , proving their use .
You can always write your code so that they are n't required , though .
I have yet to encounter a problem where I 've needed one - when I 've come close , it 's worked out just fine to perform clean-up with a weak reference queue .</tokentext>
<sentencetext>What's boring to one person is of great interest to another.
There are piles of interesting problems being tackled in developing garbage collectors - it's one of the areas in computer science that's actively evolving, and it's receptive to new ideas or approaches.Also - much of the Java language/libraries were designed with the hope that desctructors would go out of style.
I'm not saying desctructors don't have their uses - a number of core classes have finalizers, proving their use.
You can always write your code so that they aren't required, though.
I have yet to encounter a problem where I've needed one - when I've come close, it's worked out just fine to perform clean-up with a weak reference queue.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28221171</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28226683</id>
	<title>Re:But it could be!</title>
	<author>Anonymous</author>
	<datestamp>1244234640000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p><div class="quote"><p>Best practices have long accepted this fact; you close connections, free resources in the course of your application logic, rather than is being a passive act.</p></div><p><div class="quote"><p>Managing the tedium of your own garbage collection for most applications is a proven waste of time, this is why we arrived at GC.</p></div><p>These two statements say the opposite of each other.</p></div>
	</htmltext>
<tokenext>Best practices have long accepted this fact ; you close connections , free resources in the course of your application logic , rather than is being a passive act.Managing the tedium of your own garbage collection for most applications is a proven waste of time , this is why we arrived at GC.These two statements say the opposite of each other .</tokentext>
<sentencetext>Best practices have long accepted this fact; you close connections, free resources in the course of your application logic, rather than is being a passive act.Managing the tedium of your own garbage collection for most applications is a proven waste of time, this is why we arrived at GC.These two statements say the opposite of each other.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28223305</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28221623</id>
	<title>Re:Right path?</title>
	<author>Anonymous</author>
	<datestamp>1244213220000</datestamp>
	<modclass>Troll</modclass>
	<modscore>-1</modscore>
	<htmltext><p><div class="quote"><blockquote><div><p> In either case it's nice to see Java's back on the right path.</p></div></blockquote><p>Did kdawson even read the article before writing the summary?  I don't see <i>anything</i> in the article about Java becoming more like Haskell!</p></div><p>Fuck Java, it's a slow piece of shit and one vendor (Sun) has too much control over it anyway.  Even niggers and dune coons know that!  That's sayin something too because the niggers were stoneage primitives who didn't even have the wheel when the White Man found them and the dune coons are a bunch of savages who are so busy with their ages of blood feuds that they probably don't remember what they're fighting about anymore and are probably only still around because they have oil.  So now niggers are a bunch of thug wannabes and dune coons gave us terrorism and anyone is surprised by that.  Like I said Java is too goddamned slow.</p></div>
	</htmltext>
<tokenext>In either case it 's nice to see Java 's back on the right path.Did kdawson even read the article before writing the summary ?
I do n't see anything in the article about Java becoming more like Haskell ! Fuck Java , it 's a slow piece of shit and one vendor ( Sun ) has too much control over it anyway .
Even niggers and dune coons know that !
That 's sayin something too because the niggers were stoneage primitives who did n't even have the wheel when the White Man found them and the dune coons are a bunch of savages who are so busy with their ages of blood feuds that they probably do n't remember what they 're fighting about anymore and are probably only still around because they have oil .
So now niggers are a bunch of thug wannabes and dune coons gave us terrorism and anyone is surprised by that .
Like I said Java is too goddamned slow .</tokentext>
<sentencetext> In either case it's nice to see Java's back on the right path.Did kdawson even read the article before writing the summary?
I don't see anything in the article about Java becoming more like Haskell!Fuck Java, it's a slow piece of shit and one vendor (Sun) has too much control over it anyway.
Even niggers and dune coons know that!
That's sayin something too because the niggers were stoneage primitives who didn't even have the wheel when the White Man found them and the dune coons are a bunch of savages who are so busy with their ages of blood feuds that they probably don't remember what they're fighting about anymore and are probably only still around because they have oil.
So now niggers are a bunch of thug wannabes and dune coons gave us terrorism and anyone is surprised by that.
Like I said Java is too goddamned slow.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28221165</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28221989</id>
	<title>Java doesn't fail</title>
	<author>beldraen</author>
	<datestamp>1244214900000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>4</modscore>
	<htmltext><p>The reason why you are confused is because you're used to a compiled environment, where every call is an immediate action.  A C/C++ program must be coded to (i.e. explicitly) deletes memory references.  If you explicitly delete, you can also tie in other explicit behavior; therefore, it's common "duh this is how you do it" practice to tie "finalize" behavior to the object's deletion.  But remember, it is your program's logic that has decided when to get rid of it.  In a GC environment, deletion is no longer an explicit event--it is autonomous, automatic; therefore, it is illogical to tie anything to the deletion of the memory reference to anything other than deletion of the memory reference.  There is no connection between when the object was dereferenced and when the GC chooses to clean up the reference.  Generally, the only events that are tied to the finalize method are sanity checks to make sure non-Java code knows the reference is going away.  Put differently: in Java, memory deallocation is not a part of the running logic of your program and so the program must create an explicit method of releasing resources in your program's logic.  In other words, do what you were doing before, just don't call it finalize.  That's a gripe of mine about Java: It confuses C++ users who are used to using the function finalize because Java gives finalize a specific purpose that cannot act the same way.</p></htmltext>
<tokenext>The reason why you are confused is because you 're used to a compiled environment , where every call is an immediate action .
A C/C + + program must be coded to ( i.e .
explicitly ) deletes memory references .
If you explicitly delete , you can also tie in other explicit behavior ; therefore , it 's common " duh this is how you do it " practice to tie " finalize " behavior to the object 's deletion .
But remember , it is your program 's logic that has decided when to get rid of it .
In a GC environment , deletion is no longer an explicit event--it is autonomous , automatic ; therefore , it is illogical to tie anything to the deletion of the memory reference to anything other than deletion of the memory reference .
There is no connection between when the object was dereferenced and when the GC chooses to clean up the reference .
Generally , the only events that are tied to the finalize method are sanity checks to make sure non-Java code knows the reference is going away .
Put differently : in Java , memory deallocation is not a part of the running logic of your program and so the program must create an explicit method of releasing resources in your program 's logic .
In other words , do what you were doing before , just do n't call it finalize .
That 's a gripe of mine about Java : It confuses C + + users who are used to using the function finalize because Java gives finalize a specific purpose that can not act the same way .</tokentext>
<sentencetext>The reason why you are confused is because you're used to a compiled environment, where every call is an immediate action.
A C/C++ program must be coded to (i.e.
explicitly) deletes memory references.
If you explicitly delete, you can also tie in other explicit behavior; therefore, it's common "duh this is how you do it" practice to tie "finalize" behavior to the object's deletion.
But remember, it is your program's logic that has decided when to get rid of it.
In a GC environment, deletion is no longer an explicit event--it is autonomous, automatic; therefore, it is illogical to tie anything to the deletion of the memory reference to anything other than deletion of the memory reference.
There is no connection between when the object was dereferenced and when the GC chooses to clean up the reference.
Generally, the only events that are tied to the finalize method are sanity checks to make sure non-Java code knows the reference is going away.
Put differently: in Java, memory deallocation is not a part of the running logic of your program and so the program must create an explicit method of releasing resources in your program's logic.
In other words, do what you were doing before, just don't call it finalize.
That's a gripe of mine about Java: It confuses C++ users who are used to using the function finalize because Java gives finalize a specific purpose that cannot act the same way.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28221171</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28223215</id>
	<title>Re:Java doesn't fail</title>
	<author>Anonymous</author>
	<datestamp>1244219760000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><p>If you're coding in lots of explicit memory reference deletes, what you're writing is not C++ but C. A C++ codebase would use RRID and automatic memory management to obviate the need for any explicit memory management. My last C++ project at work contained zero (yes, zero) calls to delete/free() out of around 20000 lines of code and a year of development/testing.</p><p>You're making the same mistake you're accusing C++ developers of making - you're viewing C++ through Java lenses.</p></htmltext>
<tokenext>If you 're coding in lots of explicit memory reference deletes , what you 're writing is not C + + but C. A C + + codebase would use RRID and automatic memory management to obviate the need for any explicit memory management .
My last C + + project at work contained zero ( yes , zero ) calls to delete/free ( ) out of around 20000 lines of code and a year of development/testing.You 're making the same mistake you 're accusing C + + developers of making - you 're viewing C + + through Java lenses .</tokentext>
<sentencetext>If you're coding in lots of explicit memory reference deletes, what you're writing is not C++ but C. A C++ codebase would use RRID and automatic memory management to obviate the need for any explicit memory management.
My last C++ project at work contained zero (yes, zero) calls to delete/free() out of around 20000 lines of code and a year of development/testing.You're making the same mistake you're accusing C++ developers of making - you're viewing C++ through Java lenses.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28221989</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28223305</id>
	<title>Re:But it could be!</title>
	<author>Anonymous</author>
	<datestamp>1244220120000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext>Destructors/finalizers/etc are nearly never used in the course of design in languages that are built upon a framework that use a GC. Best practices have long accepted this fact; you close connections, free resources in the course of your application logic, rather than is being a passive act.

Managing the tedium of your own garbage collection for most applications is a proven waste of time, this is why we arrived at GC. Clearly there will always be exceptions<nobr> <wbr></nobr>:)</htmltext>
<tokenext>Destructors/finalizers/etc are nearly never used in the course of design in languages that are built upon a framework that use a GC .
Best practices have long accepted this fact ; you close connections , free resources in the course of your application logic , rather than is being a passive act .
Managing the tedium of your own garbage collection for most applications is a proven waste of time , this is why we arrived at GC .
Clearly there will always be exceptions : )</tokentext>
<sentencetext>Destructors/finalizers/etc are nearly never used in the course of design in languages that are built upon a framework that use a GC.
Best practices have long accepted this fact; you close connections, free resources in the course of your application logic, rather than is being a passive act.
Managing the tedium of your own garbage collection for most applications is a proven waste of time, this is why we arrived at GC.
Clearly there will always be exceptions :)</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28221171</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28221421</id>
	<title>Re:But it could be!</title>
	<author>Anonymous</author>
	<datestamp>1244212320000</datestamp>
	<modclass>Funny</modclass>
	<modscore>4</modscore>
	<htmltext><p><div class="quote"><p>Where Java really fails is in the inability to trust the finalize method. At least in C++, the destructor of an object is guaranteed to be called as soon as the object is deleted.</p></div><p>Destructor!? Finalize!? Deleted!? You talking like a crazy man, have you never heard of a system REBOOT?</p></div>
	</htmltext>
<tokenext>Where Java really fails is in the inability to trust the finalize method .
At least in C + + , the destructor of an object is guaranteed to be called as soon as the object is deleted.Destructor ! ?
Finalize ! ? Deleted ! ?
You talking like a crazy man , have you never heard of a system REBOOT ?</tokentext>
<sentencetext>Where Java really fails is in the inability to trust the finalize method.
At least in C++, the destructor of an object is guaranteed to be called as soon as the object is deleted.Destructor!?
Finalize!? Deleted!?
You talking like a crazy man, have you never heard of a system REBOOT?
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28221171</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28227211</id>
	<title>Re:But it could be!</title>
	<author>SplashMyBandit</author>
	<datestamp>1244194080000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>If more than one thread has a reference to an object then you are out of deterministic country - it is multi-threading support that makes things complicated.</htmltext>
<tokenext>If more than one thread has a reference to an object then you are out of deterministic country - it is multi-threading support that makes things complicated .</tokentext>
<sentencetext>If more than one thread has a reference to an object then you are out of deterministic country - it is multi-threading support that makes things complicated.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28221171</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28225217</id>
	<title>Re:But it could be!</title>
	<author>againjj</author>
	<datestamp>1244227440000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>Garbage collection is an amazingly boring field of computer science.</p></div><p>
And so is , unless it isn't.  Any time some one says, "X is boring," or, "X is interesting," that really means, "X is boring TO ME," or, "X is interesting TO ME."  "Boring" or "interesting" is opinion.  Personally, I find GC rather interesting, in particular the latest advances in real-time GC.  I did compiler/programming languages work for my M.S., and I believe that most people would think that it is boring as well, but it is not to me.</p><p><div class="quote"><p>It's all about tracking references</p></div><p>
There is a lot more than that.</p></div>
	</htmltext>
<tokenext>Garbage collection is an amazingly boring field of computer science .
And so is , unless it is n't .
Any time some one says , " X is boring , " or , " X is interesting , " that really means , " X is boring TO ME , " or , " X is interesting TO ME .
" " Boring " or " interesting " is opinion .
Personally , I find GC rather interesting , in particular the latest advances in real-time GC .
I did compiler/programming languages work for my M.S. , and I believe that most people would think that it is boring as well , but it is not to me.It 's all about tracking references There is a lot more than that .</tokentext>
<sentencetext>Garbage collection is an amazingly boring field of computer science.
And so is , unless it isn't.
Any time some one says, "X is boring," or, "X is interesting," that really means, "X is boring TO ME," or, "X is interesting TO ME.
"  "Boring" or "interesting" is opinion.
Personally, I find GC rather interesting, in particular the latest advances in real-time GC.
I did compiler/programming languages work for my M.S., and I believe that most people would think that it is boring as well, but it is not to me.It's all about tracking references
There is a lot more than that.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28221171</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28228651</id>
	<title>Re:Java doesn't fail</title>
	<author>BikeHelmet</author>
	<datestamp>1244203740000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Yeah, I remember reading up on finalization before I even knew Java's syntax. I decided to create a method in every class - "deleteMe", which nulls everything out when called.</p><p>I'm sure the garbage collector cleans it up soon after. Good enough. Has worked fine ever since.</p></htmltext>
<tokenext>Yeah , I remember reading up on finalization before I even knew Java 's syntax .
I decided to create a method in every class - " deleteMe " , which nulls everything out when called.I 'm sure the garbage collector cleans it up soon after .
Good enough .
Has worked fine ever since .</tokentext>
<sentencetext>Yeah, I remember reading up on finalization before I even knew Java's syntax.
I decided to create a method in every class - "deleteMe", which nulls everything out when called.I'm sure the garbage collector cleans it up soon after.
Good enough.
Has worked fine ever since.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28221989</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28225561</id>
	<title>Re:But it could be!</title>
	<author>ADRA</author>
	<datestamp>1244229000000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I think you're looking at deterministic in a different way than I. I know that when there are no longer any references to an Object, that object is completely out of scope from my application. I don't care how the system I'm on cleans it up, the same way that 99\% of the time, you don't care about what a free/delete/close really does behind the scenes. What does matter is that:<br>
&nbsp; &nbsp; &nbsp; 1. The process of cleaning up this memory doesn't negatively impact the application's runtime performance<br>
&nbsp; &nbsp; &nbsp; 2. 'Native'/OS resources outside of the code are released in a timely manner (Sockets, shared memory, etc..)</p><p>Point 1 is addressed in several different GC's in Java. Most happy cases where fine grained timing is not mandatory have very little issue with one's code unless you're creating/destroying a LOT of objects in which case, object reuse would be more meaningful. Although it may not be perfect, I think Java does a pretty good job of mitigating the GC's interruption of an application.</p><p>Point 2 is where the real problem of non-finalization occurs. If one doesn't explicitly release these resources when a programmer is done with them, you'll start getting error for too many open files, or this or that. In this case, it should be up to the developer to specifically deallocate these pieces of code. In any Input/Output steam for instance, a user must explicitly call close() to free up those OS resources that have been allocated for them (This is done on finalization as well if you don't explicitly call it). I don't care about the memory being used, since the GC magically takes care of that for me. What I do care about is that the files are released.</p><p>Java does allow one to free these resources when you tell it to, so even though I could say its a non-issue, this brings up an interesting dilemma as a Java developer. If I expect that the GC takes care of everything behind the scenes, I may be coaxed into forgetting about this behaviour when I'm developing my code. Generally, an issue like this is either caught right away which is fine, or its caught much later in the development when the programs are being tested excessively, or when performing load testing, etc.. This just re-enforces how important it is to profile your code with a good profiler to see what's staying in use and what gets freed up. Most Java 'memory leaks' I've seen fall into the annoying but not game-breaking category, but you'll eventually see degradation in performance the longer the issue is left undetected.</p></htmltext>
<tokenext>I think you 're looking at deterministic in a different way than I. I know that when there are no longer any references to an Object , that object is completely out of scope from my application .
I do n't care how the system I 'm on cleans it up , the same way that 99 \ % of the time , you do n't care about what a free/delete/close really does behind the scenes .
What does matter is that :       1 .
The process of cleaning up this memory does n't negatively impact the application 's runtime performance       2 .
'Native'/OS resources outside of the code are released in a timely manner ( Sockets , shared memory , etc.. ) Point 1 is addressed in several different GC 's in Java .
Most happy cases where fine grained timing is not mandatory have very little issue with one 's code unless you 're creating/destroying a LOT of objects in which case , object reuse would be more meaningful .
Although it may not be perfect , I think Java does a pretty good job of mitigating the GC 's interruption of an application.Point 2 is where the real problem of non-finalization occurs .
If one does n't explicitly release these resources when a programmer is done with them , you 'll start getting error for too many open files , or this or that .
In this case , it should be up to the developer to specifically deallocate these pieces of code .
In any Input/Output steam for instance , a user must explicitly call close ( ) to free up those OS resources that have been allocated for them ( This is done on finalization as well if you do n't explicitly call it ) .
I do n't care about the memory being used , since the GC magically takes care of that for me .
What I do care about is that the files are released.Java does allow one to free these resources when you tell it to , so even though I could say its a non-issue , this brings up an interesting dilemma as a Java developer .
If I expect that the GC takes care of everything behind the scenes , I may be coaxed into forgetting about this behaviour when I 'm developing my code .
Generally , an issue like this is either caught right away which is fine , or its caught much later in the development when the programs are being tested excessively , or when performing load testing , etc.. This just re-enforces how important it is to profile your code with a good profiler to see what 's staying in use and what gets freed up .
Most Java 'memory leaks ' I 've seen fall into the annoying but not game-breaking category , but you 'll eventually see degradation in performance the longer the issue is left undetected .</tokentext>
<sentencetext>I think you're looking at deterministic in a different way than I. I know that when there are no longer any references to an Object, that object is completely out of scope from my application.
I don't care how the system I'm on cleans it up, the same way that 99\% of the time, you don't care about what a free/delete/close really does behind the scenes.
What does matter is that:
      1.
The process of cleaning up this memory doesn't negatively impact the application's runtime performance
      2.
'Native'/OS resources outside of the code are released in a timely manner (Sockets, shared memory, etc..)Point 1 is addressed in several different GC's in Java.
Most happy cases where fine grained timing is not mandatory have very little issue with one's code unless you're creating/destroying a LOT of objects in which case, object reuse would be more meaningful.
Although it may not be perfect, I think Java does a pretty good job of mitigating the GC's interruption of an application.Point 2 is where the real problem of non-finalization occurs.
If one doesn't explicitly release these resources when a programmer is done with them, you'll start getting error for too many open files, or this or that.
In this case, it should be up to the developer to specifically deallocate these pieces of code.
In any Input/Output steam for instance, a user must explicitly call close() to free up those OS resources that have been allocated for them (This is done on finalization as well if you don't explicitly call it).
I don't care about the memory being used, since the GC magically takes care of that for me.
What I do care about is that the files are released.Java does allow one to free these resources when you tell it to, so even though I could say its a non-issue, this brings up an interesting dilemma as a Java developer.
If I expect that the GC takes care of everything behind the scenes, I may be coaxed into forgetting about this behaviour when I'm developing my code.
Generally, an issue like this is either caught right away which is fine, or its caught much later in the development when the programs are being tested excessively, or when performing load testing, etc.. This just re-enforces how important it is to profile your code with a good profiler to see what's staying in use and what gets freed up.
Most Java 'memory leaks' I've seen fall into the annoying but not game-breaking category, but you'll eventually see degradation in performance the longer the issue is left undetected.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28221171</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28221899</id>
	<title>Re:But it could be!</title>
	<author>Anonymous</author>
	<datestamp>1244214480000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>To call a finalize on every object you create will cause you to have to have a reference to said object.  This is the part of Java that I find nice is the ability to use objects with no reference like this:</p><p>
&nbsp; String s = new Date().toString();</p><p>There is no reference to the Date object -- all I really wanted was the String output -- it cleans up the code nicely.</p></htmltext>
<tokenext>To call a finalize on every object you create will cause you to have to have a reference to said object .
This is the part of Java that I find nice is the ability to use objects with no reference like this :   String s = new Date ( ) .toString ( ) ; There is no reference to the Date object -- all I really wanted was the String output -- it cleans up the code nicely .</tokentext>
<sentencetext>To call a finalize on every object you create will cause you to have to have a reference to said object.
This is the part of Java that I find nice is the ability to use objects with no reference like this:
  String s = new Date().toString();There is no reference to the Date object -- all I really wanted was the String output -- it cleans up the code nicely.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28221171</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28221125</id>
	<title>Haha!</title>
	<author>Anonymous</author>
	<datestamp>1244210880000</datestamp>
	<modclass>Offtopic</modclass>
	<modscore>-1</modscore>
	<htmltext>The arm is disbombed!<br> <br>Wait what?</htmltext>
<tokenext>The arm is disbombed !
Wait what ?</tokentext>
<sentencetext>The arm is disbombed!
Wait what?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28226271</id>
	<title>Re:But it could be!</title>
	<author>Raul Acevedo</author>
	<datestamp>1244232420000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><blockquote><div><p>At least in C++, the destructor of an object is guaranteed to be called as soon as the object is deleted. Java has no such guarantee, so expecting an object to clean itself up once it goes out of scope is a fool's errand.</p></div>
</blockquote><p>

So?  I switched from C/C++ to Java over 10 years ago, and have not once needed to even consider implementing finalize.  The only thing this "lack of deterministic behavior" really means in practice is that you have to explicitly close input/output streams, rather than let objects go out of scope and close their own resources in the finalize method.  In other words, instead of calling delete, you call close.  Outside of that, there is very little consequence.
<br> <br>
I'll take Java's current behavior just fine, thanks.  I don't know of a real example where Java's non-deterministic behavior is an issue.</p></div>
	</htmltext>
<tokenext>At least in C + + , the destructor of an object is guaranteed to be called as soon as the object is deleted .
Java has no such guarantee , so expecting an object to clean itself up once it goes out of scope is a fool 's errand .
So ? I switched from C/C + + to Java over 10 years ago , and have not once needed to even consider implementing finalize .
The only thing this " lack of deterministic behavior " really means in practice is that you have to explicitly close input/output streams , rather than let objects go out of scope and close their own resources in the finalize method .
In other words , instead of calling delete , you call close .
Outside of that , there is very little consequence .
I 'll take Java 's current behavior just fine , thanks .
I do n't know of a real example where Java 's non-deterministic behavior is an issue .</tokentext>
<sentencetext>At least in C++, the destructor of an object is guaranteed to be called as soon as the object is deleted.
Java has no such guarantee, so expecting an object to clean itself up once it goes out of scope is a fool's errand.
So?  I switched from C/C++ to Java over 10 years ago, and have not once needed to even consider implementing finalize.
The only thing this "lack of deterministic behavior" really means in practice is that you have to explicitly close input/output streams, rather than let objects go out of scope and close their own resources in the finalize method.
In other words, instead of calling delete, you call close.
Outside of that, there is very little consequence.
I'll take Java's current behavior just fine, thanks.
I don't know of a real example where Java's non-deterministic behavior is an issue.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28221171</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28225597</id>
	<title>Re:But it could be!</title>
	<author>Anonymous</author>
	<datestamp>1244229120000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I can only speak from experience with Mac development, but Apple's Objective-C garbage collector runs on a second thread so that there is no delay, and in theory, a garbage collected application has a small speed advantage because there are no retain and release messages in accessor methods.  Arguably, you shouldn't be relying on a destructor to do huge cleanup operations regardless of what memory management scheme you're using.</p><p>Garbage collection is one of those things that, someday, the majority of programmers will use--if they don't already--and people will wonder how we managed without it.  It's just obvious at this point.</p></htmltext>
<tokenext>I can only speak from experience with Mac development , but Apple 's Objective-C garbage collector runs on a second thread so that there is no delay , and in theory , a garbage collected application has a small speed advantage because there are no retain and release messages in accessor methods .
Arguably , you should n't be relying on a destructor to do huge cleanup operations regardless of what memory management scheme you 're using.Garbage collection is one of those things that , someday , the majority of programmers will use--if they do n't already--and people will wonder how we managed without it .
It 's just obvious at this point .</tokentext>
<sentencetext>I can only speak from experience with Mac development, but Apple's Objective-C garbage collector runs on a second thread so that there is no delay, and in theory, a garbage collected application has a small speed advantage because there are no retain and release messages in accessor methods.
Arguably, you shouldn't be relying on a destructor to do huge cleanup operations regardless of what memory management scheme you're using.Garbage collection is one of those things that, someday, the majority of programmers will use--if they don't already--and people will wonder how we managed without it.
It's just obvious at this point.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28221171</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28229825</id>
	<title>Re:But it could be!</title>
	<author>maraist</author>
	<datestamp>1244218320000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Wow, I've done a lot of Java development and have never had a need for a finalizer.  So while you may have a niche need in your C++/Java work, you certainly don't represent a majority of use-cases, and thus I can disregard your claim of Java's failure.  There are many many other programming paradigms for resource cleanups.  try-catch-finally (or better yet, pass a runnable to try-catch-finally processor to guarantee consistent resource-management).  One particularly elegant form is Thread-Local Transactions (if your use-case can support them).  The medium-weight spring-library provides a slew of these resource-safe 'executors', though they're really just simple convenience utilities where you could roll your own.  Basically any resource that you want guarantees that you won't accidentally leave open, explicitly register with some framework that at some exit-point, items will be cleaned-up. (In a transaction model, this is the post-end-transaction phase - called after rollback or commit, and whether or not you are exiting with an exception).</p></htmltext>
<tokenext>Wow , I 've done a lot of Java development and have never had a need for a finalizer .
So while you may have a niche need in your C + + /Java work , you certainly do n't represent a majority of use-cases , and thus I can disregard your claim of Java 's failure .
There are many many other programming paradigms for resource cleanups .
try-catch-finally ( or better yet , pass a runnable to try-catch-finally processor to guarantee consistent resource-management ) .
One particularly elegant form is Thread-Local Transactions ( if your use-case can support them ) .
The medium-weight spring-library provides a slew of these resource-safe 'executors ' , though they 're really just simple convenience utilities where you could roll your own .
Basically any resource that you want guarantees that you wo n't accidentally leave open , explicitly register with some framework that at some exit-point , items will be cleaned-up .
( In a transaction model , this is the post-end-transaction phase - called after rollback or commit , and whether or not you are exiting with an exception ) .</tokentext>
<sentencetext>Wow, I've done a lot of Java development and have never had a need for a finalizer.
So while you may have a niche need in your C++/Java work, you certainly don't represent a majority of use-cases, and thus I can disregard your claim of Java's failure.
There are many many other programming paradigms for resource cleanups.
try-catch-finally (or better yet, pass a runnable to try-catch-finally processor to guarantee consistent resource-management).
One particularly elegant form is Thread-Local Transactions (if your use-case can support them).
The medium-weight spring-library provides a slew of these resource-safe 'executors', though they're really just simple convenience utilities where you could roll your own.
Basically any resource that you want guarantees that you won't accidentally leave open, explicitly register with some framework that at some exit-point, items will be cleaned-up.
(In a transaction model, this is the post-end-transaction phase - called after rollback or commit, and whether or not you are exiting with an exception).</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28221171</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28225301</id>
	<title>Re:But it could be!</title>
	<author>recharged95</author>
	<datestamp>1244227800000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>For every article, opinion and comment that starts with:
<p>
"Where Java really fails..."
</p><p>
I add to my 'what-evar!' list, consider the rant it in my app <i>design</i> and continue programming my [insert ANY app here] in Netbeans (likelt the app that <i>pays</i> my mortgage).
</p><p><nobr> <wbr></nobr>.</p><p>
Thanks for the [usual academic] opinion.
</p><p> On the flip side, Java says, separate implementation representation (i.e. low-level, on the metal, specific to vendor, dependencies,  etc...) from logical representation (move robot arm 10 degrees). That <i>forces</i> you to design 'the' solution, not hack it. The rest (all the business jargon of Java), can go into the trash heap as its just a sales pitch. Can we all just get along and say Java has its place: not at the flight controller level, but somewhere between flight controller and web app and stop the "my language is <b>flat out</b> better than yours"?.</p></htmltext>
<tokenext>For every article , opinion and comment that starts with : " Where Java really fails... " I add to my 'what-evar !
' list , consider the rant it in my app design and continue programming my [ insert ANY app here ] in Netbeans ( likelt the app that pays my mortgage ) .
. Thanks for the [ usual academic ] opinion .
On the flip side , Java says , separate implementation representation ( i.e .
low-level , on the metal , specific to vendor , dependencies , etc... ) from logical representation ( move robot arm 10 degrees ) .
That forces you to design 'the ' solution , not hack it .
The rest ( all the business jargon of Java ) , can go into the trash heap as its just a sales pitch .
Can we all just get along and say Java has its place : not at the flight controller level , but somewhere between flight controller and web app and stop the " my language is flat out better than yours " ? .</tokentext>
<sentencetext>For every article, opinion and comment that starts with:

"Where Java really fails..."

I add to my 'what-evar!
' list, consider the rant it in my app design and continue programming my [insert ANY app here] in Netbeans (likelt the app that pays my mortgage).
.
Thanks for the [usual academic] opinion.
On the flip side, Java says, separate implementation representation (i.e.
low-level, on the metal, specific to vendor, dependencies,  etc...) from logical representation (move robot arm 10 degrees).
That forces you to design 'the' solution, not hack it.
The rest (all the business jargon of Java), can go into the trash heap as its just a sales pitch.
Can we all just get along and say Java has its place: not at the flight controller level, but somewhere between flight controller and web app and stop the "my language is flat out better than yours"?.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28221171</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28222571</id>
	<title>Re:But it could be!</title>
	<author>Anonymous</author>
	<datestamp>1244217360000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Not really sure if you really need destructor  calls, the only area i can see where it would make sense even in garbage collected environments is ressource cleanup like file closing, but on the other hand relying on destructors for file closing is an antipattern in itself!<br>In c++ it just makes sense because you dont have garbage collection so introducing object counters etc... via destructors is heavens sent in those surroundings!</p></htmltext>
<tokenext>Not really sure if you really need destructor calls , the only area i can see where it would make sense even in garbage collected environments is ressource cleanup like file closing , but on the other hand relying on destructors for file closing is an antipattern in itself ! In c + + it just makes sense because you dont have garbage collection so introducing object counters etc... via destructors is heavens sent in those surroundings !</tokentext>
<sentencetext>Not really sure if you really need destructor  calls, the only area i can see where it would make sense even in garbage collected environments is ressource cleanup like file closing, but on the other hand relying on destructors for file closing is an antipattern in itself!In c++ it just makes sense because you dont have garbage collection so introducing object counters etc... via destructors is heavens sent in those surroundings!</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28221171</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28228853</id>
	<title>Re:But it could be!</title>
	<author>countach</author>
	<datestamp>1244205240000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I don't find it boring, but then I am geeky.</p></htmltext>
<tokenext>I do n't find it boring , but then I am geeky .</tokentext>
<sentencetext>I don't find it boring, but then I am geeky.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28221171</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28227989</id>
	<title>Re:Right path?</title>
	<author>moosesocks</author>
	<datestamp>1244199180000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><blockquote><div><p> In either case it's nice to see Java's back on the right path.</p></div></blockquote><p>Did kdawson even read the article before writing the summary? </p></div><p>You must be new here.</p></div>
	</htmltext>
<tokenext>In either case it 's nice to see Java 's back on the right path.Did kdawson even read the article before writing the summary ?
You must be new here .</tokentext>
<sentencetext> In either case it's nice to see Java's back on the right path.Did kdawson even read the article before writing the summary?
You must be new here.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28221165</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28222965</id>
	<title>So use real-time Java</title>
	<author>shis-ka-bob</author>
	<datestamp>1244218860000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>3</modscore>
	<htmltext>If you want to control garbage collection, you should use the real time version of Java.  Go to youtube and view Java RTSJ on Wall Street pt1.  Here are folks that greatly value deterministic behavior, and they are choosing Java over C++.  Why?  Because it is predictable and you get access to the tools, developers and tools of the  Java World.</htmltext>
<tokenext>If you want to control garbage collection , you should use the real time version of Java .
Go to youtube and view Java RTSJ on Wall Street pt1 .
Here are folks that greatly value deterministic behavior , and they are choosing Java over C + + .
Why ? Because it is predictable and you get access to the tools , developers and tools of the Java World .</tokentext>
<sentencetext>If you want to control garbage collection, you should use the real time version of Java.
Go to youtube and view Java RTSJ on Wall Street pt1.
Here are folks that greatly value deterministic behavior, and they are choosing Java over C++.
Why?  Because it is predictable and you get access to the tools, developers and tools of the  Java World.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28221171</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28226799</id>
	<title>Re:Java doesn't fail</title>
	<author>Anonymous</author>
	<datestamp>1244235180000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><blockquote><div><p>The reason why you are confused is because you're used to a compiled environment</p></div></blockquote><p>Compilation has nothing whatsoever to do with memory management.  Java is a compiled environment, too.  Java can even be compiled to native code, just like C++.  Meanwhile, the gcc compiler, which is written in C and as compiled as you can get, uses GC.</p><blockquote><div><p>That's a gripe of mine about Java: It confuses C++ users who are used to using the function finalize</p></div></blockquote><p>What are you talking about?  There is no function "finalize" in C++.</p></div>
	</htmltext>
<tokenext>The reason why you are confused is because you 're used to a compiled environmentCompilation has nothing whatsoever to do with memory management .
Java is a compiled environment , too .
Java can even be compiled to native code , just like C + + .
Meanwhile , the gcc compiler , which is written in C and as compiled as you can get , uses GC.That 's a gripe of mine about Java : It confuses C + + users who are used to using the function finalizeWhat are you talking about ?
There is no function " finalize " in C + + .</tokentext>
<sentencetext>The reason why you are confused is because you're used to a compiled environmentCompilation has nothing whatsoever to do with memory management.
Java is a compiled environment, too.
Java can even be compiled to native code, just like C++.
Meanwhile, the gcc compiler, which is written in C and as compiled as you can get, uses GC.That's a gripe of mine about Java: It confuses C++ users who are used to using the function finalizeWhat are you talking about?
There is no function "finalize" in C++.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28221989</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28226269</id>
	<title>Re:Java doesn't fail</title>
	<author>Anonymous</author>
	<datestamp>1244232420000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>The problem is that you can't do what you were doing before, just by not calling it finalize. In C++ it is a common practice to rely on the stack for resource management (this is where it differs from C), and the reason that you can do this is because you have destructors. And yes, you can do this even when you allocate on the heap (see <a href="http://www.boost.org/doc/libs/1\_39\_0/libs/smart\_ptr/scoped\_ptr.htm" title="boost.org">scoped\_ptr</a> [boost.org]). There is no equivalent way to track resources in Java.
<br> <br>
Now, you might say that this is not an issue, since the GC will reclaim all memory anyway. But what you have overlooked is that heap space is not the only resource you have to manage. There are various other types of resources (file handles, network connections, hardware interfaces, to name a few). So, ironically, the garbage collection approach in Java actually results in most types of resources becoming explicit in Java where they are, in essence, implicit C++.
<br> <br>
I'm not saying that this is a huge problem, but it is something I find lacking when I develop in Java and other GC based languages.</htmltext>
<tokenext>The problem is that you ca n't do what you were doing before , just by not calling it finalize .
In C + + it is a common practice to rely on the stack for resource management ( this is where it differs from C ) , and the reason that you can do this is because you have destructors .
And yes , you can do this even when you allocate on the heap ( see scoped \ _ptr [ boost.org ] ) .
There is no equivalent way to track resources in Java .
Now , you might say that this is not an issue , since the GC will reclaim all memory anyway .
But what you have overlooked is that heap space is not the only resource you have to manage .
There are various other types of resources ( file handles , network connections , hardware interfaces , to name a few ) .
So , ironically , the garbage collection approach in Java actually results in most types of resources becoming explicit in Java where they are , in essence , implicit C + + .
I 'm not saying that this is a huge problem , but it is something I find lacking when I develop in Java and other GC based languages .</tokentext>
<sentencetext>The problem is that you can't do what you were doing before, just by not calling it finalize.
In C++ it is a common practice to rely on the stack for resource management (this is where it differs from C), and the reason that you can do this is because you have destructors.
And yes, you can do this even when you allocate on the heap (see scoped\_ptr [boost.org]).
There is no equivalent way to track resources in Java.
Now, you might say that this is not an issue, since the GC will reclaim all memory anyway.
But what you have overlooked is that heap space is not the only resource you have to manage.
There are various other types of resources (file handles, network connections, hardware interfaces, to name a few).
So, ironically, the garbage collection approach in Java actually results in most types of resources becoming explicit in Java where they are, in essence, implicit C++.
I'm not saying that this is a huge problem, but it is something I find lacking when I develop in Java and other GC based languages.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28221989</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28221461</id>
	<title>Re:But it could be!</title>
	<author>Anonymous</author>
	<datestamp>1244212500000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Hmm... I thought that even then you had to pass a VM arg to ask the GC to call finalize... ugh.<br>I got that far and seriously thought about switching to C++ for mini projects</p></htmltext>
<tokenext>Hmm... I thought that even then you had to pass a VM arg to ask the GC to call finalize... ugh.I got that far and seriously thought about switching to C + + for mini projects</tokentext>
<sentencetext>Hmm... I thought that even then you had to pass a VM arg to ask the GC to call finalize... ugh.I got that far and seriously thought about switching to C++ for mini projects</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28221171</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28221171</id>
	<title>But it could be!</title>
	<author>BadAnalogyGuy</author>
	<datestamp>1244211000000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>5</modscore>
	<htmltext><p>Garbage collection is an amazingly boring field of computer science. It's all about tracking references and trying to keep memory from filling up while also trying to keep the overall impact on the running system down. But as boring as it may be, it's also absolutely critical in today's interpreted languages.</p><p>Where Java really fails is in the inability to trust the finalize method. At least in C++, the destructor of an object is guaranteed to be called as soon as the object is deleted. Java has no such guarantee, so expecting an object to clean itself up once it goes out of scope is a fool's errand. It will get finalized eventually, but the lack of deterministic behavior in this critical part of the object lifecycle means that there is a very big chance that unacceptable delays may occur in practice.</p><p>Give me deterministic behavior over faster GC any day.</p></htmltext>
<tokenext>Garbage collection is an amazingly boring field of computer science .
It 's all about tracking references and trying to keep memory from filling up while also trying to keep the overall impact on the running system down .
But as boring as it may be , it 's also absolutely critical in today 's interpreted languages.Where Java really fails is in the inability to trust the finalize method .
At least in C + + , the destructor of an object is guaranteed to be called as soon as the object is deleted .
Java has no such guarantee , so expecting an object to clean itself up once it goes out of scope is a fool 's errand .
It will get finalized eventually , but the lack of deterministic behavior in this critical part of the object lifecycle means that there is a very big chance that unacceptable delays may occur in practice.Give me deterministic behavior over faster GC any day .</tokentext>
<sentencetext>Garbage collection is an amazingly boring field of computer science.
It's all about tracking references and trying to keep memory from filling up while also trying to keep the overall impact on the running system down.
But as boring as it may be, it's also absolutely critical in today's interpreted languages.Where Java really fails is in the inability to trust the finalize method.
At least in C++, the destructor of an object is guaranteed to be called as soon as the object is deleted.
Java has no such guarantee, so expecting an object to clean itself up once it goes out of scope is a fool's errand.
It will get finalized eventually, but the lack of deterministic behavior in this critical part of the object lifecycle means that there is a very big chance that unacceptable delays may occur in practice.Give me deterministic behavior over faster GC any day.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28222155</id>
	<title>Re:But it could be!</title>
	<author>SecondaryOak</author>
	<datestamp>1244215800000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext>I disagree about the "boring" part. I took a university course on garbage collection (and a bit more, but that was the main topic) and it was absolutely fascinating. It was filled with a lot of interesting challenges - like how to handle multithreaded systems, how to avoid dirtying the cache, how to write incremental garbage collectors to prevent pauses, etc.</htmltext>
<tokenext>I disagree about the " boring " part .
I took a university course on garbage collection ( and a bit more , but that was the main topic ) and it was absolutely fascinating .
It was filled with a lot of interesting challenges - like how to handle multithreaded systems , how to avoid dirtying the cache , how to write incremental garbage collectors to prevent pauses , etc .</tokentext>
<sentencetext>I disagree about the "boring" part.
I took a university course on garbage collection (and a bit more, but that was the main topic) and it was absolutely fascinating.
It was filled with a lot of interesting challenges - like how to handle multithreaded systems, how to avoid dirtying the cache, how to write incremental garbage collectors to prevent pauses, etc.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28221171</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28222305</id>
	<title>GC and the desctructor</title>
	<author>testman123</author>
	<datestamp>1244216400000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>A destructor is useless with a GC.</p><p>The finalize method was only introduced in some situation where you need to make memory cleaning easier &amp; faster.</p><p>If you are developing a regular program, you will never need to ever think on finalize. Using WeakReferences, Handles (look NIO for instance), you don't even need to know what is finalize() and what is the subilities it has. In the same way as the<nobr> <wbr></nobr>.wait() or<nobr> <wbr></nobr>.notify() !</p><p>This is the problem with developper comming from C/C++, they have been so focussed on memory management problems that they can not understand it has been solved (with a CPU &amp; memory cost) thru GC usage.</p><p>Having automatic memory handling, does not mean you are freed from error. One famous problem is the loitering references, a reference you did not take notice to kept a bit longer than required in your code, but unfortunatly this reference has reference to lots of objects that have also reference...etc. The problem is getting worse if the place you are keeping tis reference is under a static zone or in a daemon thread.</p><p>The known solution to this is :<br>
&nbsp; 1- never keep a cache of objects that are external to your domain unless you know what you are doing or unless you are using a weak reference to point each object and performing the appropriate presence test on them.<br>
&nbsp; 2- never store a reference to your domain in a foreign domain (worst example of this is swing client properties) unlessyou know what you are doing or unless you are using a weak reference to point each object and performing the appropriate presence test on them<br>
&nbsp; 3- never use string interning (cf.<nobr> <wbr></nobr>.intern()) unless you truly understand it and can control the memory usage impact you will have on the VM on the long run.</p><p>If you follow those simple advices, you will never have to think about<nobr> <wbr></nobr>.finalize() anymore<nobr> <wbr></nobr>:)</p><p>Allright, here is my question : we know that GC are now well known techniques and have reached to a suitable level of maturity. Why is there no GC directly written in the microprocessor ? I mean, these are basic feature that a processor could control and perform better than anybody else. All languages could benefit this by replacing memory allocation techniques !</p><p>This would be a huge step forward IMHO.</p></htmltext>
<tokenext>A destructor is useless with a GC.The finalize method was only introduced in some situation where you need to make memory cleaning easier &amp; faster.If you are developing a regular program , you will never need to ever think on finalize .
Using WeakReferences , Handles ( look NIO for instance ) , you do n't even need to know what is finalize ( ) and what is the subilities it has .
In the same way as the .wait ( ) or .notify ( ) ! This is the problem with developper comming from C/C + + , they have been so focussed on memory management problems that they can not understand it has been solved ( with a CPU &amp; memory cost ) thru GC usage.Having automatic memory handling , does not mean you are freed from error .
One famous problem is the loitering references , a reference you did not take notice to kept a bit longer than required in your code , but unfortunatly this reference has reference to lots of objects that have also reference...etc .
The problem is getting worse if the place you are keeping t is reference is under a static zone or in a daemon thread.The known solution to this is :   1- never keep a cache of objects that are external to your domain unless you know what you are doing or unless you are using a weak reference to point each object and performing the appropriate presence test on them .
  2- never store a reference to your domain in a foreign domain ( worst example of this is swing client properties ) unlessyou know what you are doing or unless you are using a weak reference to point each object and performing the appropriate presence test on them   3- never use string interning ( cf .
.intern ( ) ) unless you truly understand it and can control the memory usage impact you will have on the VM on the long run.If you follow those simple advices , you will never have to think about .finalize ( ) anymore : ) Allright , here is my question : we know that GC are now well known techniques and have reached to a suitable level of maturity .
Why is there no GC directly written in the microprocessor ?
I mean , these are basic feature that a processor could control and perform better than anybody else .
All languages could benefit this by replacing memory allocation techniques ! This would be a huge step forward IMHO .</tokentext>
<sentencetext>A destructor is useless with a GC.The finalize method was only introduced in some situation where you need to make memory cleaning easier &amp; faster.If you are developing a regular program, you will never need to ever think on finalize.
Using WeakReferences, Handles (look NIO for instance), you don't even need to know what is finalize() and what is the subilities it has.
In the same way as the .wait() or .notify() !This is the problem with developper comming from C/C++, they have been so focussed on memory management problems that they can not understand it has been solved (with a CPU &amp; memory cost) thru GC usage.Having automatic memory handling, does not mean you are freed from error.
One famous problem is the loitering references, a reference you did not take notice to kept a bit longer than required in your code, but unfortunatly this reference has reference to lots of objects that have also reference...etc.
The problem is getting worse if the place you are keeping tis reference is under a static zone or in a daemon thread.The known solution to this is :
  1- never keep a cache of objects that are external to your domain unless you know what you are doing or unless you are using a weak reference to point each object and performing the appropriate presence test on them.
  2- never store a reference to your domain in a foreign domain (worst example of this is swing client properties) unlessyou know what you are doing or unless you are using a weak reference to point each object and performing the appropriate presence test on them
  3- never use string interning (cf.
.intern()) unless you truly understand it and can control the memory usage impact you will have on the VM on the long run.If you follow those simple advices, you will never have to think about .finalize() anymore :)Allright, here is my question : we know that GC are now well known techniques and have reached to a suitable level of maturity.
Why is there no GC directly written in the microprocessor ?
I mean, these are basic feature that a processor could control and perform better than anybody else.
All languages could benefit this by replacing memory allocation techniques !This would be a huge step forward IMHO.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28221171</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28222445</id>
	<title>Re:But it could be!</title>
	<author>SecondaryOak</author>
	<datestamp>1244216880000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p><div class="quote"><p>The thing is, there really is no middle ground. You need to use a mark-and-sweep algorithm to avoid leaking cyclic references, which means you have no way of determining if an object should or should not be destroyed if it leaves scope.</p></div><p>There are cycle-detection algorithms that do not require a full mark-and-sweep; they run a limited, local scan which can be immediately performed any time a reference is decreased to 1.</p></div>
	</htmltext>
<tokenext>The thing is , there really is no middle ground .
You need to use a mark-and-sweep algorithm to avoid leaking cyclic references , which means you have no way of determining if an object should or should not be destroyed if it leaves scope.There are cycle-detection algorithms that do not require a full mark-and-sweep ; they run a limited , local scan which can be immediately performed any time a reference is decreased to 1 .</tokentext>
<sentencetext>The thing is, there really is no middle ground.
You need to use a mark-and-sweep algorithm to avoid leaking cyclic references, which means you have no way of determining if an object should or should not be destroyed if it leaves scope.There are cycle-detection algorithms that do not require a full mark-and-sweep; they run a limited, local scan which can be immediately performed any time a reference is decreased to 1.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28221613</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28222055</id>
	<title>Re:But it could be!</title>
	<author>owlstead</author>
	<datestamp>1244215260000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Amazingly boring? Jeez, there is a lot of ways of doing garbage collection. You can mix GC types, have multiple levels of GC, heap sizes to tweak for these levels etc. Java has got an upper limit to the amount of memory the process uses, but I can think of other schemes that dont. Then you can do a lot of multithreading stuff, but you cannot break code anytime, because in that case the whole VM can die unexpectedly. Then you have to choose when and how long to garbage collect, if you only do so if CPU utilization is high or low. Weak references and such can also play a role etc.</p><p>If it's really boring to people they aren't trying hard enough.</p></htmltext>
<tokenext>Amazingly boring ?
Jeez , there is a lot of ways of doing garbage collection .
You can mix GC types , have multiple levels of GC , heap sizes to tweak for these levels etc .
Java has got an upper limit to the amount of memory the process uses , but I can think of other schemes that dont .
Then you can do a lot of multithreading stuff , but you can not break code anytime , because in that case the whole VM can die unexpectedly .
Then you have to choose when and how long to garbage collect , if you only do so if CPU utilization is high or low .
Weak references and such can also play a role etc.If it 's really boring to people they are n't trying hard enough .</tokentext>
<sentencetext>Amazingly boring?
Jeez, there is a lot of ways of doing garbage collection.
You can mix GC types, have multiple levels of GC, heap sizes to tweak for these levels etc.
Java has got an upper limit to the amount of memory the process uses, but I can think of other schemes that dont.
Then you can do a lot of multithreading stuff, but you cannot break code anytime, because in that case the whole VM can die unexpectedly.
Then you have to choose when and how long to garbage collect, if you only do so if CPU utilization is high or low.
Weak references and such can also play a role etc.If it's really boring to people they aren't trying hard enough.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28221171</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28221613</id>
	<title>Re:But it could be!</title>
	<author>Unoriginal\_Nickname</author>
	<datestamp>1244213220000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>Give me deterministic behavior over faster GC any day.</p></div><p>The thing is, there really is no middle ground. You need to use a mark-and-sweep algorithm to avoid leaking cyclic references, which means you have no way of determining if an object should or should not be destroyed if it leaves scope. The good news is that a modern generational garbage collector is optimized toward collecting younger objects, so it's fairly likely that your resource objects will be collected fairly soon after you're done using them.<nobr> <wbr></nobr>.NET provides a modicum of determinism with a bunch of syntactic sugar for a particular interface (IDisposable). It's not RAII, but C++ doesn't have heap compaction which is far more inconvenient than having to type out a finally block every time you open a file.</p></div>
	</htmltext>
<tokenext>Give me deterministic behavior over faster GC any day.The thing is , there really is no middle ground .
You need to use a mark-and-sweep algorithm to avoid leaking cyclic references , which means you have no way of determining if an object should or should not be destroyed if it leaves scope .
The good news is that a modern generational garbage collector is optimized toward collecting younger objects , so it 's fairly likely that your resource objects will be collected fairly soon after you 're done using them .
.NET provides a modicum of determinism with a bunch of syntactic sugar for a particular interface ( IDisposable ) .
It 's not RAII , but C + + does n't have heap compaction which is far more inconvenient than having to type out a finally block every time you open a file .</tokentext>
<sentencetext>Give me deterministic behavior over faster GC any day.The thing is, there really is no middle ground.
You need to use a mark-and-sweep algorithm to avoid leaking cyclic references, which means you have no way of determining if an object should or should not be destroyed if it leaves scope.
The good news is that a modern generational garbage collector is optimized toward collecting younger objects, so it's fairly likely that your resource objects will be collected fairly soon after you're done using them.
.NET provides a modicum of determinism with a bunch of syntactic sugar for a particular interface (IDisposable).
It's not RAII, but C++ doesn't have heap compaction which is far more inconvenient than having to type out a finally block every time you open a file.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28221171</parent>
</comment>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_05_1222223_15</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28221421
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28221171
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_05_1222223_0</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28222283
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28221171
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_05_1222223_4</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28222155
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28221171
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_05_1222223_7</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28222571
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28221171
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_05_1222223_11</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28228853
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28221171
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_05_1222223_24</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28227211
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28221171
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_05_1222223_1</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28222445
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28221613
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28221171
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_05_1222223_21</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28221461
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28221171
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_05_1222223_8</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28226271
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28221171
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_05_1222223_19</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28223215
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28221989
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28221171
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_05_1222223_5</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28222055
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28221171
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_05_1222223_25</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28221623
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28221165
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_05_1222223_17</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28225217
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28221171
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_05_1222223_9</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28222965
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28221171
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_05_1222223_13</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28225301
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28221171
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_05_1222223_12</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28226799
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28221989
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28221171
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_05_1222223_16</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28227989
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28221165
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_05_1222223_10</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28231777
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28221165
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_05_1222223_14</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28226269
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28221989
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28221171
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_05_1222223_18</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28221899
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28221171
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_05_1222223_2</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28222305
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28221171
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_05_1222223_22</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28229825
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28221171
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_05_1222223_6</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28223519
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28221989
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28221171
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_05_1222223_26</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28228651
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28221989
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28221171
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_05_1222223_3</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28226683
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28223305
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28221171
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_05_1222223_23</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28225597
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28221171
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_06_05_1222223_20</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28225561
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28221171
</commentlist>
</thread>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_06_05_1222223.0</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28221171
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28221899
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28222965
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28223305
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28226683
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28225217
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28221461
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28227211
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28221989
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28223215
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28226269
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28226799
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28228651
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28223519
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28229825
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28221613
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28222445
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28222155
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28222055
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28226271
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28222305
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28225561
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28225597
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28225301
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28222571
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28228853
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28222283
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28221421
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_06_05_1222223.1</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28221165
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28227989
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28221623
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_06_05_1222223.28231777
</commentlist>
</conversation>
