Filename by accident wrong?

[Joop]

In the Java distributions of Innotek and the unofficial 1.5 versions I can find in the bin directory the file jpeg.dll. However in all 1.6 releases this file is called jjpeg.dll, is this by accident or on purpose? Or are we talking about total different things? Because some packages can't save jpeg files with version 1.6(Ga,GA2,GA3) and can with the Innotek 1.42something. So I suspect that those packages are looking for the jpeg.dll and can't find that name in the bin directory with the result that nothing happens, in one case I got filenames but with 0 bytes. If its just renaming the file this could be solved very quick without lots of developer time.

[Joop]

I renamed in 1.6GA the file jjpeg.dll to jpeg.dll, but at opening a jpeg file the program hangs. Seems that in the code the name have to be changed too, so its more than just a renaming job. As a work around, could I copy the jjpeg.dll to jpeg.dll and run it or is that a no go in Java 1.6(whatever)? With opening the program uses jjpeg.dll and as soon as the program wants too save the file it uses jpeg.dll or is this just too simple thought?

[Silvan Scherrer]

your thought is a bit too simple. the jjpeg.dll needs this name. we decided to change jpeg.dll to that, as there are jpeg.dll from rpm and such available. and those are not compatible with this jjpeg.dll. so there must be another reason the app dosn't write the jpeg. please try to grab a log of the not working apps.

[dmik]

This file was renamed to avoid accidental clashes with other files named JPEG.DLL -- the file name is too common; given that OS/2 shares the DLL name space among all processes (unless LIBPATHSTRICT=T is used) this is a potential problem. So this is not going to be changed back. See also #52.

Anyway, applications are not supposed to use Java DLLs directly. If some application does that, it's a bug of the particular application and needs to be fixed there. If not and it still doesn't work, it may be a bug in our port (e.g. I forgot to rename some string in the source code). Please give me a non-working application and I will look at it.

[Joop]

This program does do the job fine in 1.42. In 1.60GA or better the saved files are 0 bytes and it takes much more time to proces a picture than same in 1.4.2.

[dmik]

I can confirm this problem. But I doubt it's related to the JPEG.DLL name. It can successfully load JPG files which means the DLL can be found and works.

What actually happens is a crash (reading at the zero address) when saving to a JPG file which Java intercepts and presents as a RuntimeException. The release version traps somewhere near os:malloc() (if the trace is correct). The debug version asserts at line 70 in resourceArea.hpp which is:

    fatal("memory leak: allocating without ResourceMark");

Needs more investigation.

[dmik]

This happens when the program allocates bytes for a C string (representing a name of some method to be called). Not clear what is what so far.

[dmik]

Did some more testing. Nothing useful. I have to understand the internal logic in more detail it seems.

[dmik]

The problem with the assertion in the debug build is solved in r414. Turned out to be an upstream bug.

[dmik]

The debug version gives me an interesting message now:

Exception in thread "AWT-EventQueue-0" java.lang.IncompatibleClassChangeError: Found class com.sun.image.codec.jpeg.JPEGImageEncoder, but interface was expected
	at Unshakes.saveImage(Unknown Source)

[dmik]

Okay, the reason is simple. The IcedTea-provided implementation of the proprietary com.sun.image.codec.jpeg class (see #60) is not complete. In particular, it declares JPEGImageEncoder as a class, while it is in fact an interface (according to ​http://docs.oracle.com/javase/1.4.2/docs/guide/2d/api-jpeg/com/sun/image/codec/jpeg/JPEGImageEncoder.html).

I found another implementation of this package here: ​http://javasourcecode.org/html/open-source/jdk/jdk-6u23/com/sun/image/codec/jpeg/ and will now try it. What is unclear for me is what is the origin of this source. It says Java 6 Update 23 in the URL which looks like it's an internal Oracle source they use to build their binary-only builds of JDK for Windows...

[dmik]

Unfortunately, this code (besides the obvious copyright issues) has some native methods (like sun.awt.image.codec.JPEGImageEncoderImpl.writeJPEGStream()) defined in C files which the javasourcecode.org resource doesn't seem to have.

I'm now thinking on just dropping support for this non-standard extension at all... After all, the Oracle official says it should be (and can be easily) replaced with javax.imageio and that it may disappear completely from JDK8 (​http://comments.gmane.org/gmane.comp.java.openjdk.2d.devel/2097).

We have two apps using this class Jeti/2 and this Unshaper. The first one may be fixed by the author I'm pretty sure. Most likely, the second one probably too (if one contacts the author).

[dmik]

Another option is to implement JPEGImageEncoder like it's done for JPEGImageDecoder in the IcedTea implementation -- using the same javax.imageio package. Should be not difficult.

[David McKenna]

Possibly also the cause of ticket #92?

[Yoda_Java6]

Replying to dmik:

We have two apps using this class Jeti/2 and this Unshaper. The first one may be fixed by the author I'm pretty sure.

The author of Jeti haven't touched the code for 5 years, and have no further plans.
I have no idea, if the Jeti/2 maintainer can fix this ?!?

[dmik]

There is a problem. The Unshaper application supplies images which have 10 bits per each of RGB bands instead of 8 bits and the JPEG writer from javax.imageio can only deal with bands 8 or less bits wide. I'm looking at a way to reduce the sample model but this may affect the quality. Anyway, this will be better than having nothing.

[dmik]

Problem solved. New code is committed in r415.

Note that this implementation is still not complete. It will only work in simple cases like the one used in Unshaker. However, given that this is a deprecated API only needed for very old and outdated apps like Unshaker and Jeti/2, I think it's quite acceptable.

There is one more change: the code will now throw an UnsupportedOperationException for all functions that are still not implemented -- so that we will quickly know which is needed in case if we decide to support one more outdated application later.