Linked by kap1 on Thu 25th Apr 2013 11:45 UTC
Java The Lightweight Java Game Library provides a simple API to OpenGL, OpenAL, OpenCL and Game Controllers enabling the production of state of the art games for Windows, Linux and Mac. Version 2.9.0 contains a complete rewrite of the mac backend, support for FreeBSD, new OpenGL/OpenCL extension and bug fixes. The library is used by many high profile games such as Minecraft, Spiral Knights, Revenge of the Titans, Project Zomboid, Starsector, JMonkeyEngine, etc.
Thread beginning with comment 559886
To view parent comment, click here.
To read all comments associated with this story, please click here.
snowbender
Member since:
2006-05-04

With GC, we often take memory management for granted, but this can cause oversight of unnecessary alloc/frees activity going on under the hood that would have been caught if it were explicit.


This is a good, important point: when GC is available, a lot of developers take memory management for granted, and do not care about it anymore. I have the impression that the newer generations of developers do not even know what exactly is going on behind the scenes. And, personally, I think that you can only fully take advantage of things like e.g. GC if you do know what is going on behind the scenes. For the same reasons, I do think that it's very important to know the complexity of operations on data structures that are included in the vast libaries of e.g. Java and C#. Sadly, I've realized that only very few developers know for example the cost of adding a new element to an ArrayList.

Reply Parent Score: 2

Alfman Member since:
2011-01-28

snowbender,

"Sadly, I've realized that only very few developers know for example the cost of adding a new element to an ArrayList."

Oh man, you got me. I've used it many times, and yet I really don't know _what_ an "ArrayList" is. ;)

Reply Parent Score: 2

moondevil Member since:
2005-07-08

"With GC, we often take memory management for granted, but this can cause oversight of unnecessary alloc/frees activity going on under the hood that would have been caught if it were explicit.


This is a good, important point: when GC is available, a lot of developers take memory management for granted, and do not care about it anymore.
"

This is true even for manual memory management languages.

In languages that throw exceptions when memory allocation fails, Pascal family and C++, there is no difference from one with automatic memory management.

As for C, I have seen too much code where the value returned by malloc() and friends is never validated, or they get replaced by a macro that aborts on NULL.

Reply Parent Score: 2

Alfman Member since:
2011-01-28

moondevil,

"This is true even for manual memory management languages."

The state of what's going on in the head of the developer can be different though. The unmanaged developer implicitly will be aware of memory management in his application, otherwise it won't run well. The managed developer could be aware, but often is not. That's not necessarily a con, after all it makes programming a bit easier and allows him to concentrate on other things.


"As for C, I have seen too much code where the value returned by malloc() and friends is never validated, or they get replaced by a macro that aborts on NULL."

It's ok if it's the appropriate thing to do. I'm more annoyed that on platforms like linux, checking for null is futile because malloc always returns success and it's only when the page is accessed that it segfaults the process. No language can sanely handle OOM conditions when it cannot access the RAM, which malloc already returned successfully.

Reply Parent Score: 2