Skip to content
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

Why use StringBuffer instead of StringBuilder? #212

Open
Sternbach-Software opened this issue Jul 10, 2023 · 5 comments
Open

Why use StringBuffer instead of StringBuilder? #212

Sternbach-Software opened this issue Jul 10, 2023 · 5 comments

Comments

@Sternbach-Software
Copy link
Contributor

StringBuffer sb = new StringBuffer();

The javadoc for it says

As of release JDK 5, this class has been supplemented with an equivalent class designed for use by a single thread, StringBuilder. The StringBuilder class should generally be used in preference to this one, as it supports all of the same operations but it is faster, as it performs no synchronization.

@KosherJava
Copy link
Owner

@Sternbach-Software , This is a fair question and I will change it. The reason it uses StringBuffer is because the code dates back to 2004 before the Sept 2004 release of Java 5. At this point there is no reason not to change it.

@KosherJava
Copy link
Owner

@Sternbach-Software,
While this request is trivial, I realized when looking at this class that there is no TimeZone attached to this. While the moment in time will be fine, a typical use-case will require a time zone. This requires a drop more of a change than just changing a StringBuffer to StringBuilder.

@Sternbach-Software
Copy link
Contributor Author

So java.util.Calendar?

@Sternbach-Software
Copy link
Contributor Author

Sternbach-Software commented Aug 15, 2023

Then again, what are the use cases? Maybe the most common use case is calculating a zman for a given time zone, wrapping it in a zman, and displaying it to the user. My implementation of Zman uses kotlinx.datetime.Instant which forces you to provide a timezone when you want to convert it to a LocalDateTime and when creating the Instant, but that would be the responsibility of the accessor of the Instant when they want to do that date math or conversion. Maybe it should be the same thing here? Provide them with the minimal necessary information that they couldn't easily get without rewriting the library, and let them use that to do what they need. Still not sure what use cases you intended this for. I use this to solve #217 .

@KosherJava
Copy link
Owner

Fixed in via 8a643bc.
Thanks @Sternbach-Software

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

No branches or pull requests

2 participants