#1012103 android-platform-external-doclava: FTBFS with OpenJDK 17 due to com.sun.javadoc removal

#1012103#5
Date:
2022-05-30 08:31:34 UTC
From:
To:
android-platform-external-doclava because it uses classes from
the com.sun.javadoc package which was removed:


  :compileJava
  Putting task artifact state for task ':compileJava' into context took 0.0 secs.
  Up-to-date check for task ':compileJava' took 0.447 secs. It is not up-to-date because:
    No history is available.
  All input files are considered out-of-date for incremental task ':compileJava'.
  Compiling with JDK Java compiler API.
  warning: [options] source value 7 is obsolete and will be removed in a future release
  warning: [options] target value 7 is obsolete and will be removed in a future release
  warning: [options] To suppress warnings about obsolete options, use -Xlint:-options.
  /<<PKGBUILDDIR>>/src/com/google/doclava/ClassInfo.java:20: error: package com.sun.javadoc does not exist
  import com.sun.javadoc.ClassDoc;
                        ^
  /<<PKGBUILDDIR>>/src/com/google/doclava/ClassInfo.java:91: error: cannot find symbol
    public ClassInfo(ClassDoc cl, String rawCommentText, SourcePositionInfo position,
                     ^
    symbol:   class ClassDoc
    location: class ClassInfo
  /<<PKGBUILDDIR>>/src/com/google/doclava/ClassInfo.java:1849: error: cannot find symbol
    private ClassDoc mClass;
            ^
    symbol:   class ClassDoc
    location: class ClassInfo
  /<<PKGBUILDDIR>>/src/com/google/doclava/PackageInfo.java:34: error: cannot find symbol
    public PackageInfo(PackageDoc pkg, String name, SourcePositionInfo position) {
                       ^
    symbol:   class PackageDoc
    location: class PackageInfo
  /<<PKGBUILDDIR>>/src/com/google/doclava/PackageInfo.java:291: error: cannot find symbol
    private PackageDoc mPackage;
            ^
    symbol:   class PackageDoc
    location: class PackageInfo
  /<<PKGBUILDDIR>>/src/com/google/doclava/PackageInfo.java:21: error: package com.sun.javadoc does not exist
  import com.sun.javadoc.*;
  ^
  /<<PKGBUILDDIR>>/src/com/google/doclava/Doclava.java:81: error: cannot find symbol
    public static RootDoc root;
                  ^
    symbol:   class RootDoc
    location: class Doclava
  /<<PKGBUILDDIR>>/src/com/google/doclava/Doclava.java:145: error: cannot find symbol
    public static boolean start(RootDoc r) {
                                ^
    symbol:   class RootDoc
    location: class Doclava

#1012103#18
Date:
2023-02-08 19:10:39 UTC
From:
To:
Doclava, which does not work with Java newer than 11.  Upstream still builds it
with java8. As in Android 13 still uses java8 in the build.  Is there any hope?

#1012103#27
Date:
2025-10-08 05:32:41 UTC
From:
To:
Hi,

we have

  #1011567: android-framework-23: FTBFS with OpenJDK 17 due to com.sun.javadoc removal
  #1012103: android-platform-external-doclava: FTBFS with OpenJDK 17 due to com.sun.javadoc removal

(and maybe more related packages).  It seems the

Hans-Christoph Steiner <hans@eds.org> wrote[1]

  Looks like doclava would need to be ported to use the API that replaces
  com.sun.javadoc:
https://docs.oracle.com/en/java/javase/11/docs/api/jdk.javadoc/jdk/javadoc/doclet/package-summary.html#migration
  If someone does the migration, I can take care of the packaging updates.

Thank you Hans-Christian I would help as well but as you analysed in the
android-platform-external-doclava bug report[2]

  Doclava, which does not work with Java newer than 11.  Upstream still builds it
  with java8. As in Android 13 still uses java8 in the build.  Is there any hope?

I've checked upstream Git[3] and found this commit

commit c8be8c65ab9dab2c4d3ec6ee2e717a3fae01c93d
Author: Nikita Iashchenko <nikitai@google.com>
Date:   Mon Feb 6 15:47:35 2023 +0000

    doclava17: Update gradle build/test infrastructure

    Root project has two subprojects that share common doclava
    sources except Doclava.java: 'doclava8' for original build
    with jdk11, and 'doclava17' – with new com.sun.javadoc
    implementation and building/running with jdk17.

    Also added an end-to-end test target e2eTestAOSP that runs
    old and new doclavas on same set of inputs for easier
    debugging and comparison.

    Bug: 260694901
    Test: ./gradlew doclava17:test
    Test: ./gradlew e2eTestAOSP
    Test: ./gradlew :doclava8:e2eTestAOSP :doclava17:e2eTestAOSP
    Merged-In: Iad2aed1940cf293f8766310b21b34cc8885feb2d
    Change-Id: Iad2aed1940cf293f8766310b21b34cc8885feb2d


This is even more recent than

   android-platform-external-doclava (9.0.0+r42-1) experimental
   -- Kai-Chung Yan <seamlik@debian.org>  Wed, 24 Jul 2019 22:27:11 +0200

(which does not build any more as well).  So from my naive point
of view there might be chances that fetching a later upstream
release (I do not understand their versioning scheme) or some
later Git commit might help.

Is there anyone who could have some educated look into this?

Kind regards
   Andreas.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1011567#19
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1012103#18
[3] https://android.googlesource.com/platform/external/doclava

#1012103#32
Date:
2025-11-09 07:23:24 UTC
From:
To:
Hi,

android-framework-23 has two open RC bugs which are both unanswered
since more than two years.  I wonder if its time to remove this package
from Debian.

If there is no response here in the next 31 days I will ask for removal.

Kind regards
    Andreas.

#1012103#37
Date:
2025-11-12 20:56:47 UTC
From:
To:
Hello Andreas and everyone else,

Andreas Tille <andreas@an3as.eu> writes:

I would be sad to see android-framework-23 getting removed as I'm using
it to build my own Android apps; google-android-*-installer is not an
option because the EULA contains clauses that I cannot agree to. Already
have to figure out what to do about the dalvik-exchange removal [1]; the
replacement tool d8 is not in Debian and is hard to build from source
locally.

On the other hand I do understand the reasoning behind wanting to remove
the package from Debian and unfortunately don't have time to help out
either.

Kudos to everyone involved for maintaining the packages so far; they've
been a huge help!


Sascha

[1] https://bugs.debian.org/1078592