Opened 11 years ago

Closed 11 years ago

#193 closed defect (fixed)

Filename by accident wrong?

Reported by: Joop Owned by:
Priority: critical Milestone: GA5
Component: general Version: 1.6.0-b22 GA
Severity: high Keywords:
Cc:

Description

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.

Change History (19)

comment:1 Changed 11 years ago by 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?

comment:2 Changed 11 years ago by Silvan Scherrer

Priority: blockerFeedback Pending

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.

comment:3 Changed 11 years ago by 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.

comment:4 Changed 11 years ago by 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.

http://www.zen147963.zen.co.uk/Unshake/Unshake15r1b.zip

Last edited 11 years ago by Joop (previous) (diff)

comment:5 Changed 11 years ago by Silvan Scherrer

Milestone: EnhancedGA4

comment:6 Changed 11 years ago by Silvan Scherrer

Priority: Feedback Pendingcritical

comment:7 Changed 11 years ago by 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.

Last edited 11 years ago by dmik (previous) (diff)

comment:8 Changed 11 years ago by 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.

comment:9 Changed 11 years ago by dmik

Milestone: NextGA5

comment:10 Changed 11 years ago by dmik

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

comment:11 Changed 11 years ago by dmik

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

comment:12 Changed 11 years ago by 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)
Last edited 11 years ago by dmik (previous) (diff)

comment:13 Changed 11 years ago by 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...

comment:14 Changed 11 years ago by 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).

comment:15 Changed 11 years ago by 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.

comment:16 Changed 11 years ago by David McKenna

Possibly also the cause of ticket #92?

comment:17 in reply to:  14 Changed 11 years ago by 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 ?!?

comment:18 Changed 11 years ago by 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.

comment:19 Changed 11 years ago by dmik

Resolution: fixed
Status: newclosed

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.

Note: See TracTickets for help on using tickets.