You are confusing steam engines (trains) with steam engines (static and ships). The latter are significantly more efficient then the former. In fact the latter can be so efficient that we still use them today to generate electricity (turbines). However even the triple expansion engines used in early ships (before steam turbines becase fashionable in that role) were much more efficient than the single expansions used on trains. The investment needed to run these kinds of engines did not make economic sense on railways where teh journeys were relatively short and refills of fuel and water were accessible. Longer sea journeys required the ships to carry enough fuel and, strangely, water for the entire journey of a few thousand miles. (too complex to desalinate the sea water)
No I think that you are missing my point. Arguing that you should use CSS because it enables you to render to mobile phones is a specious argument. CSS is a good idea with an unremarkable and arguably poor design. However most mobile phones, at the moment, do not provide support for it and many provide no support for any kind of markup that CSS could be applied to. So your concept of just sending the "text" to the phone, without any styling, would still require processing of your xhtml/html document to remove the xhtml/html non-style tags and converting to a different/more limited markup. you may as well just write a custom page for mobiles (which, incidently, is exactly what many sites that support mobile do)
So yes CSS is a way forward. The mobile argument is currently dead in the water.
Another thing that is painfull with CSS is that is does not distinguish between style and layout.
CSS support on the mobile phones that support it is, in general, so appalling it just is not worth it. Not to mention the fact that most mobile phones don't support CSS at all. A very large number don't support HTML of any kind.
> The contracts would just operate like a home owner's association. If you sign a contract that says, "You will pay monthly fees to > the maintenance fund, and if you sell your property, the new owners will be bound by this contract", then the new property owners > will be bound by the contract as well (if the new owners don't like that idea, then they should choose not to buy your property. > Thus, if you sign a bad contract, you won't be able to sell your home for very much, if at all, because new buyers don't want to > enter into bad contracts).
I think you missed the point. Contracts are not commutative. If I sign a contract then it has no effect on anybody but the signatories. If I sell my house then the person who buys it has no obligations wrt the contract I signed (unless I, for some reason, am bound by a contract that says I cannot sell my house to someone who will not sign the contract that I signed). Strangely home owners associations are not popular in this country, perhaps it is because I live in a socialist country and we despise the freedom these housing associations bring.
>You're losing me. I have a contract with my apartment complex that says I will pay them a certain fee for the next 12 months in > exchange for allowing me to stay in their apartment. Once you sign the contract, it's done. What's stressful or time consuming > about that? It's not like we have to reach a new agreement every month. You sign the contract and it's done.#
I covered that. In an apartment complex or shared building you do not own the building you live in. You lease it. You own your flat/apartment but not the building it exists in. As such the owners of the building have the ability to tax you for living there for the purpose of upkeep of the building. That makes a great deal of sense as upkeep of the flat below yours ensures your flat stays up. Now what about the road that your appartment complex is built next to. Do you own that? Are you responsible for its upkeep? It services your building, why arn't you paying for it? Could it be that other people use the road? People who don't live near by? What about the sewars, are they just used by your building or does the building opposite use them as well. Are they mains lines? they could be used by a few square miles of the city. When they fail who pays?
Thats the problem with "services", they are needed by everybody so everybody needs to pay for them. It is remarkably inefficient for the physical infrastructure to be duplicated. So when a new building development is built the builders provide the roads and fresh water and sewage to the development. What do they connect to? The next development along requires contracts signed with the signatories of the maintenance contracts of the development you are connecting to. Remember that connecting your road to one of thiers increases the usage of thier roads so you should be partially responsible for the repairs to thier roads. Same with sewage and water.
It took my parents 2 years to find out who owned the sewar outside thier house. Guess what...They owned it. The neigbours found out, rather unpleasently (the cause for the investigation) that a main sewar line ran under thier house, beneath thier living room to be precise. Guess what...They owned it, but interestingly they did not and could not use it. It seems that nobody owns the road, at least nobody traceable. Private contracts are all well an good but tend to be forgotten quite quickly. They also are often not valid to begin with.
You would know why people don't want to own thier own pipes if you owned your own. In parts of the UK the property owners are responsible for the roads and pipes connecting tho thier house. They don't actually own them as they are often not on thier property but are responsible for the upkeep. It takes time and effort to run the system. It costs a LOT of money to repair it (and good luck getting people to agree to pay for it)
Now, in an ideal society nobody would complain or disagree that the road needs resurfacing or that everybody should pay to replace the common sewage pipes that are fractured under your property. In reality it is a very time consuming and stressful task to get any issues resolved (as everyone has to agreeand pay). Most people are more then happy to just pay regular bills to a service provider (or the local council) and have it all sorted out (with only a little bit of nagging required)
Also note that when someone buys a new house they are under no obligation to sign a contract with anyone that is related to infrastucture so it cannot be handled by contract (actually it can in shared buildings as the building tends not to be owned by the residents so the buildings owners can enforce membership and constributions to a maintenance fund.)
> in order to check in any code, no matter how inconsequential, it has to be reviewed by at least one other dev
This is very good advice.
Disk crashes or roll backs are a function of your VCS. The process I follow is that code is commited to the VCS in a sub stream. It can then be reviewed by a coworker who can, if they think it is OK, commit it to the main stream. This way disk crashes are not a problem. Roll backs are also fairly trivial if you commit your code regularly to your private stream (or use a IDE that integrates local revision control).
Also raided disks for developers is a good idea to work around those inconvienient disk crashes when you have't commited recently.
The govenment can and does create "wealth". It provides the education needed for the economy to work. It provides the road systems needed for efficient transport of goods. It provides many things with the taxes it levies that promote the generation of wealth. In fact it often creates wealth directly by funding research that companies don't deem profitable in the short term and therefore do not invest in. That creates value.
Whether it should interfere quite so much is a different issue.
The capital to invest in this way comes from taxes. But to claim that you derive no benifit from the taxes you pay is disingenuous at best, a lie at worst.
Commodity PCs with comodity graphics boards can not compete with SGI products. SGI is marketing its products at companies that need very high quality visualization. They sell large computers with a unified shared memory architecture and graphics subsystems that can take advantage of that shared memory (although I think they now use commodity GPU chips). They are good for some simulation systems.
Unfortunately there does not appear to be a market for them.
I find it interesting when people say "But Yahoo uses PHP". I know for a fact that they also use many other technologies. Java being one of them. The company I work for writes software. Its written in java. Yahoo uses it for thier mobile sites.
The question does not define any problem. It does not define how many cupckes each person needs to have. You could make two hundred cupcakes with sprinkles on and still satify the problem as written.
You have been able to get these tokens in credit card size for years. They just arn't very popular as they tend to break easily because of the shape (unlike credit cards they have glass screens in them which don't take well to bending). A small bulbous (as the example in the article) shape is less easy to damage by sitting on. The fobs they are looking at are only about 1 inch long, 1/2 inch wide and 1/4 inch think.
I don't think you would need to set fire to the ships (or blind the men). Just heat the crew to 80 or 90 degrees C and watch them jump overboard. Far easier to achive then the 700-800 dC needed to set fire to wood.
> Well, kind of. The JOP is an FPGA, so its only real native instrcutions are in the HDL. The JOP processor could be reprogrammed to emulate just about any > architecture you wanted it to. FPGAs are cool, but they do have their drawbacks such as higher power consumption and slower than their ASIC counterparts, > but that's another subject.
Seems to me that JOP is a processor defined in HDL. It has a native instruction set consiting of bytecode instructions. It has a simpler underlying microcode that is used to handle the more complex bytecode instructions. The fact that it is currently being run on a FPGA is niether here nor there.
> I'm going to disagree here as well. The term virtual machine just simply does not apply to native compiled languages, as there is nothing virtual about the > hardware to which you are compiling to. Java does compile to a virtual machine, as for the most part there aren't many machines out there that support > Java natively.
You seem to be implying that java bytecode ceases to be bytecode when you run it on a java processor, but is bytecode when you run it in a virtual machine. Its the same stuff, it hasn't changed. Does code compiled for the motoroller 68k instruction set suddenly become bytecode when you try to run it in mame? does it somehow change?
Does code compiled for a x86 processor run natively? Considering most x86 processors emulate (albeit in hardware) the x86 instruction set on top of a "risc"ish core the definitions become ambiguous.
Anyway it interests me. The whole concept of processors with direct support for high level languages. The lack of pointers in java mean that many of the reasons you would normally have a mmu for cease to exist (in smaller systems anyway) ( you can't bugger up memory that does not belong to you). The garbage collector can allocate all avaialble memory on the system and manage it efficiently. Some nice ideas, especially for embedded systems.
>That has nothing to do with the language, and everything to do with the compiler and linker for the platform. In the end, you wind >up with native CPU instructions. If the processor supports flops, then the compiler/linker will use flops. If the processor does >not, then it will use whatever algorithm to replace the flop code with. That's the whole purpose of cross compilers such as gcc. It >takes C code and compiles it for a given platform. If the platform doesn't support certain operations then those operations are >replaced at compile time with whatever the platform needs to approximate/implement said feature."
What? you mean Gcc starts emulating instructions that if implimented in hardware would give you far greater performance? (before you say it. Yes it does. it is EMULATING behaviour that does not exist natively.)
>I'm well aware of the fact that J2ME is cut down. I've written several games in J2ME. But you seem to be a little confused. J2ME >has a bytcode spec, and several chip manufacturers follow the spec for J2ME microcontrollers but that is not native execution. The >translation from bytcode to CPU instructions happens in hardware, which is fast to be sure but still is not native CPU code."
In most mobile devices I have used they have NO native support for the execution of bytecode. It is all emulated. What I was attempting to suggest is that J2ME specifies the minimum requirements for the developer to use. Whether those requirements are met by emulation on an 8 bit microcontroller or have corresponsing 32 bit instructons on a strongarm. The 8 bit micro has top provide a development environment that supports 32 bit math whether emulated or not.
>"The processors I'm playing with at the moment run java byte code natively."
>>No they don't. They have a "hardware JVM" for lack of a better term. The CPU is not running bytecode. None of the processor >>families I found doing a quick search have a J2ME bytcode based instruction set. Underneath, they are still running ARM, Fujitsu, >>etc. chips, which use their normal CPU instructions to execute."
Umm, Yes they do. For example I am currently playing around with JOP http://www.jopdesign.com/ This is a processor whose native instruction set is java byte code. Unless C can compile code to JBC then it would have to run in an emulation layer on this processor (I have yet to see a c compiler that can produce java byte code. It Could be done I just have not seen it yet)
>Bytecode and machine code are two different things.
No they are not. Bytecode is machine code for a "java virtual machine". It is called a Virtual Machine because hardware implementations did not exist when java bytecode was developed therefore they were all interpreted. Processors that handle bytecode natively do exist.
C and java require a "virtual machine" in the same way. However Java targets one architecutre (java byte code) and C targets many (any instruction set that can be targeted by your compiler).
Jop, Cjip, aJ-100, are all processors that run bytecode natively. Even sun produced one back in 95 (cant remeber the name but it was a hacked up sparc)
"But garbage collection only helps you manage one sort of resource. In C++, the RAII techniques that help you manage memory are good for every resource, from file handlers to database connections. Resource management in Java is not so nice. Often it is quite a hassle."
Good point. Java is very poor at handling non memory resources. Most software asks the user to release the resources and if they don't it attempts to clear up using finalization, which in my opiniion is a truely nasty hack to get around the fact that the coder using the software forgot to clean up after himself. The GC and finalization is NOT appropriate for handling non memory resources.
The worst case of this I have come across is Mapped Memory (you can do it in java). If you map a block of memory, then drop references to it, it will not be cleaned up until the GC decides to. This causes a problem as virtual address space is quite limited oin 32 bit systems. So if you allocate lots of memory mapped blocks it will run out of virtual address space. When its does this it will run out of address space (which it thinks is memory) and attempt to free physical memory. Humm there is negligible physical memory to free!. Hence in general the GC does not finalize the objects holding the memory mapped resources. So your program fails. (Worse than that, there is no method to manually free the underlying resources (shear bad design)).
Its ashame there are few better ways to do it in java. (actually in many situations good design can help alot but not always)
And yes I do like java. Its the edge conditions that piss me off. Lukily they are rarely relevent.
I would have to agree, especially on the firefox part. Leave it running for a couple of days, like I do when at work, and you will find it is using well over 1G of ram.
Java has a huge problem with memory resources.It does not integrate well with the OS (ie it does not know when increasing its heap with cause frantic swappage). It does not work well on machines with small quantities of ram (unless you specify individual heap/gc parameters for all you java apps (which is well worth doing))
However in server environments (and very low end devices) where you tend to only run one app at a time the performance is very good.
Before you complain. I run IntelliJ idea, Tomcat, Ant (and a few other java apps) all at the same time (sometimes multiple copies of each) and have no problems. But the computer I run them on has 2 Gig of ram. With 1 Gig I was struggling a bit.
Slashdot Mirror
Perhaps because people have a tendancy to drive "through the middle of nowhere" to get from "somewhere" to "somewhere else".
Talk about self fulfilling prophecies.
You are confusing steam engines (trains) with steam engines (static and ships). The latter are significantly more efficient then the former. In fact the latter can be so efficient that we still use them today to generate electricity (turbines). However even the triple expansion engines used in early ships (before steam turbines becase fashionable in that role) were much more efficient than the single expansions used on trains. The investment needed to run these kinds of engines did not make economic sense on railways where teh journeys were relatively short and refills of fuel and water were accessible. Longer sea journeys required the ships to carry enough fuel and, strangely, water for the entire journey of a few thousand miles. (too complex to desalinate the sea water)
No I think that you are missing my point. Arguing that you should use CSS because it enables you to render to mobile phones is a specious argument. CSS is a good idea with an unremarkable and arguably poor design. However most mobile phones, at the moment, do not provide support for it and many provide no support for any kind of markup that CSS could be applied to. So your concept of just sending the "text" to the phone, without any styling, would still require processing of your xhtml/html document to remove the xhtml/html non-style tags and converting to a different/more limited markup. you may as well just write a custom page for mobiles (which, incidently, is exactly what many sites that support mobile do)
So yes CSS is a way forward. The mobile argument is currently dead in the water.
Another thing that is painfull with CSS is that is does not distinguish between style and layout.
CSS support on the mobile phones that support it is, in general, so appalling it just is not worth it. Not to mention the fact that most mobile phones don't support CSS at all. A very large number don't support HTML of any kind.
> The contracts would just operate like a home owner's association. If you sign a contract that says, "You will pay monthly fees to
> the maintenance fund, and if you sell your property, the new owners will be bound by this contract", then the new property owners
> will be bound by the contract as well (if the new owners don't like that idea, then they should choose not to buy your property.
> Thus, if you sign a bad contract, you won't be able to sell your home for very much, if at all, because new buyers don't want to
> enter into bad contracts).
I think you missed the point. Contracts are not commutative. If I sign a contract then it has no effect on anybody but the signatories. If I sell my house then the person who buys it has no obligations wrt the contract I signed (unless I, for some reason, am bound by a contract that says I cannot sell my house to someone who will not sign the contract that I signed). Strangely home owners associations are not popular in this country, perhaps it is because I live in a socialist country and we despise the freedom these housing associations bring.
>You're losing me. I have a contract with my apartment complex that says I will pay them a certain fee for the next 12 months in
> exchange for allowing me to stay in their apartment. Once you sign the contract, it's done. What's stressful or time consuming
> about that? It's not like we have to reach a new agreement every month. You sign the contract and it's done.#
I covered that. In an apartment complex or shared building you do not own the building you live in. You lease it. You own your flat/apartment but not the building it exists in. As such the owners of the building have the ability to tax you for living there for the purpose of upkeep of the building. That makes a great deal of sense as upkeep of the flat below yours ensures your flat stays up. Now what about the road that your appartment complex is built next to. Do you own that? Are you responsible for its upkeep? It services your building, why arn't you paying for it? Could it be that other people use the road? People who don't live near by? What about the sewars, are they just used by your building or does the building opposite use them as well. Are they mains lines? they could be used by a few square miles of the city. When they fail who pays?
Thats the problem with "services", they are needed by everybody so everybody needs to pay for them. It is remarkably inefficient for the physical infrastructure to be duplicated. So when a new building development is built the builders provide the roads and fresh water and sewage to the development. What do they connect to? The next development along requires contracts signed with the signatories of the maintenance contracts of the development you are connecting to. Remember that connecting your road to one of thiers increases the usage of thier roads so you should be partially responsible for the repairs to thier roads. Same with sewage and water.
It took my parents 2 years to find out who owned the sewar outside thier house. Guess what...They owned it. The neigbours found out, rather unpleasently (the cause for the investigation) that a main sewar line ran under thier house, beneath thier living room to be precise. Guess what...They owned it, but interestingly they did not and could not use it. It seems that nobody owns the road, at least nobody traceable. Private contracts are all well an good but tend to be forgotten quite quickly. They also are often not valid to begin with.
You would know why people don't want to own thier own pipes if you owned your own. In parts of the UK the property owners are responsible for the roads and pipes connecting tho thier house. They don't actually own them as they are often not on thier property but are responsible for the upkeep. It takes time and effort to run the system. It costs a LOT of money to repair it (and good luck getting people to agree to pay for it)
Now, in an ideal society nobody would complain or disagree that the road needs resurfacing or that everybody should pay to replace the common sewage pipes that are fractured under your property. In reality it is a very time consuming and stressful task to get any issues resolved (as everyone has to agreeand pay). Most people are more then happy to just pay regular bills to a service provider (or the local council) and have it all sorted out (with only a little bit of nagging required)
Also note that when someone buys a new house they are under no obligation to sign a contract with anyone that is related to infrastucture so it cannot be handled by contract (actually it can in shared buildings as the building tends not to be owned by the residents so the buildings owners can enforce membership and constributions to a maintenance fund.)
Sun's java compiler IS written in java.
As for the VM, you don't need one if you hava a native java processor.
Is that you Adrian? Sounds familiar
> in order to check in any code, no matter how inconsequential, it has to be reviewed by at least one other dev
This is very good advice.
Disk crashes or roll backs are a function of your VCS. The process I follow is that code is commited to the VCS in a sub stream. It can then be reviewed by a coworker who can, if they think it is OK, commit it to the main stream. This way disk crashes are not a problem. Roll backs are also fairly trivial if you commit your code regularly to your private stream (or use a IDE that integrates local revision control).
Also raided disks for developers is a good idea to work around those inconvienient disk crashes when you have't commited recently.
You also have a simpltons view of economics.
The govenment can and does create "wealth". It provides the education needed for the economy to work. It provides the road systems needed for efficient transport of goods. It provides many things with the taxes it levies that promote the generation of wealth. In fact it often creates wealth directly by funding research that companies don't deem profitable in the short term and therefore do not invest in. That creates value.
Whether it should interfere quite so much is a different issue.
The capital to invest in this way comes from taxes. But to claim that you derive no benifit from the taxes you pay is disingenuous at best, a lie at worst.
Yep, and that health insurance, home insurance, car insurance that you have are all evil socialist ideas too.
> Maybe they can help the Brits so they don't have to hold people for 90 days without charge so they can fish in their hard drives.
Thankfully that bill was defeated yesterday.
Commodity PCs with comodity graphics boards can not compete with SGI products. SGI is marketing its products at companies that need very high quality visualization. They sell large computers with a unified shared memory architecture and graphics subsystems that can take advantage of that shared memory (although I think they now use commodity GPU chips). They are good for some simulation systems.
Unfortunately there does not appear to be a market for them.
I find it interesting when people say "But Yahoo uses PHP". I know for a fact that they also use many other technologies. Java being one of them. The company I work for writes software. Its written in java. Yahoo uses it for thier mobile sites.
The question does not define any problem. It does not define how many cupckes each person needs to have. You could make two hundred cupcakes with sprinkles on and still satify the problem as written.
ye gods, they nicked our road signs
w arning.htm
http://www.bcvr.co.uk/guide-to-driving/roadsigns/
You have been able to get these tokens in credit card size for years. They just arn't very popular as they tend to break easily because of the shape (unlike credit cards they have glass screens in them which don't take well to bending). A small bulbous (as the example in the article) shape is less easy to damage by sitting on. The fobs they are looking at are only about 1 inch long, 1/2 inch wide and 1/4 inch think.
I don't think you would need to set fire to the ships (or blind the men). Just heat the crew to 80 or 90 degrees C and watch them jump overboard. Far easier to achive then the 700-800 dC needed to set fire to wood.
Rome sacked Syracuse because someone opened the gates and invited them in.
> Well, kind of. The JOP is an FPGA, so its only real native instrcutions are in the HDL. The JOP processor could be reprogrammed to emulate just about any
> architecture you wanted it to. FPGAs are cool, but they do have their drawbacks such as higher power consumption and slower than their ASIC counterparts,
> but that's another subject.
Seems to me that JOP is a processor defined in HDL. It has a native instruction set consiting of bytecode instructions. It has a simpler underlying microcode that is used to handle the more complex bytecode instructions. The fact that it is currently being run on a FPGA is niether here nor there.
> I'm going to disagree here as well. The term virtual machine just simply does not apply to native compiled languages, as there is nothing virtual about the
> hardware to which you are compiling to. Java does compile to a virtual machine, as for the most part there aren't many machines out there that support
> Java natively.
You seem to be implying that java bytecode ceases to be bytecode when you run it on a java processor, but is bytecode when you run it in a virtual machine. Its the same stuff, it hasn't changed. Does code compiled for the motoroller 68k instruction set suddenly become bytecode when you try to run it in mame? does it somehow change?
Does code compiled for a x86 processor run natively? Considering most x86 processors emulate (albeit in hardware) the x86 instruction set on top of a "risc"ish core the definitions become ambiguous.
Anyway it interests me. The whole concept of processors with direct support for high level languages. The lack of pointers in java mean that many of the reasons you would normally have a mmu for cease to exist (in smaller systems anyway) ( you can't bugger up memory that does not belong to you). The garbage collector can allocate all avaialble memory on the system and manage it efficiently. Some nice ideas, especially for embedded systems.
matfud
So I exagerated a bit
6312 anonymous 15 0 442m 258m 17m S 0.3 12.8 145:35.09 firefox-bin
Its only using half a gig of ram after 2 or 3 weeks
>That has nothing to do with the language, and everything to do with the compiler and linker for the platform. In the end, you wind
>up with native CPU instructions. If the processor supports flops, then the compiler/linker will use flops. If the processor does
>not, then it will use whatever algorithm to replace the flop code with. That's the whole purpose of cross compilers such as gcc. It
>takes C code and compiles it for a given platform. If the platform doesn't support certain operations then those operations are
>replaced at compile time with whatever the platform needs to approximate/implement said feature."
What? you mean Gcc starts emulating instructions that if implimented in hardware would give you far greater performance? (before you say it. Yes it does. it is EMULATING behaviour that does not exist natively.)
>I'm well aware of the fact that J2ME is cut down. I've written several games in J2ME. But you seem to be a little confused. J2ME
>has a bytcode spec, and several chip manufacturers follow the spec for J2ME microcontrollers but that is not native execution. The
>translation from bytcode to CPU instructions happens in hardware, which is fast to be sure but still is not native CPU code."
In most mobile devices I have used they have NO native support for the execution of bytecode. It is all emulated. What I was attempting to suggest is that J2ME specifies the minimum requirements for the developer to use. Whether those requirements are met by emulation on an 8 bit microcontroller or have corresponsing 32 bit instructons on a strongarm. The 8 bit micro has top provide a development environment that supports 32 bit math whether emulated or not.
>"The processors I'm playing with at the moment run java byte code natively."
>>No they don't. They have a "hardware JVM" for lack of a better term. The CPU is not running bytecode. None of the processor
>>families I found doing a quick search have a J2ME bytcode based instruction set. Underneath, they are still running ARM, Fujitsu,
>>etc. chips, which use their normal CPU instructions to execute."
Umm, Yes they do. For example I am currently playing around with JOP http://www.jopdesign.com/ This is a processor whose native instruction set is java byte code. Unless C can compile code to JBC then it would have to run in an emulation layer on this processor (I have yet to see a c compiler that can produce java byte code. It Could be done I just have not seen it yet)
>Bytecode and machine code are two different things.
No they are not. Bytecode is machine code for a "java virtual machine". It is called a Virtual Machine because hardware implementations did not exist when java bytecode was developed therefore they were all interpreted. Processors that handle bytecode natively do exist.
C and java require a "virtual machine" in the same way. However Java targets one architecutre (java byte code) and C targets many (any instruction set that can be targeted by your compiler).
Jop, Cjip, aJ-100, are all processors that run bytecode natively. Even sun produced one back in 95 (cant remeber the name but it was a hacked up sparc)
matfud
"But garbage collection only helps you manage one sort of resource. In C++, the RAII techniques that help you manage memory are good for every resource, from file handlers to database connections. Resource management in Java is not so nice. Often it is quite a hassle."
Good point. Java is very poor at handling non memory resources. Most software asks the user to release the resources and if they don't it attempts to clear up using finalization, which in my opiniion is a truely nasty hack to get around the fact that the coder using the software forgot to clean up after himself. The GC and finalization is NOT appropriate for handling non memory resources.
The worst case of this I have come across is Mapped Memory (you can do it in java). If you map a block of memory, then drop references to it, it will not be cleaned up until the GC decides to. This causes a problem as virtual address space is quite limited oin 32 bit systems. So if you allocate lots of memory mapped blocks it will run out of virtual address space. When its does this it will run out of address space (which it thinks is memory) and attempt to free physical memory. Humm there is negligible physical memory to free!. Hence in general the GC does not finalize the objects holding the memory mapped resources. So your program fails. (Worse than that, there is no method to manually free the underlying resources (shear bad design)).
Its ashame there are few better ways to do it in java. (actually in many situations good design can help alot but not always)
And yes I do like java. Its the edge conditions that piss me off. Lukily they are rarely relevent.
matfud
I would have to agree, especially on the firefox part. Leave it running for a couple of days, like I do when at work, and you will find it is using well over 1G of ram.
Java has a huge problem with memory resources.It does not integrate well with the OS (ie it does not know when increasing its heap with cause frantic swappage). It does not work well on machines with small quantities of ram (unless you specify individual heap/gc parameters for all you java apps (which is well worth doing))
However in server environments (and very low end devices) where you tend to only run one app at a time the performance is very good.
Before you complain. I run IntelliJ idea, Tomcat, Ant (and a few other java apps) all at the same time (sometimes multiple copies of each) and have no problems. But the computer I run them on has 2 Gig of ram. With 1 Gig I was struggling a bit.