slachiewicz opened a new issue, #1092:
URL: https://github.com/apache/maven-doxia/issues/1092

   ### New feature, improvement proposal
   
   `doxia-sink-api` and `doxia-core` pull in `java.desktop` for four types from
   `javax.swing.text`. None of them is used for anything Swing does. All four 
serve as
   constant tables or as a `String`-to-`Object` map.
   
   | Type | Main sources | What Doxia uses it for |
   | --- | --- | --- |
   | `javax.swing.text.html.HTML.Attribute` | 6 | A table of attribute-name 
strings |
   | `javax.swing.text.html.HTML.Tag` | 6 | A table of tag-name strings, plus 
`isBlock()` |
   | `javax.swing.text.MutableAttributeSet` | 8 | The supertype of 
`SinkEventAttributes` |
   | `javax.swing.text.AttributeSet` | 4 | Parameter and return types around 
the above |
   
   #### `HTML.Attribute` is a string table
   
   38 references in main sources; 33 are `Attribute.X.toString()`. The other 
five pass the
   constant itself as the key: `XdocSink:389` and `Xhtml5Sink:169,174,190,191`. 
Those are
   harmless only because `SinkEventAttributeSet.addAttribute` calls 
`name.toString()` on the
   key, while `getAttribute`, `isDefined` and `removeAttribute` do not — so a 
set written
   with one of those keys can only be read back with a `String`. 
`SinkEventAttributes`
   already declares `CLASS`, `ID`, `HREF`, `SRC`, `STYLE`, `NAME`, `BORDER`, 
`LANG`, `VALUE`
   and `REL` as `String` constants; of the names in use only `CONTENT` is 
missing.
   
   #### `HTML.Tag` is a name holder whose one behaviour is already wrong here
   
   `HtmlMarkup` declares 117 tags. 56 of them are already anonymous subclasses 
that override
   nothing but `toString()`, because HTML5 has tags Swing's HTML 4 table never 
had. The only
   inherited behaviour any Doxia code reads is `isBlock()`, at 
`AbstractXmlSink:113`, which
   decides whether to write a newline before a start tag.
   
   That answer is arbitrary for this codebase today. Every one of the 56 
hand-rolled tags
   inherits `isBlock() == false`, so `section`, `article`, `figure`, `main`, 
`nav`, `aside`,
   `header`, `footer`, `thead` and `tbody` are all treated as inline. From the 
other
   direction Swing reports `address`, `caption`, `form`, `hr` and `html` as 
non-block, and
   `menu` and `title` as block.
   
   #### `AttributeSet` carries machinery nothing uses
   
   `SinkEventAttributes extends MutableAttributeSet`, and the implementation is 
a
   `LinkedHashMap<String, Object>` plus a `resolveParent`. No production code 
in Doxia calls
   `setResolveParent`; only `SinkEventAttributeSetTest` does. #1075 is a 
consequence of that
   otherwise unused machinery. `entrySet()`, added in 2.1.0, is already a 
Doxia-owned
   replacement for the `Enumeration getAttributeNames()` iteration.
   
   ### Why bother
   
   Worth being plain about the size of the win. On a full JDK this costs 
nothing at runtime,
   and Doxia never touches `HTMLEditorKit`, so no AWT is initialised. What it 
buys is a
   smaller jlink image and jdeps graph, one less obstacle for GraalVM 
native-image, a future
   `module-info` that need not `requires java.desktop`, and an attribute API 
with `String`
   keys instead of `Object` ones.
   
   The blast radius outside Doxia is small. Across a checkout of the Maven 
repositories only
   three main sources name a Swing type at all: `DependenciesRenderer` in
   maven-project-info-reports-plugin and `CpdReportRenderer` in 
maven-pmd-plugin, both only
   `Attribute.X.toString()`, and `GeneratorUtils` in 
maven-plugin-tools-generators, which
   uses `HTMLEditorKit` for its own HTML parsing and has nothing to do with the 
Sink API.
   
   ### Plan
   
   **1. Drop `HTML.Attribute`. No API change, can go into 2.x.**
   
   Replace every `Attribute.X.toString()` with the `SinkEventAttributes` 
constant, adding
   `CONTENT`. Fix the five call sites that pass an `Attribute` as a key. This 
removes one of
   the four types on its own.
   
   **2. Stop iterating attribute sets through Swing. No API change, 2.x.**
   
   Move `SinkUtils.getAttributeString`, `asCssString` and `filterAttributes` off
   `getAttributeNames()` onto `entrySet()`.
   
   **3. Introduce a Doxia tag type, additively, in 2.x.**
   
   Add `org.apache.maven.doxia.markup.HtmlTag` carrying a name and an explicit 
`isBlock`,
   with parallel `writeStartTag(HtmlTag, ...)` overloads on `AbstractXmlSink` 
and the
   `Tag`-typed ones deprecated. Copy the current `isBlock` values verbatim so 
no generated
   site's whitespace moves; correcting the block table is a separate, 
deliberate change with
   its own before-and-after site diff.
   
   **4. Cut the Swing supertype, next major.**
   
   `SinkEventAttributes` declares its own `String`-keyed methods and stops 
extending
   `MutableAttributeSet`; the `HtmlMarkup` constants retype to `HtmlTag`; the 
public
   `AttributeSet` parameters on `SinkUtils` retype to `SinkEventAttributes`; 
the deprecated
   overloads go. A one-method adapter can hand a 
`javax.swing.text.AttributeSet` view to
   anyone who genuinely wanted one.
   
   ### Compatibility
   
   Steps 1 and 2 are internal. Step 3 is additive.
   
   Step 4 is why this is a major-version item, on two counts. Retyping the 
`HtmlMarkup`
   constants changes their field descriptors, which no amount of deprecation 
can stage. And
   dropping a superinterface is a japicmp break by definition, although a mild 
one in
   practice: if `SinkEventAttributes` re-declares the same method names, an 
existing
   `invokeinterface SinkEventAttributes.getAttribute` still resolves, and the 
only code that
   actually breaks is code that hands a `SinkEventAttributes` to a parameter 
typed
   `AttributeSet`. The survey above found no such call site in the Maven 
repositories.
   
   ### Related
   
   #1072 / #1073 moved `SinkEventAttributeSet` into `doxia-sink-api`, which 
puts the
   interface and its only implementation in the same module — where steps 2 and 
4 have to
   happen. #1074 retypes the protected parser hooks to `SinkEventAttributes`, 
which is the
   same major-version window as step 4. #1075 is the `resolveParent` symptom.
   
   *This issue was created with AI assistance.*
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to