This article was originally posted on JRoller on January 14, 2014
On his blog, Brian Oxley shows a neat way in JDK 8 to use non AutoCloseable object having a close-like method in a try with resources construct, using the new method references. For those of us who are still stuck with JDK 7 for some time, here is the (uglier) equivalent code:
final Foo foo = new Foo(); try (AutoCloseable ignore = new AutoCloseable() { @Override public void close() { foo.close(); } }) { foo.doFoo(); }
This article was originally posted on JRoller on October 22, 2013
A simple piece of code for calculating all permutations of a given word:
public static Listpermutations(String s) { List list = new ArrayList<>(); permutations(list, s, ""); return list; } private static void permutations(List list, String from, String to) { if (from.isEmpty()) { list.add(to); } else { for (int i = 0; i < from.length(); i++) { permutations(list, new StringBuilder(from).deleteCharAt(i).toString(), to + from.charAt(i)); } } }
The code for permutations of N elements out of a word is a simple modification of the previous program:
public static ListpermutationsN(String s, int n) { List list = new ArrayList<>(); permutationsN(list, s, "", n); return list; } private static void permutationsN(List list, String from, String to, int n) { if (to.length() == n) { list.add(to); } else { for (int i = 0; i < from.length(); i++) { permutationsN(list, new StringBuilder(from).deleteCharAt(i).toString(), to + from.charAt(i), n); } } }
For Combinations, that is when order is not important, another small modification does the trick:
public static Listcombination(String s, int n) { List list = new ArrayList<>(); combination(list, s, "", 0, n); return list; } private static void combination(List list, String from, String to, int index, int n) { if (to.length() == n) { list.add(to); } else { for (int i = index; i < from.length(); i++) { combination(list, new StringBuilder(from).deleteCharAt(i).toString(), to + from.charAt(i), i, n); } } }
This article was originally posted on JRoller on Auguts 2, 2013
Here is an interesting piece of code:
public static void main(String[] args) throws Exception { JFrame alwaysOnTopFrame = new JFrame(\"Always on top Frame\"); alwaysOnTopFrame.setAlwaysOnTop(true); alwaysOnTopFrame.setDefaultCloseOperation(JFrame.DISPOSE_ON_CLOSE); alwaysOnTopFrame.setSize(500, 500); alwaysOnTopFrame.setVisible(true); alwaysOnTopFrame.setLocationRelativeTo(null); JOptionPane.showConfirmDialog(null, \"coucou\"); }
It displays a simple frame, with the "Always on Top" activated, then opens a modal dialog. What will happen? Which one will prevail and be in front of the other?
As it turns out, if you try to run this code, you will see the Frame hiding the modal dialog box, although the application waits for you to answer the dialog first. What will appear to the average user is that there is a frozen window which does not react to anything. Impossible to move it or close it, until you guess that there is a dialog box behind it.
Of course, if you know it, you can discard the dialog box using Enter or Escape key, or the Alt+F4 combination, or access the dialog box menu through Alt+Space and move it around using the arrow keys. But the average user won't know it.
What is the solution? There is actually an option that you can set on the Frame, so that it will still respond to user actions even though there are modal dialogs on the screen. It is called Modal Exclusion Type. Try adding the following line:
alwaysOnTopFrame.setModalExclusionType(ModalExclusionType.APPLICATION_EXCLUDE);
Imagine you have a SwingWorker running, and you would like to know if it has terminated its job. You notice that it has a isDone() method, and say to yourself: "great! I can use it!". But are you sure you know what it is really doing? Are you sure that all your work will be over when it returns 'true'? You would say: "of course, it is called isDone". Well, let's have a closer look.
When you create a SwingWorker, it creates a Callable, and wraps it in a Future:
Callablecallable = new Callable () { public T call() throws Exception { setState(StateValue.STARTED); return doInBackground(); } }; future = new FutureTask (callable) { @Override protected void done() { doneEDT(); setState(StateValue.DONE); } };
The Future will be executed by a ThreadPool (of maximum 10 threads). The doInBakground() is called, returning a value that will be used by the Future for its set() method. From this point onwards, calling the isDone() method will yield true. And this is even before the Future's done() method is called. So isDone() only means that doInBackground() terminated. Not what I was thinking.
OK, so why not use the getState() method. I see clearly that it is called by the Future right after the call to doneEDT(). But let's have a look at the doneEDT() method:
private void doneEDT() { Runnable doDone = new Runnable() { public void run() { done(); } }; if (SwingUtilities.isEventDispatchThread()) { doDone.run(); } else { doSubmit.add(doDone); } }
As you can see, if we are already in the EDT, we execute immediately the method. But we know that we are started from a ThreadPool, so this is not the case. The doSubmit, surprisingly, uses a Timer and schedules the task in 30ms. Not a SwingUtilities.invokeLater() as I expected, but the result is the same: the getState() will return DONE before we even start the done() method. The PropertyChange are notifying you of the state change. So basically, you are left to yourself.
This article was originally posted on Jroller on April 2, 2013
It is always the same scenario: the support team contacts us with a problem of a "frozen GUI". They send us the logs so that we can investigate, but of course the logs do not show anything. The user already restarted its GUI, so when we ask the support to perform a jstack, it is already too late. Quite often, it is not even due to a deadlock, but to a long operation that should not be done in the EDT. Since the only thing we have to investigate is the logs, I decided to write an EDT Freeze Detector that would log any operation monopolizing the EDT for more than 10 seconds. Here is the code:
import java.awt.AWTEvent;
import java.awt.EventQueue;
import java.awt.Toolkit;
import java.util.Timer;
import java.util.TimerTask;
public class FreezeDetector extends EventQueue{
private static final long FREEZE_TIMER_PERIOD = 10000L;
private volatile AWTEvent currentEvent;
private volatile Thread eventDispatchThread;
private FreezeDetector() {
Timer timer = new Timer("Freeze Detector", true);
timer.schedule(new FreezeTimerTask(), FREEZE_TIMER_PERIOD, FREEZE_TIMER_PERIOD);
}
public static void installFreezeDetector() {
Toolkit.getDefaultToolkit().getSystemEventQueue().push(new FreezeDetector());
}
@Override
protected void dispatchEvent(AWTEvent event) {
eventDispatchThread = Thread.currentThread();
currentEvent = event;
try {
super.dispatchEvent(event);
}
finally {
currentEvent = null;
}
}
private class FreezeTimerTask extends TimerTask {
private AWTEvent lastEvent;
@Override
public void run() {
if (lastEvent != null && lastEvent == currentEvent) {
printStack();
}
lastEvent = currentEvent;
}
private void printStack() {
StackTraceElement[] stackTrace = eventDispatchThread.getStackTrace();
StringBuilder sb = new StringBuilder();
sb.append("Freeze detected on EDT:");
for (StackTraceElement stackElement : stackTrace) {
sb.append(stackElement.toString()).append('\n');
}
//use your favorite logger
System.out.println(sb);
}
}
}
When running an AWS Lambda in synchronous mode from a Step Function, you will get the Lambda's return value in the output's Payload part. But unfortunately, you might also get some mostly useless information as well:
When browsing your Step Functions's output, that's a lot of noise. So to keep only the lambda's payload part, you can add this line in your task definition:
Keep only the good stuff!
Originally, Custom Resources in Cloudformation were designed for wrapping AWS resources that are not yet supported by the Cloudformation service into a Lambda. However, we often use them for other purposes:
In most of those cases, we do not care about resource deletion. But we are often surprised by calls from Cloudformation to delete the resource. The reason is the misunderstanding or the misuse of the Physical Resource ID. And the origin of this, for me, comes from a bad design choice on AWS part.
Let's have a look at the way the cfnresponse module is written.
def send(event, context, responseStatus, responseData, physicalResourceId=None, noEcho=False, reason=None):
responseUrl = event['ResponseURL']
responseBody = {
'Status' : responseStatus,
'Reason' : reason or "See the details in CloudWatch Log Stream: {}".format(context.log_stream_name),
'PhysicalResourceId' : physicalResourceId or context.log_stream_name,
'StackId' : event['StackId'],
'RequestId' : event['RequestId'],
'LogicalResourceId' : event['LogicalResourceId'],
'NoEcho' : noEcho,
'Data' : responseData
}
There are 2 bad choices:
That means that most of the time, your Physical Resource ID will change on each call, except if you trigger it several times in a row. And this change of Physical Resource ID is the one that triggers the call to the delete part of your Lambda.
You can imagine that your Resource behaves like an EC2. If you modify a tag, your instance will keep its ID. But if you change its VPC, a new instance will be created, with a new ID. In that case, the old instance must be deleted. You can consider the Physical Resource ID to be like the instance ID. You want to decide, based on which parameter was modified, if the old Resource must be kept or deleted.
Which means that in most cases, you do not want your Physical Resource ID to change. So the default behavior is wrong. It will lead to:
So the correct behavior is to always set the Physical Resource ID. And usually to a constant value:
cfnresponse.send(event, context, cfnresponse.SUCCESS, responseData, "ConstantPhysicalID")
What about the legacy code? Those old Custom Resources that already have a Physical Resource ID set to the log stream name? The good thing is that the previously set Physical Resource ID is sent to the Lambda in the event parameter. So you can simply set it back to its previous value:
physicalId = event["PhysicalResourceId"]
cfnresponse.send(event, context, cfnresponse.SUCCESS, responseData, physicalId)