I had never heard of Phaser, but it looks pretty cool. I just read Baeldung’s Guide to Phaser and correct me if I’m wrong, but doesn’t it kind of seem like a race condition (it could just be how they use it in the examples)?
class LongRunningAction implements Runnable {
private String threadName;
private Phaser ph;
LongRunningAction(String threadName, Phaser ph) {
this.threadName = threadName;
this.ph = ph;
ph.register();
}
@Override
public void run() {
ph.arriveAndAwaitAdvance();
try {
Thread.sleep(20);
} catch (InterruptedException e) {
e.printStackTrace();
}
ph.arriveAndDeregister();
}
}
then
executorService.submit(new LongRunningAction("thread-1", ph));
executorService.submit(new LongRunningAction("thread-2", ph));
executorService.submit(new LongRunningAction("thread-3", ph));
if ph.arriveAndAwaitAdvance();
is called before all of the LongRunningAction
s are initialized, won’t it proceed before it is supposed to?
assuming you propose the idea to migrate to kotlin, it would go something like this:
if management says yes, you now have like 20 people who have vetted and agreed with the idea. once you start writing Kotlin it’s not like EVERYTHING is all of the sudden Kotlin. it’s an iterative process, and hopefully you have test coverage. you can even re-use your existing java tests since the languages are interoperable. Assuming you follow a normal development process, the odds of a catastrophic bug coming out of nowhere to cause millions of dollars of losses wouldn’t even cross my mind.
that being said, assuming the current code works decently well, management will have no motivation or reason to approve a total rewrite in a new language. it’s more likely that they will only approve starting to trickle in kotlin for new projects or features, which even further reduces the likelihood of a catastrophic bug happening.
the developers don’t have to of left the team to make it legacy code
I agree it’s unique and not really talked about. It kinda reminds me of Elixir’s doctest
Optional has more syntactic sugar for more complex scenarios / functional call chaining that prevents repetitive
if
checksOptional.ofNullable(myObj) .map(MyClass::getProperty) .map(MyOtherClass::getAnotherProperty) .filter(obj -> somePredicate(obj)) .orElse(null)
This is completely null safe, the function calls are only made if the object is not null