John Mercier

Ranch Hand
+ Follow
since Nov 23, 2006
John likes ...
Netbeans IDE Java Linux
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by John Mercier

Joshua Vanrenterghem wrote:Sure, there is a small educational benefit for the reader to see the exact steps it takes to get code from text to a program, but after one time this should be completely understood.

I think it is a mistake to assume everyone completely understands the steps after going through them one time. Repetition and practice is needed to completely understand how it works. Each scenario adds complexity to the commands and steps. It would be very difficult to debug build problems without this practice. I think that is the point the book is trying to make.

At some point using an IDE will make you extremely productive but it is important to learn the basics first.
1 week ago

Mike Simmons wrote:The JLS officially defines it as a resource specification.  The Java tutorial on the other hand doesn't define anything, but it talks about how it "declares resources".  I would say resource specification, resource declaration, or resource list are all decent names for this, pretty clear.  It's a try-with-resources statement; these are the resources.

Thanks for the info. I think those names are fine but this video kept referring to it as the try block and it was confusing.
2 weeks ago
Hello, in try-with-resources what is the code between () called?

In the section where r1 and r2 is initialized what is it called? Is it "initialization"? That wouldn't make sense since in java 11 we can now just declare the resource used.

I'm watching a video about try-with-resources and it keeps referring to the try-block but clearly everything in () is not the same as the try-block. So I want to know if there is an official name for it.
2 weeks ago
Thanks for the info. 503 makes sense to me. Thanks!
1 month ago
Lets say I have service A which depends on service B. When service B is down service A returns 400 Bad Request when posting an object. Is this correct behavior? My worry is that this is misleading. There is nothing wrong with the request it just can't be processed because service B is down. Is there a better return code that would inform the user of this?
1 month ago

Stephan van Hulst wrote:assuming you wrote parameterized tests to begin with

I see what you mean. It would be a new set of parameters for the tests. I thought each set for a parameterized test was considered a test. What you are saying makes sense to me now.

I would have to look into the database example more. I haven't been working with database Entities lately and I'm not sure if I ever implemented equals on one.
1 month ago

Stephan van Hulst wrote:No. Tests must be simple and test one specific thing.

I agree it wouldn't make sense to have an equals transitive test fail for hashCode.

Stephan van Hulst wrote:Classes are either value types in which case they have a definition of equality that is based on all normalized fields, or they are entities or services, in which case different instances are unequal.

Thanks for posting this. Especially the part about entities. I believe The Car example where speed is ignored by Campbell Ritchie would be and entity but it seems ok to check some of the fields in the equals method. For instance if equals checked an id field for a database entity.

Stephan van Hulst wrote:Why was the field allowed to be null? This should occur only very rarely. For instance, I don't see the purpose of having an edge with a null source or target.

This was in an actual work example where a field was added to an object that could have been null.

Stephan van Hulst wrote:I don't like the code that IntelliJ generates, because it uses getClass(). That implies that you can't compare instances of base classes against instances of derived classes. Use instanceof instead and make your equals() method final.

I think that would be fine but maybe the whole class could be final?

Stephan van Hulst wrote:Not sure what you mean by this, but in general the number of  tests you need is not a simple calculation over the number of members of a class. You don't test members. You test assumptions you make about the class. The number of assumptions depend on the class design, not the number of members.

I'm only trying to calculate the number of tests needed for equals and hashCode in a class. Since these methods are based entirely on the members of the class I thought the number of tests could be determined ahead of time.

Stephan van Hulst wrote:I'm not sure what you mean by the self test. Isn't it already covered by the reflexivity test?

Yes thanks for pointing that out.
1 month ago
Yes you are! My advice is to stick to it. Continue to write code and keep applying for jobs.
2 months ago

Campbell Ritchie wrote:You always have to consider the possibility of a field being null when you write equals().

This is true but I was just thinking that if the api does not allow the field to ever be null this check would not be needed. I think this is why in the intellij generator it asks which fields are non-null. It doesn't appear to add the null checks in those cases.

The api can do this by doing adding required parameters and null checks in the constructor or in any method that sets the field.

Campbell Ritchie wrote:I am so sorry

Thanks, that is fine. I was a little confused but I think it helped bring up the point about super classes. I think I do remember these issues being discussed in Effective Java. I will have to find that part of the book soon.
2 months ago

Stephan van Hulst wrote:The only test you can perform for hashCode() is that equal objects must have equal hash codes.

Ok I think that hashCode could be checked in the equals tests. When two objects are expected to be equal the hashCode must be equal as well.

Campbell Ritchie wrote:Please explain more

What I mean is I often see developers add fields to classes without considering equals or hashCode at all. This is something I check in code reviews. It is possible some fields are not needed in equals and hashCode but it is still something that should be considered each time a field is added. One time we had a field added and it was added to equals and hashcode but in a way that would cause an NPE if the field was null.

Campbell Ritchie wrote:No. Most people don't write super.equals(ob) in their equals() method, but many people write an == test, which does exactly the same.

Using Objects.equals to check member variables helps prevent NPE. This is what intellij generates using Objects.equals if null members are allowed.

This is what it generates when not using Objects.equals

Objects.equals helps because it already does the null checking on its parameters. I'm not sure what this has to do with inheritance at this point but I think that could be considered a +1 for the number of tests needed.

I agree that testing with a null parameter is needed.

This was covered in my previous post.

So I think the number of tests needed could be

5 + 2 x members + 2 x nullableMembers + 1 x superclass (can be 0)

In the case of DirectedEdge if source and target are non-null then this would be 9 tests for equals.

* self
* null
* reflexive
* symmetric
* transitive
* sources equal
* sources not equal
* targets equal
* targets not equal
2 months ago
I’m starting to see how this question depends on a few factors. I think these are the easy tests.


So that is 5 tests at least. Then for each member variable being checked there needs to be two tests that shows a failure when the member variables are not equal. So maybe the equation is 5+2m. I picked 2m because for each member there is a test for the left side being null and the right side being null.

I believe that most of the time when a field is added equals and hashCode should be considered for an update and this is a common mistake but let's just assume all fields are considered.

The use of Objects.equals helps in preventing NullPointerExceptions. Deciding not to add null tests could be coupling the tests to the implementation of equals. To avoid this, I think in most cases they should be added. One exception is if there is no way to set a member to null through the api. I’m assuming a typical pojo with default constructor and setter for every member. So I’m adding 2n for nullable member variables. So far I have:

5 + 2m + 2n

m is the number of member variables being compared

n is the number of nullable member variables being compared

So far this only seems to cover equals but not hashCode. Is there really a way to test hashCode without knowing the implementation. If hashCode can always return 1 and still be valid I think it would need to be tested in a way that shows it is a good hashCode. It should be unique for everything that is equal and different for things that are not equal. If this is true then each of the above tests could check hashCode as well.
2 months ago
I have been using EqualsVerifier and I have attempted to write tests myself but I never felt comfortable writing them since finding EqualsVerifier. I have been thinking lately that there must be a formula for how many tests are needed to ensure the equals and hashCode contract is met. Say there is a typical pojo.

Given that there are only two member variables and that an IDE or lombok generates equals and hashCode how many tests would be needed to test these methods?
2 months ago
I think I figured out the problem. I need to declare the type for the class. I didn't have this in my tests and it finally messed things up for me. I figured out how to fix this in my project.

5 months ago
I figured out how to reproduce this error in my example project by adding a generic type to the interface and class.

This is what triggers the issue

I'm reading the java tutorial and it says

Static and non-static generic methods are allowed, as well as generic class constructors.

I am still not sure why this causes the problem or how to avoid it.
5 months ago
I have a java project on github which has a similar setup to the following classes:

Graph defines a generic method getProperty with a generic type T

The implementation returns values from a map

This getProperty works fine and type inference works as shown in my test

What I don't understand is that in my actual project this doesn't seem to work at all. I am using adoptopenjdk. You can see the compile error here on travis-ci.

This is the error I get

5 months ago