We Keep Coding

Singletone method

I need a method that will always be executed in one instance. For example, this method was called from different class instances and different threads at the same time. In this case, they should be executed one at a time, and not simultaneously, despite the fact that they are called from different instances.
I cant make it just static and synchronized, because it have a lot of inner code, which cant be refactored to static
For now I have next idea:
private static Boolean isMethodRun = false;
public void singletoneMethod() {
synchronized(Boolean) {
if (!isMethodRun) {
isMethodRun = true;
} else {
for (int i = 0; i < 10; i++) {
if (isMethodRun) {
Thread.sleep(2_000);
} else {
isMethodRun = true;
break;
}
}
}
}
try {
//inner code
} catch (Throwable e) {
//logs
throw e;
} finally {
isMethodRun = false;
}
}
Is there any prettier way to get such functionality

The easiest way would be to synchronize the method. Since you appear to have defined the isMethodRun variable static, it looks like you would want to synchronize on a static thing:
private static final Object lock = new Object();
public void singletoneMethod() {
synchronized (lock) {
// The code you want only to execute one-at-a-time.
}
}
You could have synchronized on the class - synchronized (WhateverYourClass.class) - but that is vulnerable to anybody in the JVM synchronizing on the class elsewhere. Using an inaccessible Object like this is more robust.

So basically you want only one singletonMethod call to proceed at a time1.
This is the simplest solution:
public static synchronized void singletonMethod() {
// your business logic here
}
You said:
I can't make it just static and synchronized, because it have a lot of inner code, which can't be refactored to static
I'm not convinced that it can't be refactored2, but if you say so, here are some alternatives:
private static final Object lock = new Object(); // Must be static!
public void singletonMethod() {
synchronized (lock) {
// your business logic here
}
}
Or
public static synchronized void oneAtATime(Runnable runnable) {
runnable.run();
}
You could use the oneAtATime method like this:
oneAtATime(() -> { // your business logic here }); // Java 8+
oneAtATime(new Runnable() {
public void run() {
// your business logic here
}
});
Apart from the first one (at the top), these alternatives all allow you to refer to instance variables in the "business logic". You just need to implement the "business logic" in the appropriate scope. (And even in the first case, it is trivial to pass an instance reference to a static method so that it can call methods on the instance.)
To use the above in a thread-safe fashion, you need to ensure that the "business logic" is all thread-safe. That will depend on other code in the application; e.g. how other threads / methods use any shared objects that this "business logic" is operating on.
why would static be needed here? Can't it just be public synchronized void singletonMethod? Or do the memory barriers not work for accessing static fields? – luk2302 25 mins ago
We need a static lock or a static synchronized method in order to meet the stated requirement that only one call is in progress at a time. If there is more than one lock, you won't get serialization.
It would be possible to implement the "one at a time" logic as a synchronized instance method of a (properly implemented) Singleton class. However, there is not much point unless you have other good uses for the Singleton class. (Bear in mind that the Singleton pattern brings problems of its own.)
1 - This is not what the term "singleton" conventionally means ...
2 - In fact the refactoring required is trivial. Just put your business logic into an instance method of YourClass declared as (say) businessLogic(). Then you can define the one-at-a-time method in YourClass as follows: static synchronized void singleton(YourClass arg) { arg.businessLogic(); }. You would typically use it (within YourClass) like this: YourClass.singleton(this);

Use 'new' without 'xyz = new abc'

I have a class as follows:
package org.requiredinput.rpg1.desktop;
import com.badlogic.gdx.backends.lwjgl.LwjglApplication;
import com.badlogic.gdx.backends.lwjgl.LwjglApplicationConfiguration;
import org.requiredinput.rpg1.Rpg1;
public class DesktopLauncher {
public static void main (String[] arg) {
LwjglApplicationConfiguration config =
new LwjglApplicationConfiguration();
config.title = "Awesome rpg";
config.width = 800;
config.height = 480;
new LwjglApplication(new Rpg1(), config);
}
}
My question is - on the last line, the new statement is used without being preceded by an =.
What is being created? A new LwjglApplication object? Class?
And why doesn't it need to be instantiated like app = new LwjglApplication() for example?

Your code creates a new object and doesn't give it a name, which means that it can't be used by main() afterwards. The code in the constructor will still run, and an object of type LwjglApplication will still be created. main() won't hold a reference to it, though.
This is just like when you call a function that returns a value without assigning it to a variable:
int foo() {
System.out.println("Ron Paul 2016!");
return 42;
}
public static void main(String... args) {
foo(); // will print out "Ron Paul 2016!" (w/o quotes)
}
Here, nothing is being done with the return value from foo() but the println() call will still run.
This is commonly used when the constructor (in this case, that of LwjglApplication) has a beneficial side-effect. In your specific case, a window is being popped up as a result of the constructor. (As RafazZ said, you don't need to access the object that's being constructed because there are other ways to access it, provided through the third-party vendor's API.)
As Drew Kennedy mentioned in a comment, this pattern is also used for single-use objects.
Let's say you have a class that looks like this:
class Foo {
void bar() {
// stuff that requires being in an instance, such as...
System.out.println(this.getClass());
}
public static void main(String... args) {
(new Foo()).bar();
}
}
Note that the program doesn't bother assigning a name to the newly created Foo object, since it's only being used for the benefit of calling its bar() method.

According to the BadLogic documentation, LwjglApplication creates a lightweight fullscreen window. This is sometimes done when designing stuff like games - you create a window, and then forget about it, because you don't need to modify it explicitly. You can still modify it using other methods - for that you need to get more familiar with the API provided by the vendor (BadLogic in your case).
Here is a top level description for LwjglApplication.
TL;DR UPDATE: Once DesktopLauncher is called it will create an OpenGL fullscreen window object by calling new LwjglApplication. Every time you call an OpenGL method, it will assume that you are implying the object that was created in the DesktopLauncher.

An LwjglApplication object is being created, but not ASSIGNED to a variable.
So essentially you can't access it later. But it exists.

An object is being created but you are not assigning it a label. It is very likely the author is just interested in calling LwjglApplication constructor.
Contrary with what others have stated, the object created is not necessarily up for garbage collection. There are a few ways the object can actually stay alive depending on the particular object, e.g., Singleton.

new MyClass() is a constructor call syntax in Java. Constructor is a special method, which returns a constructed object. It has some nuanses, but generally can be regarded as just method call.
So new without assignments is just calling a function and not using it's return value.
It is possible for all functions in Java (not to use return value).
The reason can be side effects, for example. Thus constructor may register it's result in some global static list.
If return value is an object and it is really not used, then it will be garbage collected later, as with every unused object.
Example:
package tests;
public class Runner {
public static class Line {
public Line(String line) {
System.out.println(line);
}
}
public static void main(String[] args) {
new Line("Hello world");
}
}

Publishing thread safe object [duplicate]

According to the Java Language Specification, constructors cannot be marked synchronized because other threads cannot see the object being created until the thread creating it has finished it. This seems a bit odd, because I can indeed have another thread view the object while it's being constructed:
public class Test {
public Test() {
final Test me = this;
new Thread() {
#Override
public void run() {
// ... Reference 'me,' the object being constructed
}
}.start();
}
}
I know that this is a pretty contrived example, but it seems in theory that someone could come up with a more realistic case where marking the constructor synchronized would be legitimate in order to prevent races with threads like this one.
My question is this: is there a reason that Java would specifically disallow the synchronized modifier on a constructor? Perhaps my above example is flawed, or perhaps there really is no reason and it's an arbitrary design decision. In either case, I'm really curious and would love to know the answer.

If you really need synchronization of the rest of the constructor versus any threads which anyhow gets a reference to your not-yet-totally-constructed object, you can use a synchronized-block:
public class Test {
public Test() {
final Test me = this;
synchronized(this) {
new Thread() {
#Override
public void run() {
// ... Reference 'me,' the object being constructed
synchronized(me) {
// do something dangerous with 'me'.
}
}
}.start();
// do something dangerous with this
}
}
}
Usually it is considered bad style to "give out" your not-yet-constructed object like this, so a synchronized constructor is not necessary.
In some corner cases a synchronized constructor would be useful. Here is a more realistic example, from the discussion of Bozho's answer:
public abstract class SuperClass {
public SuperClass() {
new Thread("evil") { public void run() {
doSomethingDangerous();
}}).start();
try {
Thread.sleep(5000);
}
catch(InterruptedException ex) { /* ignore */ }
}
public abstract void doSomethingDangerous();
}
public class SubClass extends SuperClass {
int number;
public SubClass () {
super();
number = 2;
}
public synchronized void doSomethingDangerous() {
if(number == 2) {
System.out.println("everything OK");
}
else {
System.out.println("we have a problem.");
}
}
}
We want that the doSomethingDangerous() method is only called after construction of our SubClass object is complete, e.g. we only want the "everything OK" output. But in this case, when you only can edit your SubClass, you have no chance of achieving this. If the constructor could be synchronized, it would solve the problem.
So, what we learn about this: never do something like I did here in the superclass constructor, if your class is not final - and don't call any non-final methods of your own class from your constructor.

The question has been raised on a discussion list used by the writers of the Java concurrent API and the Java Memory Model. Several answers were given, in particular Hans Boehm replied:
Some of us (myself included IIRC) actually argued during the Java memory model deliberations that synchronized constructors should be allowed. Now I could go either way on it. Client code shouldn't use races to communicate the reference, so it shouldn't matter. But if you don't trust the clients of [your class], I think synchronized constructors could possibly be useful. And that was much of the reasoning behind final field semantics. [...] As David said, you can use synchronized blocks.

Because synchronized guarantees that actions on the same objects are not to be performed by multiple threads. And when the constructor is called you still don't have the object. It is logically impossible for two threads to access the constructor of the same object.
In your example, even if a method is invoked by the new thread, it is no longer about the constructor - it is about the target method being synchronized or not.

Constructor Modifiers section in JLS clearly says
There is no practical need for a constructor to be synchronized, because it would
lock the object under construction, which is normally not made available to other
threads until all constructors for the object have completed their work.
So there is no need for constructor to be synchronized.
Also it is not recommended to give out the objects reference(this) before object is created. One of the possible ambiguous situations would be to give out the objects reference is superclass constructor when subsclass object is being created.

In your example, the constructor is only actually called once from one thread.
Yes, it is possible to get a reference to an incompletely constructed Object (some discussions around double check locking and why it is broken reveal this problem), however, not by calling the constructor a second time.
Syncronized on the constructor would prevent two threads from calling the constructor on the same Object simultaneously, and that is not possible, as it is never possible to call the constructor on an object instance twice, period.

I see little reason to forbid constructors to be synchronized. It would be useful in many scenarios in multi-threaded applications. If I understand the Java Memory Model correctly (I read http://jeremymanson.blogspot.se/2008/11/what-volatile-means-in-java.html) the following simple class could have benefited from a synchronized constructor.
public class A {
private int myInt;
public /*synchronized*/ A() {
myInt = 3;
}
public synchronized void print() {
System.out.println(myInt);
}
}
In theory, I believe a call to print() could print "0". This could happen if an instance of A is created by Thread 1, the reference to the instance is shared with Thread 2, and Thread 2 calls print(). If there is no special synchronization between the write myInt = 3 of Thread 1 and the read of the same field by Thread 2, Thread 2 is not guaranteed to see the write.
A synchronized constructor would fix this issue. Am I right about this?

The following code can achieve the expected result for synchronized constructor.
public class SynchronisedConstructor implements Runnable {
private int myInt;
/*synchronized*/ static {
System.out.println("Within static block");
}
public SynchronisedConstructor(){
super();
synchronized(this){
System.out.println("Within sync block in constructor");
myInt = 3;
}
}
#Override
public void run() {
print();
}
public synchronized void print() {
System.out.println(Thread.currentThread().getName());
System.out.println(myInt);
}
public static void main(String[] args) {
SynchronisedConstructor sc = new SynchronisedConstructor();
Thread t1 = new Thread(sc);
t1.setName("t1");
Thread t2 = new Thread(sc);
t2.setName("t2");
t1.start();
t2.start();
}
}

Such a synchronization might make sense in some very rare cases, but I guess, it's just not worth it:
you can always use a synchronized block instead
it'd support coding in a pretty strange way
on what should it synchronize? A constructor is a sort-of static method, it works on an object but gets called without it. So synchronizing on the class also makes (some) sense!
When in doubt, leave it out.

Note that constructors cannot be synchronized — using the synchronizedkeyword with a constructor is a syntax error. Synchronizing constructors doesn't make sense, because only the thread that creates an object should have access to it while it is being constructed.

What use is the final modifer on method/constructor parameters

Hello
What use is the final modifier on a method/constructor parameter?
Ex:
class someClass {
private final double some; // I understand the use of final in this context, immutability etc..
public someClass(final double some) {
// I don't understand what purpose is served by making "some" final
this.some = some;
}
public void someMethod(final double some) {
// I don't understand what purpose is served by making "some" final
}
}

There are 2 main situations when you need it:
1) you want to use the parameter inside local class (usually, anonymous class), like:
public void foo(final String str) {
Printer p = new Printer() {
public void print() {
System.out.println(str);
}
};
p.print();
}
2) you like the style when every variable which is not modified is marked with the final word (it is generally a good practice to keep as much things immutable as possible ).

Well, the purpose is that you cannot asign the parameter with anything
public someClass(T some) {
some = null; //You can do this. Maybe you want to use the variable `some` later on in your constructor
}
public someClass(final T some) {
some = null; //You can't do this. If you want to reuse `some` you can't.
}
Useful? Not much. Normally you don't use arguments variables. But in some special situations you may want to be able to do it.
Anyway, if some does new someClass(mySome) , mySome will never be changed although inside the function you assign values to the argument. There is no such thing as pass-by-refrence in Java. Variables are primitives or references to objects, never the object itself.

From the point of view of the function, the some variable is a constant.
Another benefit would be to prevent variable reuse. That is to say "some" should be used for only one purpose.

Java: reference escape

Read that the following code is an example of "unsafe construction" as it allows this reference to escape. I couldn't quite get how 'this' escapes. I am pretty new to the java world. Can any one help me understand this.
public class ThisEscape {
public ThisEscape(EventSource source) {
source.registerListener(
new EventListener() {
public void onEvent(Event e) {
doSomething(e);
}
});
}
}

The example you have posted in your question comes from "Java Concurrency In Practice" by Brian Goetz et al. It is in section 3.2 "Publication and escape". I won't attempt to reproduce the details of that section here. (Go buy a copy for your bookshelf, or borrow a copy from your co-workers!)
The problem illustrated by the example code is that the constructor allows the reference to the object being constructed to "escape" before the constructor finishes creating the object. This is a problem for two reasons:
If the reference escapes, something can use the object before its constructor has completed the initialization and see it in an inconsistent (partly initialized) state. Even if the object escapes after initialization has completed, declaring a subclass can cause this to be violated.
According to JLS 17.5, final attributes of an object can be used safely without synchronization. However, this is only true if the object reference is not published (does not escape) before its constructor finished. If you break this rule, the result is an insidious concurrency bug that might bite you when the code is executed on a multi-core / multi-processor machines.
The ThisEscape example is sneaky because the reference is escaping via the this reference passed implicitly to the anonymous EventListener class constructor. However, the same problems will arise if the reference is explicitly published too soon.
Here's an example to illustrate the problem of incompletely initialized objects:
public class Thing {
public Thing (Leaker leaker) {
leaker.leak(this);
}
}
public class NamedThing extends Thing {
private String name;
public NamedThing (Leaker leaker, String name) {
super(leaker);
}
public String getName() {
return name;
}
}
If the Leaker.leak(...) method calls getName() on the leaked object, it will get null ... because at that point in time the object's constructor chain has not completed.
Here's an example to illustrate the unsafe publication problem for final attributes.
public class Unsafe {
public final int foo = 42;
public Unsafe(Unsafe[] leak) {
leak[0] = this; // Unsafe publication
// Make the "window of vulnerability" large
for (long l = 0; l < /* very large */ ; l++) {
...
}
}
}
public class Main {
public static void main(String[] args) {
final Unsafe[] leak = new Unsafe[1];
new Thread(new Runnable() {
public void run() {
Thread.yield(); // (or sleep for a bit)
new Unsafe(leak);
}
}).start();
while (true) {
if (leak[0] != null) {
if (leak[0].foo == 42) {
System.err.println("OK");
} else {
System.err.println("OUCH!");
}
System.exit(0);
}
}
}
}
Some runs of this application may print "OUCH!" instead of "OK", indicating that the main thread has observed the Unsafe object in an "impossible" state due to unsafe publication via the leak array. Whether this happens or not will depend on your JVM and your hardware platform.
Now this example is clearly artificial, but it is not difficult to imagine how this kind of thing can happen in real multi-threaded applications.
The current Java Memory Model was specified in Java 5 (the 3rd edition of the JLS) as a result of JSR 133. Prior to then, memory-related aspects of Java were under-specified. Sources that refer to earlier versions / editions are out of date, but the information on the memory model in Goetz edition 1 is up to date.
There are some technical aspects of the memory model that are apparently in need of revision; see https://openjdk.java.net/jeps/188 and https://www.infoq.com/articles/The-OpenJDK9-Revised-Java-Memory-Model/. However, this work has yet to appear in a JLS revision.

I had the exact same doubt.
The thing is that every class that gets instantiated inside other class has a reference to the enclosing class in the variable $this.
This is what java calls a synthetic, it's not something you define to be there but something java does for you automatically.
If you want to see this for yourself put a breakpoint in the doSomething(e) line and check what properties EventListener has.

My guess is that doSomething method is declared in ThisEscape class, in which case reference certainly can 'escape'.
I.e., some event can trigger this EventListener right after its creation and before execution of ThisEscape constructor is completed. And listener, in turn, will call instance method of ThisEscape.
I'll modify your example a little. Now variable var can be accessed in doSomething method before it's assigned in constructor.
public class ThisEscape {
private final int var;
public ThisEscape(EventSource source) {
source.registerListener(
new EventListener() {
public void onEvent(Event e) {
doSomething(e);
}
}
);
// more initialization
// ...
var = 10;
}
// result can be 0 or 10
int doSomething(Event e) {
return var;
}
}

I just had the exact same question while reading "Java Concurrency In Practice" by Brian Goetz.
Stephen C's answer (the accepted one) is excellent! I only wanted to add on top of that one more resource I discovered. It is from JavaSpecialists, where Dr. Heinz M. Kabutz analyzes exactly the code example that devnull posted. He explains what classes are generated (outer, inner) after compiling and how this escapes. I found that explanation useful so I felt like sharing :)
issue192 (where he extends the example and provides a race condition.)
issue192b (where he explains what kind of classes are generated after compiling and how this escapes.)

This confused me quite a bit, as well. Looking at the full code example and also just reading it a million times helped me finally see it. Compliments to Stephen C, though, whose answer is quite thorough and offers a simplified example.
The problem is source.registerListener(), which is provided as a member of ThisEscape. Who knows what that method does? We don't. ThisEscape doesn't specify, because it's declared in an interface within ThisEscape.
public class ThisEscape {
// ...
interface EventSource {
void registerListener(EventListener e);
}
interface EventListener {
void onEvent(Event e);
}
// ...
}
Whatever class implements EventSource provides the implementation for registerListener() and we have no idea what it might do with the provided EventListener. But, because EventListener is a part of ThisEscape, it also contains a hidden reference to it. That's why this example is so tricky. Basically, while ThisEscape is being constructed, a reference to it is published via source.registerListener(<reference>), and who knows what that EventSource will do with it.
It's one of the many great cases for a private constructor and static factory method. You can confine construction to one line in the static factory method, ensuring its completion before passing it to source.