Bug 719118 - javadoc parses .class file as Java source code when -subpackages is used
Summary: javadoc parses .class file as Java source code when -subpackages is used
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: java-1.6.0-openjdk
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Deepak Bhole
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 703828 715804
TreeView+ depends on / blocked
 
Reported: 2011-07-05 20:02 UTC by Alexander Boström
Modified: 2012-08-22 17:21 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-08-22 17:21:58 UTC
Type: ---


Attachments (Terms of Use)

Description Alexander Boström 2011-07-05 20:02:09 UTC
Description of problem:
When run with -subpackages, javadoc will fail with error messages like "warning: unmappable character for encoding ASCII" followed by extracts of the .class binary.

Version-Release number of selected component (if applicable):
java-1.6.0-openjdk-1.6.0.0-55.1.10.fc15.x86_64 up to and including 58.1.10.2.fc16

Problem is not reproducible with 53.1.9.6

How reproducible:
Always

Steps to Reproduce:

cd $(mktemp -d)
mkdir -p org/example/bug
cat >org/example/bug/Bug.java <<'EOF'
package org.example.bug;
public class Bug {}
EOF
javac org/example/bug/Bug.java
javadoc -classpath . -subpackages org.example.bug

Actual results:
./org/example/bug/Bug.class:1: warning: unmappable character for encoding ASCII
????2
^
and so on...

Expected results:
javadoc is generated

Comment 1 Kostya Kardamanov 2011-09-05 11:12:16 UTC
The same problem on FC15 with java-1.6.0-openjdk-1.6.0.0-59.1.10.3.fc15.x86_64 package.

Comment 2 Deepak Bhole 2011-09-06 14:42:01 UTC
Can you please try again from the terminal? This time, set locale first:

export LC_ALL=en_US.UTF-8

Comment 3 Kostya Kardamanov 2011-09-06 15:27:03 UTC
[korum@korum ~]$ ./test_javadoc.sh 
+ export LC_ALL=en_US.UTF-8
+ LC_ALL=en_US.UTF-8
++ mktemp -d
+ TEMPDIR=/tmp/tmp.klOVVu1W3X
+ cd /tmp/tmp.klOVVu1W3X
+ mkdir -p org/example/bug
+ cat
+ javac org/example/bug/Bug.java
+ javadoc -classpath . -subpackages org.example.bug
Loading source files for package org.example.bug...
./org/example/bug/Bug.class:1: warning: unmappable character for encoding UTF8
����2
^
...

./org/example/bug/Bug.class:1: illegal character: \65533
����2
^
...

90 errors
6 warnings

Comment 4 Deepak Bhole 2011-09-06 17:51:42 UTC
Ah, okay so it is not an encoding issue. I looked deeper into this and I think I have found the cause. I will work with upstream to try and get it resolved.

In the mean time, as a workaround, you can have the .class file go to another directory (than the source files) and that should fix the error.

Comment 5 Andrew John Hughes 2011-09-13 01:53:54 UTC
I've been aware of this for some time, as it breaks java-gnome's doc build, but I haven't had a chance to do anything more than replicate it.

I believe it's caused once again by:

http://hg.openjdk.java.net/jdk6/jdk6/langtools/rev/5c2858bccb3f

Comment 6 Deepak Bhole 2011-09-16 18:03:52 UTC
(In reply to comment #5)
> I've been aware of this for some time, as it breaks java-gnome's doc build, but
> I haven't had a chance to do anything more than replicate it.
> 
> I believe it's caused once again by:
> 
> http://hg.openjdk.java.net/jdk6/jdk6/langtools/rev/5c2858bccb3f

Yeah, specifically the change to JavadocTool.java from what I traced.

I sent an email to the javadoc-dev list earlier this month about this, including a potential fix. It is still waiting for moderator approval.

I've emailed the moderator personally to try and get things moving again.

Comment 7 Deepak Bhole 2011-09-16 19:12:22 UTC
I just finished communicating with Jonathan Gibbons from Oracle. He is going to fix this in JDK8. Once there, either him or myself will look into backports to 7 and 6.

Comment 8 Andrew John Hughes 2012-08-22 12:54:16 UTC
I think this is fixed by 7091528 which was applied in 1.10.5.

Comment 10 Alexander Boström 2012-08-22 17:21:58 UTC
Tried with the latest 1.6.0 and 1.7.0. Looks like it's fixed in both. Closing.


Note You need to log in before you can comment on or make changes to this bug.