Skip to content

Conversation

@Pankraz76
Copy link
Contributor

@Pankraz76 Pankraz76 commented Jun 5, 2025

Following this checklist to help us incorporate your
contribution quickly and easily:

  • Make sure there is a JIRA issue filed
    for the change (usually before you start working on it). Trivial changes like typos do not
    require a JIRA issue. Your pull request should address just this issue, without
    pulling in other changes.
  • Each commit in the pull request should have a meaningful subject line and body.
  • Format the pull request title like [MNG-XXX] SUMMARY,
    where you replace MNG-XXX and SUMMARY with the appropriate JIRA issue.
  • Also format the first line of the commit message like [MNG-XXX] SUMMARY.
    Best practice is to use the JIRA issue title in both the pull request title and in the first line of the commit message.
  • Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
  • Run mvn clean verify to make sure basic checks pass. A more thorough check will
    be performed on your pull request automatically.
  • You have run the Core IT successfully.

If your pull request is about ~20 lines of code you don't need to sign an
Individual Contributor License Agreement if you are unsure
please ask on the developers list.

To make clear that you license your contribution under
the Apache License Version 2.0, January 2004
you have to acknowledge this by using the following check-box.

@Pankraz76 Pankraz76 force-pushed the auto-close-MavenProperties branch from c078b6c to 6981dd5 Compare June 5, 2025 18:47
@Pankraz76 Pankraz76 marked this pull request as ready for review June 5, 2025 18:47
Copy link
Contributor

@gnodet gnodet left a comment

Choose a reason for hiding this comment

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

That's wrong imho.
The one responsible for closing the out Writer should be the caller, as the writer is passed as an argument. Closing the PropertiesWriter will automatically close the out writer too, so that looks a bad idea to me.

@Pankraz76
Copy link
Contributor Author

yes this one looks special. will check, merci.

@Pankraz76
Copy link
Contributor Author

Pankraz76 commented Jun 6, 2025

Closing the PropertiesWriter will automatically close the out writer too, so that looks a bad idea to me.

the scope of writer remains the same, so does the gc, it will flush in both cases, so the behavior seems consistent overall.

lets request some secret expertise @elharo. 🥷

image

@Pankraz76 Pankraz76 requested a review from gnodet June 6, 2025 16:28
@slachiewicz slachiewicz marked this pull request as draft June 6, 2025 17:21
@gnodet
Copy link
Contributor

gnodet commented Jun 6, 2025

If the properties writer is not closed, it should be flushed immediately, gc can happen way after out is closed.

@Pankraz76
Copy link
Contributor Author

Pankraz76 commented Jun 6, 2025

it should be flushed immediately

yes then flush is mandatory. but is this really important?

Assuming order will remain the same when impl. will flush itself.

It feels like optimization not required by test nether by business case, assuming result is the same.

Only real difference seems explicit call, of whats done by gc, as well just as it is right now, we just calling flush before close by gc and flush again.

Never needed to use .flush as always the impl. is smart enough to do so.

Its a expensive operation just like finalize should never been called directly. thats some else regards never to be called by dev imho.

The cleanup order of the writer instance remains the same, calling close and therefore flush. Its not our regard of doing so. Thats why try to leverage autocloseable feature.

@Pankraz76 Pankraz76 marked this pull request as ready for review June 7, 2025 15:04
@slachiewicz slachiewicz closed this Jun 9, 2025
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.

3 participants