This is the first API change I'd like to make, removing any and all methods that accept/return a J3DBuffer
and return/accept an nio buffer instead. The only reason this class exists was to allow Java3d to shim an alternate implementation where nio was not available (Java 1.3 VMs). Time has passed....I'm hoping either nobody is using this API, or they wouldn't mind updating their projects. This would be an incompatible API change with Java3D 1.5. Thoughts? Please just do a quick search through your projects to at least let me know 'Hey, I'm using that!' Thanks, Harvey |
Administrator
|
This post was updated on .
Why do you need to remove it? Isn't it possible to keep it as is and let it use only NIO buffers in order to avoid modifying the public API?
Julien Gouesse | Personal blog | Website
|
It's not a necessity to remove it, but it sure would be nice:
1) The J3DBuffer hides the actual implementation (it holds a bytebuffer, floatbuffer, etc internally) and some API entrypoints only accept a particular type of buffer inside the J3DBuffer, directly passing the right nio buffer type here would be a lot easier to use. 2) J3DBuffer and the wrapper code all lives in j3dutils, but is required by j3dcore to build properly, this is one of the last pieces required to make j3dcore build standalone, and have only a one-way dependency (utils depending on core) Its use is rather limited in public API, and came late in Java3D's lifetime, so hopefully it didn't spread too far. Related to 2) I've been trying to get vecmath/java3d packaged in fedora, but the j3dutils license is a bit of a sticking point, so if I can remove the dependency I can at least get java3dcore packaged. So having the utils dependency gone would be helpful. Harvey |
Administrator
|
Ok you have 2 excellent reasons to remove J3DBuffer. What is the problem with j3dutils license? Can you be more precise?
Is it difficult to get a Java API packaged for a Linux distro? Do you use Red Line RPM?
Julien Gouesse | Personal blog | Website
|
J3DUtils is licensed as the standard 2-clause BSD....except for this little gem on the end:
"You acknowledge that this software is not designed, licensed or intended for use in the design, construction, operation or maintenance of any nuclear facility." Which means Fedora won't package it as this is an additional restriction on use and that is against their policy for what they will carry in the main fedora package repo. |
Java 3D 1.5.2 compatible loader and importer will be affected if they support J3DBuffer (e.g. InteractiveMesh's X3D importer and possibly others in work).
J3D's J3DBuffer class is now independent of the utilities package and is implemented as follows. A few classes have to be adapted according to the changed API. public class J3DBuffer { /** * Type of the wrapped NIO buffer object. */ public static enum BufferType { /** * Specifies a J3DBuffer object with a null NIO buffer object. */ NULL, /** * Specifies a J3DBuffer object with a wrapped NIO ByteBuffer object. */ BYTE, // CHAR, /** * Specifies a J3DBuffer object with a wrapped NIO DoubleBuffer object. */ DOUBLE, /** * Specifies a J3DBuffer object with a wrapped NIO FloatBuffer object. */ FLOAT, // INT, // LONG, // SHORT; } private Buffer originalBuffer = null; private Buffer readOnlyBuffer = null; private BufferType bufferType = BufferType.NULL; /** * Constructs a J3DBuffer object and initializes it with * a null NIO buffer object. The NIO buffer object * must be set to a non-null value before using this J3DBuffer * object in a J3D node component. */ public J3DBuffer() { this(null); } /** * Constructs a J3DBuffer object and initializes it with * the specified NIO buffer object. * * @param buffer the NIO buffer wrapped by this J3DBuffer * * @exception IllegalArgumentException if the specified buffer is * neither of type ByteBuffer, DoubleBuffer, nor FloatBuffer, or * not a direct buffer, or if the byte order of the specified * buffer does not match the native byte order of the underlying * platform. */ public J3DBuffer(Buffer buffer) { setBuffer(buffer); } /** * Sets the NIO buffer object in this J3DBuffer to * the specified object. * * @param buffer the NIO buffer wrapped by this J3DBuffer * * @exception IllegalArgumentException if the specified buffer is * neither of type ByteBuffer, DoubleBuffer, nor FloatBuffer, or * not a direct buffer, or if the byte order of the specified * buffer does not match the native byte order of the underlying * platform. */ public void setBuffer(Buffer buffer) { BufferType bType = BufferType.NULL; boolean direct = false; ByteOrder order = ByteOrder.BIG_ENDIAN; if (buffer instanceof ByteBuffer) { bType = BufferType.BYTE; direct = ((ByteBuffer)buffer).isDirect(); order = ((ByteBuffer)buffer).order(); } else if (buffer instanceof FloatBuffer) { bType = BufferType.FLOAT; direct = ((FloatBuffer)buffer).isDirect(); order = ((FloatBuffer)buffer).order(); } else if (buffer instanceof DoubleBuffer) { bType = BufferType.DOUBLE; direct = ((DoubleBuffer)buffer).isDirect(); order = ((DoubleBuffer)buffer).order(); } // Verify that the buffer is direct and has the correct byte order if (buffer != null) { if (bType == BufferType.NULL) { throw new IllegalArgumentException(J3dI18N.getString("J3DBuffer3")); } if (!direct) { throw new IllegalArgumentException(J3dI18N.getString("J3DBuffer1")); } if (order != ByteOrder.nativeOrder()) { throw new IllegalArgumentException(J3dI18N.getString("J3DBuffer2")); } } bufferType = bType; originalBuffer = buffer; // Make a read-only view of the buffer if the type is one // of the internally supported types: byte, float, or double switch (bufferType) { case BYTE: readOnlyBuffer = ((ByteBuffer)buffer).asReadOnlyBuffer(); readOnlyBuffer.rewind(); break; case FLOAT: readOnlyBuffer = ((FloatBuffer)buffer).asReadOnlyBuffer(); readOnlyBuffer.rewind(); break; case DOUBLE: readOnlyBuffer = ((DoubleBuffer)buffer).asReadOnlyBuffer(); readOnlyBuffer.rewind(); break; default: readOnlyBuffer = null; } } /** * Retrieves the wrapped NIO buffer object from this J3DBuffer. * @return the current NIO buffer wrapped by this J3DBuffer */ public Buffer getBuffer() { return originalBuffer; } Buffer getReadOnlyBuffer() { return readOnlyBuffer; } /** * Retrieves the read-only view of the wrapped NIO byte buffer. * @return the read-only view of the wrapped byte buffer * @throws ClassCastException if the wrapped buffer is not of type <code>BufferType.BYTE</code> */ public ByteBuffer getByteBuffer() { return (ByteBuffer)readOnlyBuffer; } /** * Retrieves the read-only view of the wrapped NIO double buffer. * @return the read-only view of the wrapped double buffer * @throws ClassCastException if the wrapped buffer is not of type <code>BufferType.DOUBLE</code> */ public DoubleBuffer getDoubleBuffer() { return (DoubleBuffer)readOnlyBuffer; } /** * Retrieves the read-only view of the wrapped NIO float buffer. * @return the read-only view of the wrapped float buffer * @throws ClassCastException if the wrapped buffer is not of type <code>BufferType.FLOAT</code> */ public FloatBuffer getFloatBuffer() { return (FloatBuffer)readOnlyBuffer; } /** * Retrieves the type of the wrapped NIO buffer. * @return the type of the wrapped buffer */ public BufferType getBufferType() { return bufferType; } } Signed-off-by: August Lammersdorf <aldorf@interactivemesh.com> |
Yeah, I suppose that would work, cuts the dependencies on the BufferWrapper classes in util and just does it
all directly in J3DBuffer, not sure when I'll get around to it, but I will preserve the J3DBuffer interface at this time to stay compatible. Harvey |
What is the problem with j3dutils license? Can you be more precise? Is it difficult to get a Java API packaged for a Linux distro?
|
Administrator
|
What do you expect exactly? Providing an OS-specific packaging for Java-based APIs isn't something common even though some package maintainers do so, this is absolutely unnecessary. Why not using JARs? It's a more flexible solution, you can use any version of a library, it requires no effort to wrap JARs into something else, you don't modify your environments to use a library, you can have a very precise management of versions, classpaths, etc... Just use JARs and set your classpath correctly.
Julien Gouesse | Personal blog | Website
|
Free forum by Nabble | Edit this page |