Java To Be Opened For Christmas? 243
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."
64-bit (Score:5, Interesting)
License (Score:5, Interesting)
Don't get yer hopes up (Score:2, Interesting)
But at this point it really doesn't matter anymore. GCJ already builds many major Java based apps into either Java bytecode or native executables and has long since passed the point where development would be hindered by a Open Source/Free Software release of Sun's version.
GCJ is now bringing a lot more to the table than just cloning the Sun stuff. Sun would never do native executables because it doesn't fit into their 'vision.' The JVM and Write Once Debug Everywhere has no real place in the Free Software world. In the Free world portability comes from automake/autoconf and doesn't need to pay the emulation overhead of a virtual machine or any of the other problems. Problems like each major Java app tending to bring along an entire JVM and set of libraries to solve compatibility issues.
Something I have been wondering.... GCC now accepts Java source and emits either native binaries or Java bytecode. Can it take C/C++/etc and emit bytecode? If it is treating bytecode as just another target what if a C# frontend were written? Could gcc take C# on input and emit Java bytecode on the other end? And if a mono backend were added could it compile Java source to it? And if this all came to pass would it be a sure sign the end of times were at hand?
Re:License (Score:5, Interesting)
Re:Don't get yer hopes up (Score:3, Interesting)
Not really. GCC generates x86 code in the backend, which operates on some intermediate language. 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.
Re:64-bit (Score:4, Interesting)
Re:Don't get yer hopes up (Score:3, Interesting)
It isn't, if you're targetting bytecode. Bytecode is handled as a special case which bypasses GCC's RTL representation.
Since the JVM doesn't allow arbitrary access to memory, it's not feasible to make a Java bytecode backend for GCC. (Java bytecode is Turing complete, so it's technically possible; but you'd have to resort to ugly hacks like representing memory as a gigantic, flat array of bytes.)
Re:Don't get yer hopes up (Score:4, Interesting)
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.
Re:Finally (Score:1, Interesting)
Sun needs, desperately, to make their implementation of Java the defacto standard with Linux distributions. Their problem is Java is becoming open source right now [kaffe.org]. That's a comparison between a cleanroom, GPL implementation [gnu.org] of Java and Sun's JDK 1.4. That's approximately 99% compatible aside from the swing api. And for a Tomcat or Jboss, that's all you need. Debian already distributes this in the main repository with SableVM. Red Hat favors GCJ.
Right now Sun is on the cusp of becoming irrelevant. They wanted so badly to prevent a fork of Java but it is already forked right under their noses. They need to dump a superior, complete, open source version of Java on the market RIGHT NOW and sweep support out from under these other projects and kill them with extreme prejudice. Lets face it, Solaris has no takers outside hardcore enterprise customers because we open sourced around them. In another year Sun's JDK will be just "that JDK that comes with Solaris" if they don't do something really soon. Then Java is forked and Sun has lost the standards battle with Microsoft in their eyes.
Personally, I think an independent Java Foundation needs to get spun off. That way IBM, Sun, Oracle, Red Hat, Intel, HP, and Apple can dump research money into Java without all the discomfort of working with a direct competitor. And finally, fast VM technology will enter the public domain and we can get rid of all this slow ass interpreted shit.
Re:64-bit (Score:3, Interesting)
I don't like it, but hope for a GCJ killer (Score:1, Interesting)
As you can see today with many package maintainers who's only link with the software they're maintaining is that they like it. Only 2 weeks ago did I try to utilize FreeBSD and its ports. I already installed MySQL 4.x and then wanted dspam. No go.. It demanded I used MySQL 5.x. A perfect example IMO, the package maintainer asks...
And that is why I don't like the idea of Java going open source. Still, despite all that I truly hope it might turn out to be a GCJ killer. Why? If there is one thing turning off Linux people from Java it has got to be gcj.. How frustrating can it be when you're trying example code and only come to the conclusion that it simply doesn't work? You typed everything as it should, you studied the code yourself but yet it does. not. work. Well, enter gcj hell. If you're going over the Java tutorials [sun.com] you'll be sure to run into some beginner examples which will not run when using gcj.
In fact, many of the usenet and irc groups I'm on start asking people if they're using gcj when experiencing problems on Linux. If so then the advice is: ditch that POS and get the JVM from Sun. Strangely enough this fixes the problem in most of the cases. So yes, I don't like the idea of Java going open source but I'd be very pleased if this stopped the gcj idiocy and got distributions to ship with the official and working Java Virtual Machine. The one from Sun ofcourse...
IBM Trolls (Score:5, Interesting)
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.
Re:64-bit (Score:2, Interesting)
I dunno if that's the case in Java, but any "hello world" Win32 program is certainly single-threaded.
Re:Don't get yer hopes up (Score:3, Interesting)
I have worked on shrinked wrap software that was intended to run on both Linux and Windows, and i can tell you that there are little bugs that crop up now and then due to inconsistent handling, rendering issues, font issues, and especially in the way the Look and feels work. Granted it's not as bad as most people think and mostly it's bugs in Java's default libraries, but there ARE issues, and you shouldn't just dismiss them with a wave of the hand just because you have not had an occasion to experience one
I just want to offer a counterpoint to this... I did Java development at IBM for a summer internship. We were doing server-side stuff (which would, granted, bypass the most difficult platform-specific stuff, the GUI), but we developed on Windows on just typical laptops. The final target for the program was s390 Linux. Change of OS, change of architecture, even change of character set from ASCII to EBCDIC. You'd be hard pressed to find a larger platform transition. We had to make one change to the program to get it to run as well on there as it did on our laptops. I was quite impressed.
Re:Isn't the garbage collector supposed to minimiz (Score:4, Interesting)
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.
Re:64-bit (Score:1, Interesting)
On any of the netburst P4's there were multiple execution units, be they HT or not. There was also a clever scheduler that would take the instruction stream (from a single thread) and figure out the interdependancies between the instructions - so that instructions could be executed in parallel on the multiple execution units. This helped hide the hideous latency problems with the netburst architecture as the instruction pipeline was so long.
What intel realised was that many of these extra execution units were infact idle much of the time because there weren't enough independant instructions coming through on a typical thread - even with their clever compilers. So they discovered that they could actually simply (well probably not) add another scheduler to the processor that used these spare slots on the existing execution units. All it took was something like a 5% increace in transistor count and they got the capability of running another thread on the same processor - so this was cheap in comparison. Also AFAIK that's why it's not there on the Core processors - they don't have the same super long pipelines so there is way less benefit.
So in theory turning HT on makes the machine simply seem to run faster as it has a second logical processor. The units themselves don't run at half the speed though if you turn hyperthreading off, they run at the same speed.
So on the face of it HT should be a win-win situation. However there are gotcha's involved. Firstly there is cache - both the threads share the same cache. This is made even worse by windows by default creating threads that are on 1MB memory boundaries - which means that they actually share cache lines in cache because of the way the aliasing works (why they thought this was a good idea in the first place I don't know). This can make HT much much slower than non HT but is easy to get around.
Also things that do busy-waiting loops rather than using OS sleep (something you shouldn't ever do of course) will flood the execution units and so take away from the non-waiting threads capacity.
These are almost certainally why your stuff runs slower in HT mode - it was written without considering HT in the fisrt place.