Opened 12 years ago

Closed 12 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 by Joop, 12 years ago

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 by Silvan Scherrer, 12 years ago

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 by dmik, 12 years ago

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 by Joop, 12 years ago

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 12 years ago by Joop (previous) (diff)

comment:5 by Silvan Scherrer, 12 years ago

Milestone: EnhancedGA4

comment:6 by Silvan Scherrer, 12 years ago

Priority: Feedback Pendingcritical

comment:7 by dmik, 12 years ago

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 12 years ago by dmik (previous) (diff)

comment:8 by dmik, 12 years ago

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 by dmik, 12 years ago

Milestone: NextGA5

comment:10 by dmik, 12 years ago

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

comment:11 by dmik, 12 years ago

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

comment:12 by dmik, 12 years ago

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 12 years ago by dmik (previous) (diff)

comment:13 by dmik, 12 years ago

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 by dmik, 12 years ago

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 by dmik, 12 years ago

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 by David McKenna, 12 years ago

Possibly also the cause of ticket #92?

in reply to:  14 comment:17 by Yoda_Java6, 12 years ago

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 by dmik, 12 years ago

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 by dmik, 12 years ago

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.