Slashdot Mirror
Java To Be Opened For Christmas?
MBCook writes "At the Oracle OpenWorld conference, Sun's CEO Jonathan Schwartz announced on Wednesday morning that Java would be opened within 30-60 days, which would would mean about Christmas Day at the latest. Sun first announced they would do this back in May at JavaOne but didn't give a date. We've seen rumblings before on this topic. Schwartz also commented on the companies Sun Fire servers, Sun's relationship with Oracle, and general trends."
Now maybe we can have a Java plug-in for 64-bit browsers.
Under what license?
If you mod this up, your slashdot background will turn into a beautiful sunset!
If the same intermediate language is generated from the Java frontend and the C frontend, and the Java bytecode backend handles that full language, it would be possible to compile C to Java bytecode.
my understanding was it was more like
java-->java bytecode-->GCC internal-->native code
the trouble with java bytecode is that if you wan't it to run on suns vm and certainly if you wan't it to run in any kind of restricted environment it has to pass the bytecode verifier. Short of essentially having an emulated main ram with a C heap inside it (possible but almost certainly not good for performance) passing the bytecode verifier with something compiled from C would be pretty damn hard.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
I can't believe how many IBM trolls are in this thread (and Slashdot as a whole) decrying Sun's lack of a track record in open sourcing their stuff.
Have they ever heard of NFS? OpenOffice? OpenSolaris?
Is there something wrong with the CDDL that's not wrong with the Mozilla license? From what I understand, the CDDL is similar to the Mozilla license but simpler. I invite every single one of those armchair critics to stop using Firefox if they're so adamant.
Unlike IBM (with the exception of Eclipse), Sun actually *open sources* stuff. I invite those IBM trolls to push their corporate master to open source WebSphere, DB2, Rational Rose, or Lotus Notes.
This space left intentionally blank.
Only if you redfine 'leak' to be something other than data which is no longer reachable.
A precise collector will always correctly identify the liveness of data, because it knows what is a pointer into the GCed heap. (That is the definition of a precise collector).
A conservative collector is used when an object may or may not be a pointer into the GC heap (e.g., it may be a pointer into memory that is not to be managed by the collector, sometimes it may be another type of object entirely). Conservative collectors must err on the side of retaining possibly (but not provably) unreachable objects, and so can leak. However, for a number of years now, modern approaches such as barriers and generational scavenging asymptotically eliminate such retained dead objects from the managed heap, unless they are deliberately created. Such deliberation usually requires some effort, can be prevented by the compiler, is readily detected at runtime, and is easy to debug.
Bad programming practices can result in the growth of lots of live data. Typically this involves using global variables. Sometimes this is accidental, such as when the top-level retains a history of results returned to it for debugging purposes or other convenience. However, these are not leaks per se -- the data is live in that it is reachable. Making the data in question unreachable (reset the global variable or previous-results list) will allow either type of collector to reclaim the space.
In general it is much more common that memory is consumed by abandoned data that was created in heaps not managed by the collector, and these heaps are almost always used by code written in another non-GCed language. This includes the runtime, libraries, and foreign functions. Usually this is fixed via careful wrapping of the non-GC-language code with finalizers (exceptions, dynamic winding/unwinding, and other techniques), and in most GCed languages which expect to interact with things like the POSIX API this is usually done through libraries written in the GCed language.
Finally, some GC implementations, particularly conservative ones, are simply buggy or are not using modern techniques. In this case it's the implementation's collector leaking, not the language.