Support java interfaces?

[issmirnov]

Hi @mosra,

Thanks for putting this together. I'm trying to use this with a codebase that relies on a java interface (source here) and I'm seeing a crash at

m.css/doxygen/dox2html5.py

Line 3115 in a02eeab

else: assert False # pragma: no cover

I did some digging and it looks like the XML is correctly showing that the kind is an interface. Can this code path be fixed without too much trouble?

Sample of generated XML

<?xml version='1.0' encoding='UTF-8' standalone='no'?>
<doxygen xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="compound.xsd" version="1.8.13">
  <compounddef id="interfaceorg_1_1chromium_1_1base_1_1annotations_1_1CalledByNative" kind="interface" language="Java" prot="public">
    <compoundname>org::chromium::base::annotations::CalledByNative</compoundname>
      <sectiondef kind="public-func">
      <memberdef kind="function" id="interfaceorg_1_1chromium_1_1base_1_1annotations_1_1CalledByNative_1ac43248b9f1706e4302741534e242efe6" prot="public" static="no" const="no" explicit="no" inline="no" virt="non-virtual">
        <type>String</type>
        <definition>String org.chromium.base.annotations.CalledByNative.value</definition>
        <argsstring>() default &quot;&quot;</argsstring>
        <name>value</name>
        <briefdescription>
        </briefdescription>
        <detaileddescription>
        </detaileddescription>
        <inbodydescription>
        </inbodydescription>
        <location file="java/org/chromium/base/annotations/CalledByNative.java" line="22" column="1"/>
      </memberdef>
      </sectiondef>
    <briefdescription>
    </briefdescription>
    <detaileddescription>
<para>is used by the JNI generator to create the necessary JNI bindings and expose this method to native code. </para>    </detaileddescription>
    <location file="java/org/chromium/base/annotations/CalledByNative.java" line="18" column="1" bodyfile="java/org/chromium/base/annotations/CalledByNative.java" bodystart="18" bodyend="23"/>
    <listofallmembers>
      <member refid="interfaceorg_1_1chromium_1_1base_1_1annotations_1_1CalledByNative_1ac43248b9f1706e4302741534e242efe6" prot="public" virt="non-virtual"><scope>org::chromium::base::annotations::CalledByNative</scope><name>value</name></member>
    </listofallmembers>
  </compounddef>
</doxygen>

[mosra]

Hi,

the Doxygen XML output processing was originally tailored to C and C++ and I'm afraid adding support for Java is more than just fixing the asserts -- the output templates would need to get updated as well, since you definitely do not want to have Java namespaces packages separated by ::, for example, and other C++-isms -- Doxygen itself was behaving like that for a long time (treating Java with C++ syntax) and it did no good. Plus the new concepts like interfaces (which are not present in C++) need to be introduced, as neither the script nor the templates are aware of them. And then writing tests for all this so updates for one language don't cause regressions for the other.

On a related note, as a longer-term project I'm planning to extend the script to support C# (#76) and Python (#80), however taking a bit different approach there -- instead of relying on Doxygen (and all its misfeatures / parser bugs), introspecting the C# / Python APIs directly via reflection (using IronPython for C#) and taking the documentation strings from there as well, instead of attempting to parse the sources directly. I didn't investigate what is the equivalent introspection / docblock extraction API in Java, but I'm sure there is something as well. In my opinion this is a more viable solution in the long-term than relying on Doxygen for parsing.

Unfortunately at the moment I have no time to look into this. The Python support from #80 is currently at the top of my priority list and things I'll be doing for it could benefit the potential future Java support, but that's about it I'm afraid -- I can't even give you an estimate when I could take a look at this, sorry. Too many things to do, too little time :)

[issmirnov]

Got it, totally understand. So many interesting projects and tasks in this life, and not enough time to get to them all! Glad to see you prioritizing the important things for you and the project.

Best of luck with the python side of things! I'll close this issue out for now, and if you ever decide to get to this we can always reopen 😄

[mosra]

Keeping the issue open doesn't cost me any time, fortunately :)

I'll reopen this to avoid people opening the same issue again. And if it stays open, there's a non-zero chance someone chimes in and suggests a way how to implement this using some Java introspection.