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

replaced use of Arrays.copyOf for Java 1.5 compatibility #759

Merged
merged 1 commit into from
Nov 5, 2013

Conversation

adam-beneschan
Copy link

No description provided.

@kcooney
Copy link
Member

kcooney commented Nov 1, 2013

Java 5 reached end of life on October, 2009, and Java 6 reached EOL in February, 2013:
http://www.oracle.com/technetwork/java/eol-135779.html
http://slashdot.org/story/13/06/20/1819245/java-6-eold-by-oracle

I think we should ask on the community if there is any reason why JUnit should continue to support Java 5.

@dsaff
Copy link
Member

dsaff commented Nov 5, 2013

@kcooney,

A reasonable point. I think this change should go in, and we should prepare a 4.12 release that compiles under Java 5; that way, people who are stuck on Java 5 for whatever reason can stick to 4.12, if we decide to drop Java 5 support going forward.

dsaff pushed a commit that referenced this pull request Nov 5, 2013
replaced use of Arrays.copyOf for Java 1.5 compatibility
@dsaff dsaff merged commit 0c6f4dc into junit-team:master Nov 5, 2013
@dsaff
Copy link
Member

dsaff commented Nov 5, 2013

Thanks, @adam-beneschan !

@kcooney
Copy link
Member

kcooney commented Nov 5, 2013

@dsaff I understand, though, still disagree :-)

But either way, before copying our own implementation of Arrays.copyOf() couldn't we have modified the code to use a List?

@adam-beneschan
Copy link
Author

@kcooney Since things were already working and tested as an array, it made the most sense to me to keep it that way; by replacing the Arrays.copyOf() call with something equivalent, so that nothing else needed to change. I don't see any gain in using a List in this case, since the array is returned by one private method and used by another private method and then disappears. If getThreadArray were a general utility public method, perhaps it would be better if it returned a List, but then we'd also want to move it out of the FailOnTimeout class. Maybe that's a refactoring that could be done at some point.

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