Granny's Programming Pearls
"inside of every large program is a small program struggling to get out"
Win a copy of Python Continuous Integration and Delivery this week in the Python forum!

Stephan van Hulst

Saloon Keeper
+ Follow
since Sep 20, 2010
Cologne, Germany
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 Rancher Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Stephan van Hulst

The pseudo-code is not helping you, because there are no well-defined operations on mutexes and semaphores, and I think it's time that you saw some of this stuff in action, because I think you have trouble visualizing what is happening.

The sleep() method just causes the current thread to pause for a few milliseconds, to simulate that it is working on a time-consuming job.

Here's an example output from the above program:

As you can see, the program consists of two workers who both repeatedly do something, and then they do something else. Worker A is faster than Worker B, as you can see by the fact that Worker A has already finished doing something else the first time, before Worker B has even started doing something else.

Can you relate this output to the code I presented earlier? Why is Worker A faster than Worker B?
Let me write a bit of Java code, and then you can explain to me what the application does. Forget about mutexes and semaphores and such for now.
The && operator returns true if BOTH its operands are true. If the left operand is true, it must still check to see if the right operand is true as well.

If the left operand is false however, there is no need to check the right operand, because the result of the && operation will always be false.

If you change the value of a, you will see that you don't get a NullPointerException.
14 hours ago
We'd like to help you, but you have to be specific in what you don't understand. What is so alien to you?
Well, if agent wasn't null, how else would your while-loop terminate?
15 hours ago
Purely theoretical. The current thread isn't interrupted anywhere. I prefer to enforce that assertion with an AssertionException, rather than printing a message.
Raw literals are not in Java 12.

Switch expressions are a preview feature, so while they can be used in the new JDK, they're not officially part of the language yet.
16 hours ago
There are some mistakes in that code.

  • You're using the wrong name for your 5th task, it's called "UUID4".
  • You're only awaiting four of the five latches.
  • Shut down executor services in a finally-clause:

  • The harm is that if you expose a public field, you're forever bound to that data format, because you can't change or remove the field without breaking backward compatibility. If at a later moment you decide that instead of just setting or getting that field, you want to add validation or you want to change your type into a proxy that delegates to a different object... well, you can't.

    Unless your type is intended for serialization, its internal data structure is an implementation detail, and implementation details must not be exposed publicly.
    18 hours ago
    Object Oriented Programming and Functional Programming are not mutually exclusive. I also fail to see what higher order functions have to do with not exposing fields.
    20 hours ago
    That it does this in WebLogic is inconsequential. Can you confirm that you've set the contentType property in your JSP pages? Setting the content type as a meta tag in the HTML isn't enough, because that doesn't determine in which encoding the HTML it served, only how it is to be parsed by a client.

    Can you also tell us which Java EE version you're using?
    21 hours ago

    Gerard Gauthier wrote:This endorses a strict OPP view which is falling out of favor in the mainstream.

    What sources do you have to support this? Who is this mainstream? What applications are they writing?

    Yes you do expose the internals of the data but you have to expose something in an object for it to be accessible.

    Yes, that would be accessor methods. If Java had full-fledged properties I would be 100% behind that instead, but alas, it doesn't so we need to use methods for public APIs.

    The idea that its OK to expose some methods of an object while forbidding others is flawed.

    Flawed how? Can you give anexplanation for this assertion?

    The designer of the class has to consider its usage before committing to a public interface.

    And in what use case is accessing a public field directly more appropriate than accessing it through a method? This point actually speaks against using public fields, because when I provide a method I can easily use the method handle in higher order functions, rather than having to use a lambda expression, making my code much more fluent.
    21 hours ago
    That's possible with any generic type, including the collection classes, so I don't think that's fair criticism.
    22 hours ago
    Several things wrong with that. First of all, a Pair class is degenerate in that it conveys no semantic meaning and should be avoided in preference for a data structure that is appropriate for the specific problem domain. That's why Java doesn't include a Pair class in the first place.

    Now, it's fine to create classes that exposes their fields to other classes in the same package, but making fields public is always a big no no because you give up the ability to change the internal representation of the class without breaking backwards compatibility of your public API.

    So while fields don't necessarily have to be private, they should definitely never be public.
    23 hours ago