David wrote:
>
> That raises a scary point. What if Sun woke up one day and decided to
> "discontinue" Java3d? Is this a real possibility?
I don't know. Some would say that anything that is non-core always has
this potential. Right at the moment Sun has obviously found a huge niche
with the server side Java rather than the original intention of client
side. Therefore all of the marketing focus is going in to shore up that
market (and obviously to keep MS out of that space - this being Sun and
all).
If Sun abandon's the API, that would make people no longer required to
submit to the compatibility test (and that is another problem entirely
in itself). This would allow the independent developers to move into
making any API changes they liked. Whether they could keep going under
the javax.blah package name and not get beaten to death by Sun's Lawyers
is another problem. Purely speculation here, but you could probably use
the Java Community Process to keep this going anyway even if Sun were
not interested in it.
Right at the moment I don't think it is likely to drop. It is supposedly
going through the JCP process for 1.4. This JCP proposal is supposed to
hit the shelves some time in the next couple of months.
> Justin did you get any sense how Sun views Java3d in their long term plans?
Well, my understanding is that Java 3D is not run by the Javasoft branch
of Sun. Instead it is actually run by the 3D graphics/Hardware people.
Therefore they have a vested interest in keeping it going. Where it is
falling over is that apparently a number of the people on the J3D team
also lead other lives over in the OpenGL and hardware driver world as
well.
The other thing that I seem to notice was that like everywhere, the guys
would like more engineers to work on the team. They seem to be
overwhelmed with bugs to fix, new features to implement etc. This is
where I think an OSS implementation would fair much better - and keep
Sun much more honest.
To some extent I think the engineering side of the house is looking
forward to the JCP process. It leaves them much more free to implement
rather than speculate what the required features should be and then get
hammered by us on the list here. I really don't like the semi-closed
nature of JCP, but it is the best we have to work with at the moment.
I'd encourage as many people to join up as possible as it is free for
individuals.
Another reason to look forward to the JCP work will be in the cleaning
up of the API. I have a very strong personal feeling that it is very
confused. The API doesn't know where to position itself or any form of
consistency. Take two examples: MediaContainer and picking.
MediaContainer should be useful for textures as much as audio. Why is it
not being used there? The picking code is mainly expressed in the
utilities packages, which are effectively non-core. However, in the
words of KR, they really are part of the core.
I challenged him about the util code. There is a lot of stuff there that
people are continously re-implementing for their own applications. The
Euler vs Quaternion vs Matrix for the viewing transforms. I suggested
that all of this code would be better to be let go free under say the
BSD license and let us the developers pick it up and build a really good
toolkit out of it because people are wasting precious development time
continously reinventing exactly the same piece of code. His response was
that there were some parts of com.sun that would be good for this, but
there were other parts like picking that really were part of the core of
Java3D and would not be released. If they are really part of the core,
what are they doing in com.sun. rather than javax....picking?
These sorts of issues really, really need to be sorted out. I feel that
the JCP process should be not for J3D 1.4 but for v2.0. Clean up all the
shitty bits that are odd and inconsistent, break a lot of apps once (not
that there are many) and lets make something useful out of it, rather
than a slightly glorified toy. This would mirror the efforts of the JMF
API.
This is where an OSS implementation of J3D would be the best thing. We
could use this to keep Sun honest. Really, the API specification is a
complete piece of shit. Professionally I would never let my developers
get away with writing something like that as internal proprietary code,
let alone a public API. There is absolutely nothing at all in there that
I could use to begin an implementation that would even remotely resemble
the same workings as Sun's code. An external, independent implementation
would force them to clean this up. If by some miracle they ran the JCK
over it for nothing (It costs huge dollars to license that) then said it
didn't pass, we can turn around and say that the problem is because
there is no specification for that particular item that didn't pass etc
etc. Sure it might take us 6 months to catch up with Sun's
implementation, but after that, it would far outstrip theirs for quality
and performance.
Anyway, enough of my ranting for a while (typing much faster now that
I've had the pins taken out of my finger today).....
--
Justin Couch Author, Java Hacker
http://www.vlc.com.au/~justin/ Java 3D FAQ Maintainer
http://www.j3d.org/ J3D.org The Java 3D Community Site
-------------------------------------------------------------------
"Humanism is dead. Animals think, feel; so do machines now.
Neither man nor woman is the measure of all things. Every organism
processes data according to its domain, its environment; you, with
all your brains, would be useless in a mouse's universe..."
- Greg Bear, Slant
-------------------------------------------------------------------
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff JAVA3D-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
