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.
Nothing to do with it at all. At the 3D layer, LG isn't that complex a user of 3D graphics. You could port the LG code over to an alternate scene graph API in the matter of a day or two, maybe 3-4 days if writing directly to a Java OpenGL binding. Mostly it has to do with the internal things happening inside Sun. Most of that is due to the loss of staff due to enforced downsizing. There used to be 3 different groups doing 3D inside Sun, now there is one. From hundreds of developers down to, at best (it's hard to get a good indication right now), 10. Those developers are spread all over the map.
Sun killed the J3D development team almost this time last year when they sacked the last fulltime developers working on it and have been struggling to decide what to do with it since. The basic reaction was for the commerical users to bail in a big hurry and all the non-commercial users like universities and hobbiest scream for Sun to release the source code. It was only in late March that Sun decided what they were finally going to do with it and only until this week that they had the final information and go-ahead from the lawyers about which licenses would be used.
LookingGlass is coded in Java and uses Java3D for the 3D part of the rendering. It uses JMF and JAI for the other media handling as well as pushing out a number of other experimental Java APIs from Sun, 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.
Speed is exceedingly good. In the area that we develop an open source toolkit (Xj3D) and commerical applications in (X3D/VRML) our Java3D renderer is the same speed as the natively coded OpenGL and D3D applications. We have another renderer that is built directly on top of the JOGL OpenGL bindings that is at least twice as fast in every instance as that of the J3D renderer.
So, put simply, in our application space, the Java-based application is at least twice as fast as every native code competitor. We also have a high-level scene graph optimised for visualisation that has these speed advantages as a replacement for Java3D called Aviatrix3D. You may also want to check out Xith3D, another highlevel scenegraph API written in Java that is optimised for gaming purposes and gets even better performance than AV3D.
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.
Adding to that (Sun has said they're going to release the J3D source, but no word on the license yet).
The Java+OpenGL apps are very impressive. As an additional view, we have our our Java/OpenGL scene graph called Aviatrix3D which is aimes that the sci-viz end of the scale. Already, without serious optimisations, we're running twice the frame rates of Java3D. As a better benchmark, when it's under the base of a VRML/X3D browser, we're getting a least twice (typically 3 to 4 times) the frame rate, if not more than any other VRML or X3D browser written in C or C++ (eg Cortona, Blaxxun, Flux, etc). It's all about how you code, not what you're coding in.
There is no way that a language that is running through simulated hardware is going to be faster than a program that is running on the hardware it was compiled for.
Really? Perhaps you need to do some reading about HP's Dynamo project. It was even posted here as an article a year or two ago. A VM that makes native code faster than running the native code by itself. Dynamic runtime profiling and optimisation is always going to result in faster code than statically optimised.
The Cinerama here in Seattle doesn't put on ads before the movies. The last 3 movies I've seen there (Shrek 2, LoTR III, Kill Bill Vol 2) haven't had any ads at all. There's about 5 trailers or so and then straight into the movie. I actually wanted to see one - for the local Seattle Film Festival. Stars one of my workmates and I've seen it on small screen, but not on the big screen.:(
Maybe it's some deal with the distributors or they make so much money out of the popcorn and coke that they don't need to. *shrug*
This just begs for a response. 'Everywhere that I know' happens to also include that part of the world thats not inside the USA (yet) ?
Yes. I'm an aussie that has travelled extensively, and lived in both the US and UK. Courtesy of various international motorcycle lists that I frequent I know (as much as one can on some of these lists) quite a few policemen. I could easily count at least a dozen in different countries as being friends - guys I've ridden with or crashed at their place when travelling etc.
Note your third paragraph supports exactly what I said - the Dutch police are taught StK.
icluding the part where I happen to live (the Netherlands), police is taught to shoot to kill
By your own words they are taught this. That's all I'm talking about - when the weapon is drawn and they are aiming it at someone, they are taught to kill with it, not to disarm, not to injure. I'm not talking about any point prior to drawing the weapon and the finger being squeezed on the trigger, just the point after that. The point that a weapon is drawn is different by country, but after that point, the training is all the same - for a very good reason.
Maybe other states, but given the number of people killed, certainly not Victorian cops!
BTW, all cops, everywhere that I know (including one of my martials arts instructors, who is also one of the police defence tactics training instructors here in Washington) are taught StK. There are a lot of very good reasons for this. Primary reason is that the easiest thing to hit is the body, not the extremities. Called shooting at the center of seen mass. Go for the biggest target as if you're off by a little bit in your aim then you've still got a high probability of a hit. A shoot to wound strategy requires you aiming at a far smaller target - shoulder, leg, arm - all of which are close to impossible to hit in a real life situation.
Other reasons why StK is mandatory is that a wacko coming at you pumped full of various substances, as well as adrenaline, is not going to feel a wound - or at least not enough to stop them from continuing in their path the attempt to hurt you. That person coming at you at full speed can easily clear a 10 metre gap between you before you get a chance to put a second round into them. Generally a police officer will not double tap, which means by the time recoil, damping and aiming again, the attacker is already on top of you and you're history.
Oh, so you mean like the average aussie road then. Nothing unusual about that.... In fact, 1.5 lanes is rather generous. Most roads here outside of the main cities tend to be around 1 lane wide with half lane of dirt either side of it. Somewhat like this:
That's the difference between static optimisation and dynamic. In the dynamic case, such as Java and.NET runtime, the VM knows exactly what your code is doing, and probably much better than you do. In that case, it optimises your code explicitly for the data it is working with Right Now(TM) rather than what the programmer thought was a fairly common case. Pretty much every study done on dynamic optimisation has shown that programmer pre-optimisations actually perform worse on these sorts of VMs than non-optimised code. The programmer-optimised version typically does stuff The Wrong Way that is slow for the given current conditions.
Re:Is the right to implement the spec perpetual?
on
Gosling on Opening Java
·
· Score: 2, Informative
The way the specs are right now is that anyone can implement them. Sun owns a Trademark on "Java" and many derivative names. In order to call your work "an implementation of Java" you need to get Sun to give you a license to use the Java(TM). To do that, you need to pass the compatibility tests. To pass the compatability tests you must purchase a TCK (test kit), run the tests and give the results to Sun. They check it over, it if passes muster you get to call your work Java.
For a perfect example of seeing this happening in real life, have a look at the Wabi project. This was a Java-clone in all but name for small footprint devices, long before J2ME started. Basically it was Java - you could compile the code with a normal Java compiler and run it on the Wabi VM and it would work (except for the odd bug here and there). They never called it Java as they didn't want to pay for the TCK.
The only evidence I have I can't exactly present. My business partner and I worked very closely with them on the specification at the time with the CAD working group. That involved weekly trips either for us down to Intel's Portland, OR labs or their engineers coming to our Seattle office. I've taken another look at the stuff they've put up here and it's no different (in fact I would say identical, but memory of the old stuff is somewhat fuzzy these days). Also, I would recommend you go to Intel's site and search through their press releases from about 1999 onwards. You'll see they re-announce this same technology about once every 18 months.
As for the comment of "shockwave 3D simply isn't up to it", you're absolutely correct. The format is attrocious for anything other than some fairly simple sexy looking graphics. Doing large scale interactive environments, it is not made for. Nor is it made for high-end work like CAD.
They're not copying from X3D. It's a completely different model altogether. Very different from pretty much every scene graph architecture devised. It separates out the scene graph structure into two separate structures of material usage (textures, appearance etc) and mesh relationships. Animation and modification is done through a separate process called Modifier Chains. This is infact just Shockwave3D with a few minor additions.
In fact, when they tried to push this through the Web3D consortium, they were told to go away. They started the CAD working group there and then started doing some very underhanded things to certain members of the group when the majority of the members asked them to prove how this format was better than X3D at accomplishing the task (in short, it's useless for large scale geometry representation).
Nope. VRML Never had a binary format. Still doesn't. X3D is gaining one, but the work is a separate standards track process involved in it. We're currently evaluating all the proposals right now.
You're partially correct. X3D added a XML format, it didn't replace the existing one with it. As such it has grown a lot so now you can express the same concepts in 3 different file formats - the origial Inventor-style curly brackets, XML and a pure binary form.
As for the other technologies, they're included in the X3D standard. The only ones taht aren't are progammable shaders and 3D texturing support. Both of those are currently going through the standardisationn process working groups within the Web3d consortium.
Only a part of X3D is incorporated into MPEG IV. There's a lot they didn't take - most specifically all the extensibility that X3D allows. It's a single fixed profile of functionality. It's a rather cut-down version if anything.
ECMA is typically used as a gateway standards body by a lot of companies trying to standardise proprietary technology. A lot of places will not accept contract bids for proprietary standards, so many companies use it to get a "standard" tag associated with their technology. Another classic example of this is Javascript that got pushed through here.
Once ECMA has approved it (almost always do as it is a pay-for standards body - ie you pay for it, we'll make it a standard) companies try to leverage these into other more stringent bodies. As you correctly note, most of these standards end up going through somewhere like ISO, IEEE, ANSI or other places. However, don't expect the text to be indentical. I know in the couple of cases I've been involved in that have taken ECMA standards and turned into ISO ones that a lot of changes are made. Not big ones like complete rewrites, but lots of things like completely defining semantics and behaviuoural models etc. If you get a chance, check out the differences between ECMA 262/269 and ISO/IEC DIS 16262 both of which define what we know as "Javascript".
There is one in the works - There's a CAD profile of the X3D standard that is currently being worked on by the Web3d Consortium. The primary purpose is for data interchange at the DCC tool level so that CAD content can be taken and repurposed for tasks like training manuals, applications and online display. Every major CAD vendor as well as all the other tool vendors (Autodesk, Alias etc etc) are involved. The standard is underway and the first draft to be added to the ISO process should be ready in the next month or so.
Unless they have done some serious modifications to it from when we were working with them on it 12 months ago, the architecture prohibits the use of any video hardware accelerated capabilities - let alone programmable shaders. The format implicitly requires CPU utilitisation all the way through until you hit the rasterisation stage. If you want to see why, do some research into the Modifier Chain architecture part of the spec. It's a great concept, but totally in appropriate for hardware acceleration.
VRML never had a binary format. Some people would GZIP the files, but that is not a binary format. X3D will have a binary format. We're going through the process right now, but it's not even decided what the final bit pattern looks like (there's 3 proposals being evaluated right now).
Not at all. U3D is actually just the Shockwave3D file format that Intel are trying to ram through a standards body somewhere.
They originally tried to do this through the Web3D consortium (the owner of the VRML standard) under the guise of a CAD format. After a lot of manipulation of the members and several other very dodgy things, the consortium told Intel to get lost. It's now just popped up again under another guise. The laughable thing is that this file format is completely inappropriate for CAD requirements. It's somewhere between a scene graph file format and a programming API, with neither being particularly good. For example, it's not extensible and has a lot of hardcoded strategies. If you wanted to extend or change an iimplementation of one item in the modifier chain, it would require complete reimplementation of the entire system. For example, changing the humanoid representation to using shaders for rendering the mesh was impossible. The entire format is designed around CPU-based rendering. Video hardware accelaration is not possible for about 95% of the spec.
Nothing has changed at Intel since we were dealing with them for the last 2 years on it. Effectively this project is 2 engineers and one manager trying to save their arse and the code from failed Shockwave efforts.
An example - the press release says it will be an ISO standard. The ISO people have no idea what Intel is talking about as they've not been approached yet. It would fall under either SC24 or SC29 subcommittes (SC24 3D graphics, SC29 is programming and home to MPEG) and both of these committees already have standards that fullfil these requirements (MPEG and VRML/X3D). It wouldn't make it past the front gate at ISO.
It's more than scalable. It's gone into real world usage. No longer hyped, people are just using it for real applications and data transfer.
VRML is as open as HTML, it's an ISO specification. There's the next revision of it going through ISO process right now called X3D (final ISO vote on the IS acceptance ends June 30, so see an announcment at Siggraph). X3D takes all the good stuff from VRML and expands it again to allow for multiple different encoding strategies (VRML-style, XML, binary etc) and componentises the spec to add a lot of different things.
I write heaps of open source Java software (mostly under LGPL, some BSD). In fact, my entire business is based on it (somewhere close to a million lines of it now spread across 6 different projects). We are certainly achieving our goals in doing what we want and we really don't care what Sun or anyone else do with the underlying language - neither do the companies and instituitions who pay us to develop more.
As a company that primarily develops OSS toolkits, and some proprietary applications on those toolkits, we achieve everything we want from it. In fact, most of our business comes from the open source nature of what we do and most of the proprietary stuff is that way because of it's classified nature. Our goals are to spread the open source model into the defence community, and we are very successful at doing so, even with the detriment we have to deal with of RMS's rants.
Given that we are making money, offering stuff under a license that we like, are achieving our goals and we're using an open platform, I see nothing valid in any of RMS's points in that diatribe. We're using a language and some defined libraries, we're not using a toolkit. We have hundreds of developers using our products in all sorts of different environments and platforms. Some are Sun-based, most are not. What's his point?
If the program is written by someone else, then you don't really have an option on changing it without getting into some serious hacking (ie writing a wrapper class for their application that changes the default L&F before starting the real app).
If you want to see what is available on a platform, have a look at the javax.swing.UIManager class and specifically the getInstalledLookAndFeel() method. This will give you a list that you can then drop into a menu, print out to a command line or anything else you care to do. If you're builing an app that is supposed to be cross platform, then specifically setting a L&F is bad design. What you should use is
String name = UIManager.getSystemLookAndFeelClassName() UIManager.setLookAndFeel(name)
In this way you'll always get something that approximates the local widget set look, regardless of whether you are running on Win32, Linux, Solaris or anything else.
Slashdot Mirror
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.
Nothing to do with it at all. At the 3D layer, LG isn't that complex a user of 3D graphics. You could port the LG code over to an alternate scene graph API in the matter of a day or two, maybe 3-4 days if writing directly to a Java OpenGL binding. Mostly it has to do with the internal things happening inside Sun. Most of that is due to the loss of staff due to enforced downsizing. There used to be 3 different groups doing 3D inside Sun, now there is one. From hundreds of developers down to, at best (it's hard to get a good indication right now), 10. Those developers are spread all over the map.
Sun killed the J3D development team almost this time last year when they sacked the last fulltime developers working on it and have been struggling to decide what to do with it since. The basic reaction was for the commerical users to bail in a big hurry and all the non-commercial users like universities and hobbiest scream for Sun to release the source code. It was only in late March that Sun decided what they were finally going to do with it and only until this week that they had the final information and go-ahead from the lawyers about which licenses would be used.
LookingGlass is coded in Java and uses Java3D for the 3D part of the rendering. It uses JMF and JAI for the other media handling as well as pushing out a number of other experimental Java APIs from Sun, 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.
Speed is exceedingly good. In the area that we develop an open source toolkit (Xj3D) and commerical applications in (X3D/VRML) our Java3D renderer is the same speed as the natively coded OpenGL and D3D applications. We have another renderer that is built directly on top of the JOGL OpenGL bindings that is at least twice as fast in every instance as that of the J3D renderer.
So, put simply, in our application space, the Java-based application is at least twice as fast as every native code competitor. We also have a high-level scene graph optimised for visualisation that has these speed advantages as a replacement for Java3D called Aviatrix3D. You may also want to check out Xith3D, another highlevel scenegraph API written in Java that is optimised for gaming purposes and gets even better performance than AV3D.
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.
Adding to that (Sun has said they're going to release the J3D source, but no word on the license yet).
The Java+OpenGL apps are very impressive. As an additional view, we have our our Java/OpenGL scene graph called Aviatrix3D which is aimes that the sci-viz end of the scale. Already, without serious optimisations, we're running twice the frame rates of Java3D. As a better benchmark, when it's under the base of a VRML/X3D browser, we're getting a least twice (typically 3 to 4 times) the frame rate, if not more than any other VRML or X3D browser written in C or C++ (eg Cortona, Blaxxun, Flux, etc). It's all about how you code, not what you're coding in.
There is no way that a language that is running through simulated hardware is going to be faster than a program that is running on the hardware it was compiled for.
Really? Perhaps you need to do some reading about HP's Dynamo project. It was even posted here as an article a year or two ago. A VM that makes native code faster than running the native code by itself. Dynamic runtime profiling and optimisation is always going to result in faster code than statically optimised.
The Cinerama here in Seattle doesn't put on ads before the movies. The last 3 movies I've seen there (Shrek 2, LoTR III, Kill Bill Vol 2) haven't had any ads at all. There's about 5 trailers or so and then straight into the movie. I actually wanted to see one - for the local Seattle Film Festival. Stars one of my workmates and I've seen it on small screen, but not on the big screen. :(
Maybe it's some deal with the distributors or they make so much money out of the popcorn and coke that they don't need to. *shrug*
This just begs for a response. 'Everywhere that I know' happens to also include that part of the world thats not inside the USA (yet) ?
Yes. I'm an aussie that has travelled extensively, and lived in both the US and UK. Courtesy of various international motorcycle lists that I frequent I know (as much as one can on some of these lists) quite a few policemen. I could easily count at least a dozen in different countries as being friends - guys I've ridden with or crashed at their place when travelling etc.
Note your third paragraph supports exactly what I said - the Dutch police are taught StK.
icluding the part where I happen to live (the Netherlands), police is taught to shoot to kill
By your own words they are taught this. That's all I'm talking about - when the weapon is drawn and they are aiming it at someone, they are taught to kill with it, not to disarm, not to injure. I'm not talking about any point prior to drawing the weapon and the finger being squeezed on the trigger, just the point after that. The point that a weapon is drawn is different by country, but after that point, the training is all the same - for a very good reason.
Maybe other states, but given the number of people killed, certainly not Victorian cops!
BTW, all cops, everywhere that I know (including one of my martials arts instructors, who is also one of the police defence tactics training instructors here in Washington) are taught StK. There are a lot of very good reasons for this. Primary reason is that the easiest thing to hit is the body, not the extremities. Called shooting at the center of seen mass. Go for the biggest target as if you're off by a little bit in your aim then you've still got a high probability of a hit. A shoot to wound strategy requires you aiming at a far smaller target - shoulder, leg, arm - all of which are close to impossible to hit in a real life situation.
Other reasons why StK is mandatory is that a wacko coming at you pumped full of various substances, as well as adrenaline, is not going to feel a wound - or at least not enough to stop them from continuing in their path the attempt to hurt you. That person coming at you at full speed can easily clear a 10 metre gap between you before you get a chance to put a second round into them. Generally a police officer will not double tap, which means by the time recoil, damping and aiming again, the attacker is already on top of you and you're history.
Oh, so you mean like the average aussie road then. Nothing unusual about that.... In fact, 1.5 lanes is rather generous. Most roads here outside of the main cities tend to be around 1 lane wide with half lane of dirt either side of it. Somewhat like this:
The Alpine Way 1 and The Alpine Way 2 in the Snowy Mountains area or somewhere near Mt Isa
That's the difference between static optimisation and dynamic. In the dynamic case, such as Java and .NET runtime, the VM knows exactly what your code is doing, and probably much better than you do. In that case, it optimises your code explicitly for the data it is working with Right Now(TM) rather than what the programmer thought was a fairly common case. Pretty much every study done on dynamic optimisation has shown that programmer pre-optimisations actually perform worse on these sorts of VMs than non-optimised code. The programmer-optimised version typically does stuff The Wrong Way that is slow for the given current conditions.
The way the specs are right now is that anyone can implement them. Sun owns a Trademark on "Java" and many derivative names. In order to call your work "an implementation of Java" you need to get Sun to give you a license to use the Java(TM). To do that, you need to pass the compatibility tests. To pass the compatability tests you must purchase a TCK (test kit), run the tests and give the results to Sun. They check it over, it if passes muster you get to call your work Java.
For a perfect example of seeing this happening in real life, have a look at the Wabi project. This was a Java-clone in all but name for small footprint devices, long before J2ME started. Basically it was Java - you could compile the code with a normal Java compiler and run it on the Wabi VM and it would work (except for the odd bug here and there). They never called it Java as they didn't want to pay for the TCK.
The only evidence I have I can't exactly present. My business partner and I worked very closely with them on the specification at the time with the CAD working group. That involved weekly trips either for us down to Intel's Portland, OR labs or their engineers coming to our Seattle office. I've taken another look at the stuff they've put up here and it's no different (in fact I would say identical, but memory of the old stuff is somewhat fuzzy these days). Also, I would recommend you go to Intel's site and search through their press releases from about 1999 onwards. You'll see they re-announce this same technology about once every 18 months.
As for the comment of "shockwave 3D simply isn't up to it", you're absolutely correct. The format is attrocious for anything other than some fairly simple sexy looking graphics. Doing large scale interactive environments, it is not made for. Nor is it made for high-end work like CAD.
They're not copying from X3D. It's a completely different model altogether. Very different from pretty much every scene graph architecture devised. It separates out the scene graph structure into two separate structures of material usage (textures, appearance etc) and mesh relationships. Animation and modification is done through a separate process called Modifier Chains. This is infact just Shockwave3D with a few minor additions.
In fact, when they tried to push this through the Web3D consortium, they were told to go away. They started the CAD working group there and then started doing some very underhanded things to certain members of the group when the majority of the members asked them to prove how this format was better than X3D at accomplishing the task (in short, it's useless for large scale geometry representation).
Nope. VRML Never had a binary format. Still doesn't. X3D is gaining one, but the work is a separate standards track process involved in it. We're currently evaluating all the proposals right now.
You're partially correct. X3D added a XML format, it didn't replace the existing one with it. As such it has grown a lot so now you can express the same concepts in 3 different file formats - the origial Inventor-style curly brackets, XML and a pure binary form.
As for the other technologies, they're included in the X3D standard. The only ones taht aren't are progammable shaders and 3D texturing support. Both of those are currently going through the standardisationn process working groups within the Web3d consortium.
Only a part of X3D is incorporated into MPEG IV. There's a lot they didn't take - most specifically all the extensibility that X3D allows. It's a single fixed profile of functionality. It's a rather cut-down version if anything.
ECMA is typically used as a gateway standards body by a lot of companies trying to standardise proprietary technology. A lot of places will not accept contract bids for proprietary standards, so many companies use it to get a "standard" tag associated with their technology. Another classic example of this is Javascript that got pushed through here.
Once ECMA has approved it (almost always do as it is a pay-for standards body - ie you pay for it, we'll make it a standard) companies try to leverage these into other more stringent bodies. As you correctly note, most of these standards end up going through somewhere like ISO, IEEE, ANSI or other places. However, don't expect the text to be indentical. I know in the couple of cases I've been involved in that have taken ECMA standards and turned into ISO ones that a lot of changes are made. Not big ones like complete rewrites, but lots of things like completely defining semantics and behaviuoural models etc. If you get a chance, check out the differences between ECMA 262/269 and ISO/IEC DIS 16262 both of which define what we know as "Javascript".
There is one in the works - There's a CAD profile of the X3D standard that is currently being worked on by the Web3d Consortium. The primary purpose is for data interchange at the DCC tool level so that CAD content can be taken and repurposed for tasks like training manuals, applications and online display. Every major CAD vendor as well as all the other tool vendors (Autodesk, Alias etc etc) are involved. The standard is underway and the first draft to be added to the ISO process should be ready in the next month or so.
Unless they have done some serious modifications to it from when we were working with them on it 12 months ago, the architecture prohibits the use of any video hardware accelerated capabilities - let alone programmable shaders. The format implicitly requires CPU utilitisation all the way through until you hit the rasterisation stage. If you want to see why, do some research into the Modifier Chain architecture part of the spec. It's a great concept, but totally in appropriate for hardware acceleration.
VRML never had a binary format. Some people would GZIP the files, but that is not a binary format. X3D will have a binary format. We're going through the process right now, but it's not even decided what the final bit pattern looks like (there's 3 proposals being evaluated right now).
Not at all. U3D is actually just the Shockwave3D file format that Intel are trying to ram through a standards body somewhere.
They originally tried to do this through the Web3D consortium (the owner of the VRML standard) under the guise of a CAD format. After a lot of manipulation of the members and several other very dodgy things, the consortium told Intel to get lost. It's now just popped up again under another guise. The laughable thing is that this file format is completely inappropriate for CAD requirements. It's somewhere between a scene graph file format and a programming API, with neither being particularly good. For example, it's not extensible and has a lot of hardcoded strategies. If you wanted to extend or change an iimplementation of one item in the modifier chain, it would require complete reimplementation of the entire system. For example, changing the humanoid representation to using shaders for rendering the mesh was impossible. The entire format is designed around CPU-based rendering. Video hardware accelaration is not possible for about 95% of the spec.
Nothing has changed at Intel since we were dealing with them for the last 2 years on it. Effectively this project is 2 engineers and one manager trying to save their arse and the code from failed Shockwave efforts.
An example - the press release says it will be an ISO standard. The ISO people have no idea what Intel is talking about as they've not been approached yet. It would fall under either SC24 or SC29 subcommittes (SC24 3D graphics, SC29 is programming and home to MPEG) and both of these committees already have standards that fullfil these requirements (MPEG and VRML/X3D). It wouldn't make it past the front gate at ISO.
It's more than scalable. It's gone into real world usage. No longer hyped, people are just using it for real applications and data transfer.
VRML is as open as HTML, it's an ISO specification. There's the next revision of it going through ISO process right now called X3D (final ISO vote on the IS acceptance ends June 30, so see an announcment at Siggraph). X3D takes all the good stuff from VRML and expands it again to allow for multiple different encoding strategies (VRML-style, XML, binary etc) and componentises the spec to add a lot of different things.
I write heaps of open source Java software (mostly under LGPL, some BSD). In fact, my entire business is based on it (somewhere close to a million lines of it now spread across 6 different projects). We are certainly achieving our goals in doing what we want and we really don't care what Sun or anyone else do with the underlying language - neither do the companies and instituitions who pay us to develop more.
As a company that primarily develops OSS toolkits, and some proprietary applications on those toolkits, we achieve everything we want from it. In fact, most of our business comes from the open source nature of what we do and most of the proprietary stuff is that way because of it's classified nature. Our goals are to spread the open source model into the defence community, and we are very successful at doing so, even with the detriment we have to deal with of RMS's rants.
Given that we are making money, offering stuff under a license that we like, are achieving our goals and we're using an open platform, I see nothing valid in any of RMS's points in that diatribe. We're using a language and some defined libraries, we're not using a toolkit. We have hundreds of developers using our products in all sorts of different environments and platforms. Some are Sun-based, most are not. What's his point?
If the program is written by someone else, then you don't really have an option on changing it without getting into some serious hacking (ie writing a wrapper class for their application that changes the default L&F before starting the real app).
If you want to see what is available on a platform, have a look at the javax.swing.UIManager class and specifically the getInstalledLookAndFeel() method. This will give you a list that you can then drop into a menu, print out to a command line or anything else you care to do. If you're builing an app that is supposed to be cross platform, then specifically setting a L&F is bad design. What you should use is
String name = UIManager.getSystemLookAndFeelClassName()
UIManager.setLookAndFeel(name)
In this way you'll always get something that approximates the local widget set look, regardless of whether you are running on Win32, Linux, Solaris or anything else.