Skip to content

IGNITE-25515 Remove obsolete code from MessageReader/Writer #12110

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged

Conversation

timoninmaxim
Copy link
Member

Thank you for submitting the pull request to the Apache Ignite.

In order to streamline the review of the contribution
we ask you to ensure the following steps have been taken:

The Contribution Checklist

  • There is a single JIRA ticket related to the pull request.
  • The web-link to the pull request is attached to the JIRA ticket.
  • The JIRA ticket has the Patch Available state.
  • The pull request body describes changes that have been made.
    The description explains WHAT and WHY was made instead of HOW.
  • The pull request title is treated as the final commit message.
    The following pattern must be used: IGNITE-XXXX Change summary where XXXX - number of JIRA issue.
  • A reviewer has been mentioned through the JIRA comments
    (see the Maintainers list)
  • The pull request has been checked by the Teamcity Bot and
    the green visa attached to the JIRA ticket (see TC.Bot: Check PR)

Notes

If you need any help, please email dev@ignite.apache.org or ask anу advice on http://asf.slack.com #ignite channel.

@@ -683,7 +663,6 @@ else if (Map.class.isAssignableFrom(type)) {

/**
* @param type Field type.
* @param name Field name.
* @param colItemType Collection item type.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we should remove @param name documentation here, as field name is still used by the method implementation.

@@ -308,17 +305,11 @@ public void prepareDirectMarshal(CacheObjectContext ctx) throws IgniteCheckedExc

}

assert key != null;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do I undestand correctly that we want to make outside code responsible for this sort of checks? From codegeneration standpoint of view this code doesn't make sense, but we may want to make this information explicit - in javadoc of Message interface or somewhere else.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do I undestand correctly that we want to make outside code responsible for this sort of checks?

Yes.

but we may want to make this information explicit

which information do you mean?

Copy link
Contributor

@sergey-chugunov-1985 sergey-chugunov-1985 Jun 3, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

which information do you mean?

My point here is that I want to describe explicitly the fact that message itself knows nothing about semantics of its fields and what are possible values for the fields. So enforsing rules like "when this field is null that field should be positive" is not a responsibility of a message itself but of a code that uses (consumes) the message.

* @param dflt Default value if field not found.
* @return {@code int} value.
*/
public int readInt(String name, int dflt);
public int readInt(int dflt);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if we can get rid of this method too as its implementation simply delegates to readInt w/o parameters, effectively ignoring any value passed into as dflt.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll remove this method.

? (T)new KeyCacheObjectImpl()
: null;
}
// /** {@inheritDoc} */
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you please leave a comment here clarifying why this peice of code is commented out and when it can be uncommented?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll remove this code at all.

@timoninmaxim timoninmaxim force-pushed the IGNITE-25515__msg_read_write_clean branch from cead2cc to 4b92656 Compare June 2, 2025 16:41
Copy link

sonarqubecloud bot commented Jun 2, 2025

Quality Gate Failed Quality Gate failed

Failed conditions
26.2% Duplication on New Code (required ≤ 5%)
558 Duplicated Blocks on New Code (required ≤ 10)
4 New Code Smells (required ≤ 1)

See analysis details on SonarQube Cloud

Catch issues before they fail your Quality Gate with our IDE extension SonarQube for IDE

Copy link
Contributor

@sergey-chugunov-1985 sergey-chugunov-1985 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

PR looks good to me, lets test it on TC to make sure that no tests are broken and merge it.

@timoninmaxim timoninmaxim merged commit 12071ac into apache:master Jun 3, 2025
8 of 9 checks passed
@timoninmaxim timoninmaxim deleted the IGNITE-25515__msg_read_write_clean branch June 3, 2025 15:11
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants