If the message about removing DataBufferInt was sarcasm, it was a really poor attempt at it.
@Riven, @JonJava you are all seriously missing the point here.
It is a protected functionality - you shouldn’t be accessing it. I can’t believe you could possibly argue for this. If I implemented another DataBuffer that was In a more remote location not to be readily written to, your design would break assuming it is an IO structure when it infact may not. I am not suggesting they would remove DataBufferInt, I am saying that you are accessing an internal data structure you shouldn’t be accessing and the object you are violating is not written to expect this behaviour.
It’s public API. It’s perfectly valid to take advantage of it if it’s there, and provide a fallback if it’s not.
No it isn’t - for god’s sake how can you possibly argue this? You’ll have to elaborate more because I cannot possibly see valid use of this. It is exactly like my IOStream analogy.
Not only are you extrapolating a promise to where it is no longer valid, but you are also accessing protected data buffers. This is very basic programming practice, I can’t believe I have to argue it.
I am not going to continue to argue fact - if you can find a JRE developer that encourages this - well than I still won’t be convinced until it is written into the javadoc.
It was. I thought it obvious considering my preceding post. Then again, sarcasm through text isn’t always easy to spot regardless of context.
Maybe I should just stick with meme’s and video clips.
[quote=“Jeremy,post:14,topic:43431”]
BufferedImage.getRaster() returns a WritableRaster.
Take it easy. Your IOStream analogy has nothing to do with the case at hand. If you receive a DataBuffer from a public method, you are free to use [icode]instanceof[/icode] and take advantage of your knowlegde about a specific subclass. Just like if you are stressed for memory, you can check whether a List<?> is an ArrayList, and if so, call trimToSize() on it. This is not against OOP ideology, this is taking advantange of the strengths of OOP. You can see how the JRE libs themselves often check whether Collections/Lists implement the RandomAccess interface, and write two different implementations to speedup certain operations.
These are not protected buffers in any way, they are WritableRasters. Sure, they may disable hardware acceleration for the BufferedImage, but if you want to have per-pixel control over your image, that’s a guarantee.
Above concepts are in use, and observable in rt.jar / src.zip.
Jeremy –
Not sure where you’ve been for the last several years, but modifying the backing int[] has long been the norm for per-pixel modifications.
You must be misunderstanding the code. There is no protected access. Everything is public API and well documented.
Look at the code:
BufferedImage.getRaster() --> returns a WritableRaster object, which we know we can write to
WritableRaster.getDataBuffer() --> returns a DataBuffer – the reason this class exists is to wrap different primitive types.
By casting it to the required type (in our case, int for TYPE_INT_ARGB), we can call getData() to access the backing array. Each DataBuffer subclass implements getData(). And it’s well documented; telling us that using getData() may disable hardware acceleration on a buffered image (which is likely what you want).
[quote=“Riven,post:26,topic:43431”]
They are protected buffers - because you don’t have access to them. Returning a super class is with limited implementation IS a form of protection. Yes, they are WritableRaster but like I said, that doesn’t imply they are readily accessible. Hence why WritableRaster exposes explicitly accessors to access this data - so the implementor can prepare this data instead of tearing it out without warning.
Does it surprise you that undocumented functionality is in use? Any large software platform does this - its all over the windows and linux kernel - applications have broken because they have become deprecated. The reason it isn’t documented is because it is subject to change - if your implementation knows something to be true, it is totally valid to hack into it - BUT if you are not maintaining your JRE - and you are not guaranteeing yourself the same platform every run, it is completely different. That is a non-sense argument and it means nothing.
That is a good point - and this is done throughout the JDK and most software library - but special note is taken of its handling in the javadoc - i.e, a promise is made. Here, no promise is made.
It seems you assume that I didn’t provide a fallback.
DataBuffer is public API, its specification is known and will not be broken by changes in the implementation.
DataBufferInt is public API, its specification is known and will not be broken by changes in the implementation.
If public API returns a DataBuffer, and it turns out to be a DataBufferInt, we have a guarantee that it will behave like it says in the specification. If the JRE library developers want to change things behind the scenes that affects behaviour to the point that it no longer behaves like specified by DataBufferInt, they must use/create a different subtype of DataBuffer. The fallback will keep the application functional in this case, therefore the application won’t be broken, like you suggested.
Besides… this is just a bunch of mental masturbation. The JRE might “officially” have you modify data with BufferedImage.setRGB or MemoryImageSource. But for practical and performance purposes (in my limited testing), you might rather use int[] of a BufferedImage.
I don’t understand your argument regarding the fallback. If you could explain that more I would appreciate it.
If the JRE developers want to change things behind the scenes, why should they be forced to keep a promise they never made so a bunch of improperly implemented code can still work?
If I promise to return A, and everyone assumes I return B because I do infact return B, it is then my fault when I return C at a later point in time, which is not B but is A?
I check whether you return an instance of B, if so, use it as B, and if not, I use the returned instance as an A (which may or may not be a C,D,etc). So, the moment you start returning C, my app still works, because I use C as A (which is a promise).
That, is a proper fallback.
That makes sense. And I would argue that implementation makes complete sense. Still though, I do feel like you are accessing protected data - none the less I wouldn’t mind this.
Golly, I almost feel as if I started this whole thing. :-X
I don’t think this was started as a means to heatedly discuss hardware acceleration or what the most OOP way to access pixels.
I was actually trying to find a way to do fast perlpixel software effects. Not really OOP’s way. I come from a C++ background where you could just declare an int pointer, point it to the image’s data buffer and write directly so this is kind of new to me. 
Though, I’m kinda lost halfway through the discussions because of my light java experience.
That’s pretty much exactly what you get with the method I posted. Fast too.
Thanks! will try it later today.
Great stuff! Your link to the other topic is broken though. 
Glad you didn’t get dissuaded by the arguments in this thread - if it’s good enough for JavaFX … ;D