James Gosling Leaves Google 192
scottbomb writes "Well, that didn't take long: 'After only a few months at Google, Java founder James Gosling has left the search engine giant to go to a small startup company specializing in ocean-based robotics.' In a brief blog post about his new company, Gosling says, 'They have a growing fleet of autonomous vehicles that roves the ocean collecting data from a variety of onboard sensors and uploading it to the cloud. The robots have a pile of satellite uplink/GSM/WiMax communication gear and redundant GPS units. They have a bunch of deployments. For example, one is a set of robots patrolling the ocean around the Macondo well in the Gulf of Mexico monitoring water chemistry. These craft harvest energy from the waves for propulsion and can stay at sea for a very long time. The longest that one craft has been out is 2.5(ish) years. They can cross oceans.... Slowly. They only move at 1-2 knots, which is a great speed for data collection.'"
Re:SkyNet (Score:4, Informative)
I doubt Gosling has problems managing memory in Java.
I dunno, you've never run into the more infamous "java.lang.OutOfMemoryError: PermGen space"?
This is the error that's generated when the Java VM itself (well, the classloader, I guess) runs out of memory.
Because, unlike Java code itself, the Java classloader never frees memory it uses, which means that if you use a class briefly on startup, that code itself will be kept in memory indefinitely and never freed.
Which wouldn't matter as much, if there weren't this special "PermGen" space that used to default to 1MB. (It's slowly been increased as the versions go on and the size of Java programs continued to bloat, I think the default is now something like 16MB and can, as of five years ago, be user-set via a command line parameter.)
So what does this have to do with SkyNet? Well, if it's written in Java, it will run out of PermGen space well before its self-modifying code can accomplish anything.
And, given that PermGen space is never freed, apparently James Gosling does have problems managing memory in Java.
Re:SkyNet (Score:5, Informative)
PermGen is gone in newer versions of Java.
Re:Oracle? (Score:3, Informative)
Java is a "byzantine language", really? You must be a C coder if you seriously think so.
I'd say Linus Torvalds described this well enough.
KISS.
Keep it Simple and Slow? ~
Well, we're talking about Java vs C...
Seriously, there's a bad trend among some "modern" languages of piling up constructs without regards for efficiency, simplicity or sanity. For example, you can write a non-optimized compiler for languages I'd call sane in a week while for some a team in five years can't be expected to fully implement the standard. There is not a single compliant compiler of C++, and for Java it's only because of a skewed definition of "compliant" Sun has. And if you can't write a compiler reliably, how can you program in it?
The language with best balance between simplicity and featuritis I know is LPC. It has things sorely missing in C, like strings (something that C++ scrrewed in epic ways...), refcounted structures (arrays, mappings), closures, rudimentary OOP.
I did not get to learn golang yet, but it looks promising. I do have a bit of beef with some details, but nothing that'd make me vomit.
Re:SkyNet (Score:4, Informative)
Correct me if I'm wrong, but while the JVM doesn't free memory, it does recycle memory from it's allocated space. So, just because you might have accumulated the max memory your JVM might allocate, that doesn't mean your app isn't releasing memory back to the JVM. Kind of like super fetch except allocation is passive.
Re:SkyNet (Score:4, Informative)
As the other reply alluded this isn't a JVM problem but a problem with poorly written libraries. If a library sticks something in a ThreadLocal, creates a Thread, registers a JDBC driver, or several other tasks using classes from the webapp class loader and then DOESN'T CLEAN THEM UP when the webapp context is destroyed you get a ClassLoader leak. Just like any other Java memory leak it stems from having classes in the loader still reachable from the GC root.
Tomcat has made some great changes to their webapp classloader to watch for this bad behavior and forcibly remove/cleanup these references when a webapp shuts down, solving this problem in many cases.
Re:SkyNet (Score:4, Informative)
However this does often not happen because some objects keeps a (Normally static) reference to this class. An example where this often causes problems are with loggers because they often keep an static reference to a class, because they use it when generating debug output.
Removing all references to a class when doing dynamic class loading is not as easy as it sound, and I know that tomcat had huge problems with this in tomcat 5.5 and 6. I had to restart my 6.0 tomcat server used for development due to this problem because I had it configured to auto reload all newly generated classes. But it seems that they fixed that problem with tomcat 7, because I have not seen a PermGen exception since I upgraded.