Wilhelm Vogt

Greenhorn
+ Follow
since Jul 11, 2012
Wilhelm likes ...
Linux
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Wilhelm Vogt

varsha koli wrote:
So why not for Integer?



As for the Integer part, you might look up the JLS on Integer Operations.

The operation 2147483647 + 10 results in a negative int, even before it is assigned to 'value'.

Regards
Wilhelm
9 years ago
Just some nitpicking, as already mentioned it does not really matter ...

Ulf Dittmer wrote:... As to the answer, all options but #4 are highly likely to be identical, namely, calling the no-argument constructor. ...


I am pretty sure #2 clone() does also not call the no-arg constructor, as clone() also works also if a class implements Cloneable but does not have a no-arg constructor.

fred rosenberger wrote:Doesn't it depend on what you mean by 'create an instance'? for example, de-serializing an object implies the object has already been created. It's like a balloon that has been deflated. Blowing it up doesn't "create" a balloon, does it? Or perhaps a better example is a piece of sheet music. Does the song exist when it's just written down, or does it only exist when it is being performed?


I would count a de-serialized instance as new one - it might be created while the original still exists which results in two distinct instances, it might be done several times from the same data and it might be done from input data which is not directly created by serializing an existing object. (the sheet music would be the class, which exists even if there is never an instance of it, and each performance would be an instance - hopefully each time slightly different)

And to get a whole number of possibilites to create an instance, we might also count as another half way to create an instance.

9 years ago

You cannot declare a new Exception without violating the Liskov substitution Principle. If the superclass' method is feasible without Exceptions then the subclass' method must be feasible without Exceptions.


I agree that throwing additional Exceptions will violate the Liskov substitution Principle. However, as unchecked Exceptions might be thrown without declaring them, the compiler allows declaring (and throwing) them in overriding methods - for the compiler, the overridden method is allowed to throw an unchecked exception, so the overriding method is allowed to declare them. According to the JLS: 11.2. Compile-Time Checking of Exceptions

The unchecked exception classes (ยง11.1.1) are exempted from compile-time checking.


Also the following code compiles fine in eclipse

Regards Wilhelm
10 years ago
Hi Ray,
some hint: you might want to read up the javadoc for Executor.execute() and note that setting a breakpoint at the position you indicated almost certainly changes the execution order of the threads.
Regards Wilhelm

edit: adding

at the end of the main method might also provide some insight
You might look up 'multiple implementation inheritance' or 'Diamond Problem'. As I understand the problem, it applies to this question.
10 years ago
Hi Vaibhav,

I don't know what the thoughts and design choices of the original developers were - but what happens, if there is a serializable class with a method that throws any exception (which is not serializable)?

Regards
Wilhelm
10 years ago

Interfaces do not allow static blocks but do allow public final static member.
If someone wants to initialize the variable based on some logic, it is not possible in interfaces but possible in classes.


It is not necessary to have a static block to initialize the variables based on some logic, as the variable initializer may contain a method call.


This might be useful to initialize some variables according to the current environment.

As to why static blocks are not allowed, there are some good reasons in the previous answers, but to really know we would need some documentation from the original developers.
10 years ago
You might look at the end of Chapter 8 in the JLS, Example 8.9.2-4. Enum Constants with Class Bodies, or this thread from Programmer Certification: enums. The syntax for the overriding method is standard, but as enums are special classes, the enclosing class looks different than an ordinary class definition - feel free to ask again, as the JLS is not easy to read.
10 years ago
It might also be worth noting that the following line (which might be the line throwing the OOME - hard to tell without CodeTags)

System.out.println("ArrayList :: "+thresholdElements);


migth easily triple the memory needed as it builds a StringBuffer / StringBuilder (not shure which one) with all strings from all HashMaps (keys and values) concatenated. And each time the internal buffer of a StringBuffer/Builder reaches it capacity, a new, bigger internal buffer will be created (StringBuilder.ensureCapacity() has a formula for the new size). So the memory needed would be once for the original ArrayList, about once for the final Buffer with the concatenated contents of the ArrayLIst<HashMap> and additionally more than once while the internal buffer is increased. The amount of memory needed depends on when the internal buffer needs to be expanded, this would explain why there is no obvious limit to the upper value of the loop.
If the OOME is really on the System.out.println() line, printing the ArrayList in a loop might help.
An additional thing to consider: What happens if there are three accounts (mary, bob, jane) and one thread calls getDoubleLock(mary, bob) and an other thread calls getDoubleLock(jane, bob) ? As far as I understand the proposed solution, this will leave the account 'bob' not synchronized, as there is a lock for (mary, bob) and a different one for (jane, bob).
As accounts usually have a unique identifier, a solution would be to always lock the account with the 'lower' identifier first.