Slashdot Mirror
Java3D Source Code Released
mrp101 writes "Over the past few months (aka year) the future of Java3D has been in question. Not too long ago Apple announced a port to Mac OS X, but still no official update from Sun. A few weeks ago Sun announced that they were going to release the source code and begin collecting comments for version 1.4/2.0. And today they delivered, right before the JavaOne conference. The announcement can be found here(1) and
the CVS here(2). The code includes the core scenegraph, the vector math library, and Sun's own add-on utility libraries."
If the final release of Looking Glass turns out to be as impressive as the demo shows, I don't think anyone will ever doubt Java as a 3D application language.
Java hasn't been interpreted byte code (strictly speaking) for some time now. The byte code gets compiled to native code at runtime, with optimizations that are determined by the runtime behavior of the code rather than by simple static analysis.
Here is the link to the blog entry about open sourcing solaris
one of my personal favs... http://equinox.planet-d.net/java/vectorball/
Java3D was used for the game Roboforge. It was also used in Law and Order: Dead on the Money.
No data, no cry
FYI, OpenOffice.org is LGPL and SISSL. Not GPL.
You are dreaming! BSD for the utils and examples. Whoopie.
The main product...
Get a clue, dude. It depends on the platform. If you're running on an x86, yes, the IEEE FP standard that is used by x86 CPUs is the backward one. SPARCs support nateively the same FP format, and that's the reason Sun chose it. Intel has been bitching for years to Sun asking them to change the format to one that does not require conversion for x86 systems. If Intel had chosen the better format, they wouldn't have this problem. Try runing FP on a SPARC -- it's on par with C++ code.
While the examples and utilities for Java3D are being released under a BSD-like license, Java3D itself is being released under the Java Research License, which is neither a Free Software license nor an Open Source license. It allows use of the code for research purposes only.
You've been listening to PJ's anti-Sun rants for too long.
Heh...I love Groklaw, and PJ's probably really nice.. but she does seem to have it in for Sun for some reason.
Yes, Sun has been a little wishy-washy in terms of whether they want to support Linux or want to see it die.. but otherwise they've been fairly friendly to the FOSS communities over the years... dating at least back to the time when they released the source for the ONC-RPC / NFS stuff... and of couse they support Open Office and NetBeans, etc... and let's not forget the various code donations they've made to Apache projects, like Tomcat, etc...
// TODO: Insert Cool Sig
Only the utils and examples are released under the BSD license. The core and vecmath libraries are released under licenses named Java Development License and Java Research License. These are most definitely not OSI-approved Open Source licenses.
Life is complete only for brief intervals in between toys or projects -- John Dalton
I believe that it is possible for Java3D implementations to be (partial) wrappers around hardware-based OpenGL/DirectX functionality.
Well, there are several projects available which make OpenGL available for Java programmers.
Lightweight Java Game Library
Open GL for Java
Don't think the second one is still being developed, but I think Sun is working on something more up to date.
Being bitter is drinking poison and hoping someone else will die
Plenty of companies own lots of high-end Sparc boxes. Think of all the E10Ks, Starfires and newer boxes that have been purchased throughout the dot-com era and still today. Typically they're acting as the big number crunchers on databases or application servers for websites - places where Java is by far the dominant development language in use today.
Life is complete only for brief intervals in between toys or projects -- John Dalton
Java was 2 decimal orders of magnitude (ie. 100x) slower
I'm sorry if this sounds harsh, but its not Java that is slower, its your code. Modern Java is regularly benchmarked as being around the same as C++ or Fortran for numerical work.
However, I have seen some numeric Java code run a lot slower than C++ code. The usual reason is the way data structured are coded. If you use Collection classes in Java you will get slow access to your data. If you use Arrays and code carefully, there is no reason for Java to be significantly slower than C++, and certainly not 100x!
I dont know about SPARC, but Java 1.4 on x86 can hand off FP maths to the SSE registers, rather than the classic "shite" x86 FPU, the one Patterson and Hennessey cover as a "what not to do" example in their Computer Architecture Book.
And that is one of the nice things of Java: you get a boost from whatever accelleration is in the platform, if the compiler handles it.
I think to make best use of the SIMD features in modern CPUs we need better array operations with compilers/runtimest that bind to the new SIMD FPUS. I think Fortran still has the edge there, for historical reasons.
AltiVec Instruction reference for the G4 say that one extra CPU cycle is needed when using java FP. Why is this relevant? Because the topic is 3D involving vector processing.
Now thats interesting. I didn't use collections or any ADTs actually. All I used were simple doubles held in a class with operations performed on them.
I unlike many others am willing to put my code where my mouth is, so I will implement a rigorous floating point benchmark in both C++ and Java and I'll be more than happy to have people school me on my crappy Java coding by optimizing it to be as fast (or with 90%) of the C++ code.
You want to know about Java3D and why people love it? Try looking towards the medical profession, especially radiology and surgical planning. There are a number of Java3D based DICOM viewers out there for viewing CT and MRI images, such as SPLViz and VisAdd.
The cross-platform portability means that the same CT and MRI images can be loaded up onto the same viewer on both the doctor's office PC workstation, their home macintosh or linux system, or even onto one of the esoteric workstations.
To get a better handle on why this images are needed, read up on this article: Combining Local and Remote Visualization Techniques for Interactive Volume Rendering in Medical Applications, and check out the Stanford-NASA National Biocomputation Center Website.
Once you dive around those articles and websites, you'll realize that Java3D supports alot of exotic hardware, such as 5 megapixel LCD monitors, Projection Tables for Virtual and Augmented Reality and Virtual Surgery Tables.
Radiograph images in most hospitals are obtained on VAX or QNX or HP Unix systems, and are then transmitted to Solaris or Windows workstations/servers for post processing. It's typical to have sometype of Oracle database sitting on an imaging archive (we have a 20TB archive, for example), feeding images to the clients sitting on workstations. Sometimes the images are saved as 3D volumetric data, although usually they're saved as 2D slices. So, you need some type of portable 3D viewing application that can sit on nearly any type of box, and can compile the radiographs for whatever local viewing equipment is available...
FYI, medical systems have to conform and perform according to federally mandated law, and there isn't the market pressure to compete with the newest processor on the market. Therefore, priorities are very different in the medical world. Pixel shading and texture mapping are generally on the bottom of our list of importance. True stereoscopic visualization and platform portability are near the top. For our purposes, Java3D outperforms all other competitors, because we *need* the portability, the garbage cleanup of java, and all of the other advantages of Java.
including one that does the low-level desktop integration like Icons, system trays etc. Can't remember the name of that offhand, but it's something like JDNC.
It's JDIC