Bug 719118 - javadoc parses .class file as Java source code when -subpackages is used
javadoc parses .class file as Java source code when -subpackages is used
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: java-1.6.0-openjdk (Show other bugs)
rawhide
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Deepak Bhole
Fedora Extras Quality Assurance
:
Depends On:
Blocks: 703828 715804
  Show dependency treegraph
 
Reported: 2011-07-05 16:02 EDT by Alexander Boström
Modified: 2012-08-22 13:21 EDT (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-08-22 13:21:58 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Alexander Boström 2011-07-05 16:02:09 EDT
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 07:12:16 EDT
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 10:42:01 EDT
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 11:27:03 EDT
[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 13:51:42 EDT
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-12 21:53:54 EDT
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 14:03:52 EDT
(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 15:12:22 EDT
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 08:54:16 EDT
I think this is fixed by 7091528 which was applied in 1.10.5.
Comment 10 Alexander Boström 2012-08-22 13:21:58 EDT
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.