Paul Clapham

You'd need a Supplier<Integer> to implement the idea that you'd only compute the value on demand, but Map.getOrDefault doesn't have a method Map.getOrDefault(Object, Supplier<V>).

Swapnil Mishra wrote:is There any solid reason why? can't we use setters and getters for private methods the same way we use them for private fields ?

There's something about that question which makes it impossible for me to understand. So let me try to figure out what you are getting at.

You can use a "getter" method to get a particular value from an object, without exposing where that value comes from. Often the value is stored in a (private) field in the object, so like this:
private int age; public int getAge() {  return age; }Likewise you can use a "setter" method to assign a particular value in an object; often that means to set the value of a (private) field in the object.

Now, there are other things that "getter" and "setter" methods might do. But typically they are public methods so that instances of other classes can use them.

But there's no reason that you can't have private "getter" and "setter" methods. Although that might seem kind of pointless, the language doesn't forbid that. And somebody might be able to figure out a non-pointless use for them.

Was that your question? Or is your question the thing I can't understand?

I am still here.

When you send a message to an SMTP server, it will not reply that the message cannot be delivered. That isn't how SMTP was designed. You may later receive one of those bounce messages, but that is not guaranteed. Some servers may just ignore undeliverable messages.

Anil Philip wrote:it should be up to the native language speakers to tell us what the primitives are in that picture language.

Probably you didn't know that Unicode supports several scripts which don't have any native speakers any more. And then there are scripts where you can't just casually go out and ask native speakers... consider Korean for example. Who are you going to ask?

It might be easier for you to accept that the Unicode Consortium knows what they are doing.

Anil Philip wrote:It makes me wonder why they did not have a separate character set(s) for graphics symbols.

People routinely write messages which include both "ordinary" characters and emojis. I can't imagine why any designer would propose treating them differently when the people writing the messages don't.

Or yes, I'm sure you could use that code from SO to display the popup when a tree node is selected.

In my application I have the possibility for a tooltip to appear when the mouse passes over a node of a JTree. However all of the tooltips I wrote are text only. Your image implies that the tooltip should be able to contain something like a JPanel, and I don't know whether that's possible. What I did was to make the tooltip be right-clickable (controlled by a MouseListener in the JPanel), and have the right-click display the panel of actions which can be selected. Or actually, it's the node with the tooltip showing which is right-clickable. Or maybe you don't even need the tooltip at all, you just need to right-click the node to get the panel of options? That part is controlled by the MouseListener in the panel.

Is an alternative to "this" going to be more verbose? Well, it's pretty hard to be less verbose than "this".

I don't have access to my copy of Eclipse right now, but "Java SE21 (jdk22.0.1)" looks weird to me. Java 21 or 22 or some weird mashup? Look at where that comes from.

Swapnil Mishra wrote:I got these ideas earlier, but want to resolve it using only Arrays.

First create an array of length N containing the numbers from 1 to N (or whatever variation on that you like). Also create another array to hold the shuffled version.
Next:
1. Choose a random entry from the input array.
2. Put that entry in the appropriate place in the shuffled array. (Fill it from left to right.)
3. Replace the input array by an array which is one entry shorter, removing the chosen entry.
Do this until the input array has length zero.

Well, this is what Cary's compiler warning message is trying to say. The fact is that void makeNoise(String... noises) and void makeNoise(String[] noises) mean exactly the same thing and can be used interchangeably. So using both of them doesn't break polymorphism, it's just confusing.

Swapnil Mishra wrote:This Code below populates the entire array with random integers (int), this array is filled with random integers at the runtime, I want to modify this code such a way that all the elements in this array are distinct, i.e no element should repeat, in this array.  

1. Create an array which contains the integers from 0 to 9. (Easiest to put them into the array in that order.)
2. Convert that array to a List.
3. Call the method Collections.shuffle on that List.
4. Convert the List back to an array.

Java has so many methods which make it so you don't have to write tedious (and error-prone) methods to do common things -- like shuffling a list of numbers.

On the other hand, if you want to use the task of shuffling an array of numbers as a programming exercise then go for it. (I think maybe you didn't notice that "shuffling" was a useful concept here.) My point here is just that Java makes a lot of that sort of programming obsolete. For example arrays themselves are nearly obsolete in modern Java, they have been replaced by List. In code I write these days I never use an array unless it's given to me by an old method which still works with arrays.

Swapnil Mishra wrote:ok

It sounds like you're dubious about that. Here's what I mean:

You can measure my height. You take a ruler and ask me to stand up straight and so on.

Now take all of the people who live on my street. You can measure their average height by measuring each of their heights and averaging those numbers.

Next, can you measure the average height of the people who live on a random street in my city? No, you can't. You could bring a statistician to measure that metric for a suitable variety of streets, or even for all streets. Then you could estimate the average height of the people who live on a random street, and you could calculate the standard deviation of the error in your estimate. But none of that arithmetic qualifies as measuring anything.

Swapnil Mishra wrote:By this, I am assuming the answer to my question is no, we cannot measure how often an element is likely to reappear. (in a sample space of 10)

Indeed. You can't measure the likelihood of anything.