Hi there,
I've switched to the latest 1.8 snapshot (b84) and javadoc went nuts
about the following:
1)
/**
* @see "http://www.google.com";
*/
public class Main {}
C:\carrot2\carrotsearch.lingo3g\carrot2\tmp>javadoc -quiet Main.java
Main.java:3: error: unexpected content
* @see "http://www.g
th seem odd.
>
> I will investigate. Thanks for the reports.
>
> You can probably work around the issues by disabling doclint for now,
> -Xdoclint:none.
>
> -- Jon
>
>
> On 04/10/2013 06:31 AM, Dawid Weiss wrote:
>>
>> Hi there,
>>
>> I've swit
ent change which may be a cause. So, I'm hoping
> there is enough info in your report in this case for me to make
> progress.
>
> I'll post info about issue numbers in due course.
>
> -- Jon
>
>
> On 04/10/2013 11:55 PM, Dawid Weiss wrote:
>>
>> Thank
Hello,
I just filed a bug for Lucene [1] but I can't explain why there is a
difference between calling javadoc with several lint options:
javadoc ... -Xdoclint:all -Xdoclint:-missing -Xdoclint:-accessibility
versus aggregating them in one line:
javadoc ... -Xdoclint:all,-missing,-accessibility
Here is another gem I discovered while porting an ant build to gradle.
Applies to Java 11-14. Say you're compiling class Bat like this:
javadoc -classpath p2.jar -d tmp p3/bat/Bat.java
p2 contains class Baz which Bat imports. Baz in turn has a reference
to a class not on classpath (annotation, fo
For the record -- Java 8 works as expected, Java 9 and on does not.
Dawid
On Sat, Jan 11, 2020 at 3:41 PM Dawid Weiss wrote:
>
> Thank you, Jon.
>
> From what I can see on github this buggy scenario is fairly common...
> I checked with Java 11 on and it's present in al
gt;
> Filed
>
> https://bugs.openjdk.java.net/browse/JDK-8236949
>
> -- Jon
>
> On 01/10/2020 07:45 AM, Jonathan Gibbons wrote:
> > Dawid,
> >
> > Thanks for reporting this. If this is the case, it is a bug.
> > I'll investigate and file a bug if necessary.
Hello everyone,
I had a somewhat wild idea of trying to modify the behavior of the
StandardDoclet to write directly to a ZIP file (instead of the file
system). All the pieces fall into place relatively easily:
1) Create a custom Doclet that extends (public) StandardDoclet and
overrides the run me
r stated in the docs
seems more useful in practice).
Dawid
On Thu, Apr 30, 2020 at 4:26 PM Jonathan Gibbons
wrote:
>
> Dawid,
>
> Thanks for the report; this should be investigated further.
>
> Do you want to file an issue against javadoc, or would you like us to do so?
>
>
va/javase/11/docs/api/java.compiler/javax/tools/ToolProvider.html#getSystemDocumentationTool()
>
> -- Jon
>
>
> On 5/7/20 1:29 AM, Dawid Weiss wrote:
> > Hello everyone,
> >
> > I had a somewhat wild idea of trying to modify the behavior of the
> > StandardDoclet
or that internal 'WorkArounds' class is less than
> ideal, as you might guess from the name.
>
> But, keep asking these questions; it helps us to know how folk are
> trying to use tools like javadoc.
>
> -- Jon
>
> On 5/7/20 7:40 AM, Dawid Weiss wrote:
> > T
Hi Jon,
> In this case, it would (probably) be easier for you to just use a
> standard StandardFileManager (no subtyping required) and use
> the setLocation call to set the DOCUMENTATION_OUTPUT [...]
Ah... Brilliant. You're right - it'd be a much better solution.
> At least part of the problem
' option's path and
conditionally switches to ZIP filesystem if this seems to point to a
"zip/jar" file. I'll leave it at [1] in case somebody finds it useful.
Dawid
[1] https://github.com/dweiss/javadoc-zip
On Sun, Jul 12, 2020 at 2:58 AM Jonathan Gibbons
wrote:
>
>
&g
Hello and Merry Christmas,
I discovered this odd javac behavior with jdk8 up to jdk15 (didn't
check the latest head). This source file (note the anchor tag over
multiple lines):
/**
* Lucene internals or asking for help on mailto:java-u...@lucene.apache.org";>java-u...@lucene.apache.org
*/
pub
d to the `@`
>> character in the mailto: link. Change that character in `Breaks.java`
>> and it passes.
>>
>> Do you want to file the bug, or would you like me to?
>>
>> -- Jon
>>
>> On 12/23/20 2:39 AM, Dawid Weiss wrote:
>>>
etween Breaks and
> Passes2 is the newline character. There's a bug in the code that tries
> to detect malformed attributes by looking for `@` after a newline. The
> flag for the newline should have been reset by the intervening non-white
> characters, but was not.
>
> -- Jon
&g
16 matches
Mail list logo