JDK-4908153 : Font2DTest throws classcast exception on "save as JPEG"
  • Type: Bug
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: 1.4.1,5.0,6
  • Priority: P4
  • Status: Closed
  • Resolution: Cannot Reproduce
  • OS: linux,solaris_10
  • CPU: x86,sparc
  • Submitted: 2003-08-18
  • Updated: 2007-05-29
  • Resolved: 2007-05-03
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 7
7Resolved
Related Reports
Duplicate :  
JDK-6221207 - Font2DTest:ClassCastException occured while saving the Font as JPEG file.
Duplicate :  
JDK-4987560 - demo/jfc/Font2DTest - throws ClassCastException
Description
Name: dk106046			Date: 08/18/2003

OPERATING SYSTEM(S):
--------------------
Turbo Linux 8


FULL JDK VERSION(S):
-------------------
This test fails with Sunjdk1.4.1 (build 1.4.1_01-b01),



------------

java -jar Font2DTest.jar

modify something (such as the font size), then
use "save as JPEG" from the menu.

There is a classcast exception:

java.lang.ClassCastException: sun.awt.image.DataBufferNative
        at sun.awt.image.codec.JPEGImageEncoderImpl.encode(JPEGImageEncoderImpl.java:436)
        at sun.awt.image.codec.JPEGImageEncoderImpl.encode(JPEGImageEncoderImpl.java:259)
        at FontPanel$FontCanvas.writeJPEG(FontPanel.java:1060)

This appears to be because the field db is a DataBufferNative, which inherits from DataBuffer,
as do DataBufferInt and DataBufferByte, so a class cast between them would fail.

Whilst I dont fully understand the problem (I.E why a DataBufferNative is being supplied in this
case), I have altered the code such that it goes down the alternative path if it is given a
DataBufferNative, and that "seems to work" - Here are the modifications:


>>>>  import sun.awt.image.DataBufferNative;

              pack  = false;
>>>>              if (cmok && useGiven(ras) && !(db instanceof DataBufferNative) ) {        /*ibm@63210*/
                     ComponentSampleModel csm =(ComponentSampleModel)sm;

                     start = (int)(db.getOffset()+
                            csm.getOffset(
                                ras.getMinX() - ras.getSampleModelTranslateX(),
                                ras.getMinY() - ras.getSampleModelTranslateY()
                                ));
                     line  = (int)csm.getScanlineStride();
                     data  = ((DataBufferByte)db).getData();

>>>>              } else if (cmok && canPack(ras) && !(db instanceof DataBufferNative) ) { /*ibm@63210*/
                     SinglePixelPackedSampleModel sppsm;
                     sppsm = (SinglePixelPackedSampleModel)sm;

                     start = (int)(db.getOffset()+
                            sppsm.getOffset(
                                ras.getMinX() - ras.getSampleModelTranslateX(),
                                ras.getMinY() - ras.getSampleModelTranslateY()
                                ));
                     line  = (int)sppsm.getScanlineStride();
                     data  = ((DataBufferInt)db).getData();
                     pack  = true;
              } else {


[This bug is being submitted as a courtesy, in order to maintain uniformity between Sun & IBM JDKs.  It has been fixed in IBM JDKs.  
Please contact ###@###.### if you have questions.]
======================================================================
This is reproducible on WinXP with JPEGFlip program (which is part of Java2Demo) when executed with OpenGL flag. This is not reproducible with JPEGFlip on DDRAW, NODDRAW. I have attached the code to this bug report.

###@###.### 2004-07-27
Comments
EVALUATION This is no longer reproducible in JDK 7 for two reasons: 1. Font2DTest no longer saves to JPEG (it uses PNG instead; see 4917498, which was fixed in JDK 6-b39). 2. We no longer use X11RemoteOffScreenImage as of JDK 7, so this bug can no longer be triggered (see 6205557, which was fixed in JDK 7-b08). Closing as "no longer reproducible" (could've closed it as a dup of one of the above, but it wouldn't make much difference either way).
03-05-2007
WORK AROUND Name: dk106046 Date: 08/18/2003 Changing colour depth of turbolinux to 16bit makes it go away. ======================================================================
06-08-2004
EVALUATION The image processing code belongs to 2D. ###@###.### 2003-08-18 There are a couple issues here. First, the JPEGImageEncoderImpl is incorrectly assuming that a certain DataBuffer subclass will be associated with the various SampleModels. In the case of Font2DTest, the image being encoded is most likely an X11RemoteOffScreenImage, which uses a DataBufferNative object to represent the pixel region contained in an X11 pixmap. The JPEGImageEncoderImpl doesn't know what a DataBufferNative is, and therefore a ClassCastException is thrown. The suggested fix from the description field is one approach; a slightly better approach would check for: if (!(ras.getDataBuffer() instanceof DataBufferByte/Int) return false; in the useGiven() and canPack() methods, which would be a more accurate check. The other issue here is that Font2DTest was written in the days of yore, before Image I/O was available. Back then, the only solution for image writing was the unsupported com.sun JPEG encoder, which was a poor solution because of the lossy compression of the screen dumps. A better solution would be to remove Font2DTest's dependency on the com.sun JPEG encoder and instead use IIO to write the image in a lossless format, such as PNG. I will file a new bug to address this demo issue. ###@###.### 2003-09-04 The demo issue regarding use of the old JPEG encoder was filed as RFE 4917498 under the demo_2d subcategory. ###@###.### 2004-02-03
04-09-2003