src/main/java/com/flowingcode/vaadin/addons/chipfield/ChipField.java (4)

Line range hint 307-309: Fix infinite recursion in isReadonly()

The deprecated isReadonly() method contains a recursive call to itself, which will cause a StackOverflowError.

Apply this fix:

  @Deprecated
  public boolean isReadonly() {
-   return this.isReadonly();
+   return this.isReadOnly();
  }

---

Line range hint 316-326: Align required property handling with Vaadin's implementation

Similar to the disabled state, the deprecated setRequired method manipulates the element property directly while isRequired delegates to isRequiredIndicatorVisible. This inconsistency should be addressed.

Update the implementation to:

  @Deprecated
  public void setRequired(boolean required) {
-   getElement().setProperty("required", required);
+   setRequiredIndicatorVisible(required);
  }

---

Line range hint 299-326: Overall assessment of deprecation changes

The changes successfully address the Javadoc warnings by properly deprecating methods and providing references to their replacements. However, there are some implementation concerns:

1. isReadonly() has a recursive call that needs fixing
2. The deprecated methods for disabled/required states handle properties inconsistently with Vaadin's implementation

These issues should be addressed to ensure proper functionality during the deprecation period.

Consider adding a deprecation timeline in the Javadoc comments to help users plan their migration to the new methods.

---

Potential state inconsistency confirmed - update implementation needed

The web component uses a disabled property that is directly bound to the element's state (disabled$="[[disabled]]"), and there's no separate enabled property handling. To maintain consistency with Vaadin's component model:

• The deprecated setDisabled method should delegate to setEnabled(!disabled)
• The deprecated isDisabled method should delegate to !isEnabled()

This will ensure the component's state remains consistent regardless of which API is used.

🔗 Analysis chain

Line range hint 282-293: Verify disabled/enabled state consistency

The deprecated methods manipulate the disabled property directly, while Vaadin's setEnabled/isEnabled might use a different mechanism. This could lead to state inconsistency.

Let's check how Vaadin handles the enabled state:

Consider updating the implementation to:

  @Deprecated
  public void setDisabled(boolean disabled) {
-   getElement().setProperty("disabled", disabled);
+   setEnabled(!disabled);
  }

  @Deprecated
  public boolean isDisabled() {
-   return getElement().getProperty("disabled", false);
+   return !isEnabled();
  }

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Search for HasEnabled interface implementation in Vaadin
rg -A 5 "implements.*HasEnabled.*{" 

# Search for setEnabled/isEnabled implementations
ast-grep --pattern 'public void setEnabled($_) { $$$  }'

Length of output: 210

---

Script:

#!/bin/bash
# Search for HasEnabled interface implementation in Vaadin with fixed regex
rg -A 5 "implements.*HasEnabled"

# Search for setEnabled/isEnabled implementations in the ChipField class
ast-grep --pattern 'class ChipField {
  $$$
  public void setEnabled($_) {
    $$$
  }
  $$$
}'

# Search for isEnabled implementations
ast-grep --pattern 'class ChipField {
  $$$
  public boolean isEnabled() {
    $$$
  }
  $$$
}'

# Check if there are any other usages of disabled property
rg -A 3 "getElement\(\).*disabled" 

Length of output: 1048

---

Script:

#!/bin/bash
# Let's check the parent class or interfaces for enabled/disabled handling
rg -A 5 "class ChipField\s+extends|implements" 

# Search for any other disabled/enabled property usage in the element
rg "setProperty\([\"'](?:disabled|enabled)" 

# Check if there's any HasEnabled interface definition
fd -e java -x rg -l "interface.*HasEnabled"

Length of output: 4731

---

Script:

#!/bin/bash
# Let's check Component class usage since ChipField extends Component
rg -A 5 "extends\s+Component" 

# Check if there are any other implementations of setEnabled/isEnabled in the codebase
rg -A 3 "public\s+(?:void\s+setEnabled|boolean\s+isEnabled)\("

# Look for any usage of disabled/enabled state in the web component
fd -e js -x rg "disabled|enabled"

Length of output: 1529

Configuration used: CodeRabbit UI
Review profile: CHILL

#!/bin/bash
# Description: Verify Javadoc generation with Java 17 profile

# Test: Run Javadoc generation with v24 profile
mvn clean javadoc:javadoc -Pv24 -Dverbose=true

#!/bin/bash
# Description: Check for existing Javadoc warnings that could fail the build

# Test: Run Javadoc generation in verbose mode to see all warnings
mvn clean javadoc:javadoc -Dverbose=true

#!/bin/bash
# Let's check for potential Javadoc issues by searching for common patterns that cause warnings

# Search for @param, @return, and @throws tags with missing descriptions
rg -U "(@param\s+\w+\s*$|@return\s*$|@throws\s+\w+\s*$)" --type java

# Search for broken {@link} or {@code} references
rg -U "(\{@link\s+[^}]*\}|\{@code\s+[^}]*\})" --type java

# Search for #setReadOnly() specifically mentioned in issue #74
rg -U "#setReadOnly\(\)" --type java

# Look for any TODO or FIXME comments related to Javadoc
rg -i "(todo|fixme).*(@param|@return|@throws|javadoc)" --type java