The case in point is building a String from the concatenation of a List of Strings with some separator between them, in this case a semi-colon.
The problem is expressed as "append the separator after each element, except the last one". What seems to have evaded Mark and his commenters is that the problem can be expressed differently.
If you restate the problem as "append the separator before each item except the first one" then you are one step away from what seems to me to be an elegant solution, at least compared to the others offered.
That final step is to realise that "except the first one" can be rephrased as except the first one in which case you prepend nothing".
Applying this to the relevant section of Mark's code yields
StringBuilder sb = new StringBuilder();
String separator = "";
for (String listenerClassName : data.TEST_LISTENERS) {
if (listenerClassName != null && !"".equals(listenerClassName)) {
sb.append(separator).append(listenerClassName);
separator = ";";
}
}
There is a more OOish solution, which is to have a (tiny) class thus
public Class Separator {
private String next = "";
private String separator;
public Separator(String separator) {
this.separator = separator;
}
public String get() {
String result = next;
next = separator;
return result;
}
}
which returns an empty string the first time get() is called, then the configured value thereafter.
With this we can code the loop as
StringBuilder sb = new StringBuilder();
Separator sep = new Separator(";");
for (String listenerClassName : data.TEST_LISTENERS) {
if (listenerClassName != null && !"".equals(listenerClassName)) {
sb.append(sep.get()).append(listenerClassName);
}
}
So how do you tackle this problem?
]]>I had previously encountered slow startup with Netbeans 5.5 (itself - not the installer) and based on A. Sundararajan's blog Using Mustang's Attach API I had written a tool to output the stack traces for the three busiest threads in a java process.
Here's the source code. And for those that just need to do the same thing without understanding internals, Download the jar file
The program attaches to the local java process (specified by the PID on the command line), it grabs information about the processing time of all threads, twice 500ms apart, and uses that to find the three busiest threads. It then takes 10 stacktrace snapshots of those three threads at 10ms intervals, and looks for the common parts on those stack traces for each thread. If a thread is busy, normally most of the stack stays the same, and just the top part changes. The program then outputs to common parts of the stack traces. From there you can see which thread is running hot, and where it is.
So I enabled PID display in the Window's task Manager and ran the program. Here's what I saw...
C:\>java -jar C:\projects\experimental\HotThread\dist\HotThread.jar 3544
java.lang.UnsatisfiedLinkError: no attach in java.library.path
Exception in thread "main" com.sun.tools.attach.AttachNotSupportedException: no
at com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:190)
at hotthread.Main.main(Main.java:52)
That was due to java's installation running the JRE's copy of java.exe, but it doesn't have some of the attach API support files, so you need to run the JDK version of java.exe. Trying again...
C:\>"C:\Program Files\Java\jdk1.6.0_05\bin\java.exe" -jar C:\projects\experimental\HotThread\dist\HotThread.jar 3544
106.3% CPU Usage by Thread 'Swing-Shell'
10/10 snapshots sharing following 10 elements
sun.awt.shell.Win32ShellFolder2.getAttributes0(Native Method)
sun.awt.shell.Win32ShellFolder2.access$600(Unknown Source)
sun.awt.shell.Win32ShellFolder2$6.call(Unknown Source)
sun.awt.shell.Win32ShellFolder2$6.call(Unknown Source)
java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)
java.util.concurrent.FutureTask.run(Unknown Source)
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
sun.awt.shell.Win32ShellFolderManager2$ComInvoker$3.run(Unknown Source)
java.lang.Thread.run(Unknown Source)
1.6% CPU Usage by Thread 'RMI TCP Connection(9)-172.30.41.210'
10/10 snapshots sharing following 32 elements
sun.management.ThreadImpl.getThreadInfo0(Native Method)
sun.management.ThreadImpl.getThreadInfo(Unknown Source)
sun.reflect.GeneratedMethodAccessor106.invoke(Unknown Source)
sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
java.lang.reflect.Method.invoke(Unknown Source)
com.sun.jmx.mbeanserver.ConvertingMethod.invokeWithOpenReturn(Unknown Source)
com.sun.jmx.mbeanserver.MXBeanIntrospector.invokeM2(Unknown Source)
com.sun.jmx.mbeanserver.MXBeanIntrospector.invokeM2(Unknown Source)
com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(Unknown Source)
com.sun.jmx.mbeanserver.PerInterface.invoke(Unknown Source)
com.sun.jmx.mbeanserver.MBeanSupport.invoke(Unknown Source)
javax.management.StandardMBean.invoke(Unknown Source)
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(Unknown Source)
com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(Unknown Source)
javax.management.remote.rmi.RMIConnectionImpl.doOperation(Unknown Source)
javax.management.remote.rmi.RMIConnectionImpl.access$200(Unknown Source)
javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(Unknown Source)
javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(Unknown Source)
javax.management.remote.rmi.RMIConnectionImpl.invoke(Unknown Source)
sun.reflect.GeneratedMethodAccessor21.invoke(Unknown Source)
sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
java.lang.reflect.Method.invoke(Unknown Source)
sun.rmi.server.UnicastServerRef.dispatch(Unknown Source)
sun.rmi.transport.Transport$1.run(Unknown Source)
java.security.AccessController.doPrivileged(Native Method)
sun.rmi.transport.Transport.serviceCall(Unknown Source)
sun.rmi.transport.tcp.TCPTransport.handleMessages(Unknown Source)
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(Unknown Source)
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(Unknown Source)
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
java.lang.Thread.run(Unknown Source)
0.0% CPU Usage by Thread 'Reference Handler'
10/10 snapshots sharing following 3 elements
java.lang.Object.wait(Native Method)
java.lang.Object.wait(Object.java:485)
java.lang.ref.Reference$ReferenceHandler.run(Unknown Source)
So armed with this information, a quick search of the JDK bug database looking for "sun.awt.shell.Win32ShellFolder2" yields Bug ID: 5033747 JFileChooser is very slow on Windows XP but that is about JFileChooser which doesn't seem related to my problem, however the stack trace matches. One of the related bugs is Bug ID: 5050516 JFileChooser very slow in XP if directory contains large zip files and a light turns on. I have some big zip files on my desktop temporarily while I set things up. In that bug it shows how to disable XP's feature of treating zip files as directories which seems like it might be the root cause.
So I disabled XP's horrible ZIP file handling (which would be marvellous if it wasn't so pathetically slow), and ... Drum roll ... netbeans was installed in a couple of minutes.
Thank you JMX. Maybe a hot thread detector would be useful in jconsole and visualVM. ]]>
With this jar file and JDK 6, you can effectively cast a method to a SAM type. For those not following the various closures proposals too closely, a SAM type is a "Single Abstract Method" type. That is, a class or an interface with only one method that is abstract.
So to cast a method to a SAM type, the method should have the same argument types and return type as the SAM, but it can have any name. It may NOT be private. You then annotate that method with @net.java.dev.rapt.anon.As, and specify the SAM type.
Here is a method declared to be castable as a Runnable
import net.java.dev.rapt.anon.As;
class MyClass {
@As(Runnable.class)
void slowStuff() {
... // whatever
}
}
Thats right, you get the Runnable by calling a static method on the Runnables class, and pass the object that owns the method.new Thread(Runnables.slowStuff(this)).start();
In the jar file containing the annotation there is also an annotation processor. For each SAM type with at least one corresponding @As annotation in a package, it creates a class in that package whose name is the SAM type name with an "s" appended, hence Runnable SAM type -> Runnables.java created. That class has static methods which make anonymous inner classes that delegate to each of the methods in that package annotated with @As(Runnable.class)
Those generated static methods look like this
class Runnables {
private Runnables() {}
static Runnable slowStuff(final MyClass owner) {
return new Runnable() {
public void run() {
owner.slowStuff();
}
};
}
}
If you want to pass additional arguments to the method which are not part of the SAM, just annotate those with @As.Additional, and when you call the generated class, pass those arguments.
Here is a small swing app that demonstrates things.
package asdemo;
import java.awt.EventQueue;
import java.awt.GridLayout;
import java.awt.event.ActionEvent;
import java.awt.event.ActionListener;
import java.lang.reflect.InvocationTargetException;
import javax.swing.JButton;
import javax.swing.JFrame;
import javax.swing.JLabel;
import net.java.dev.rapt.anon.As;
public class Main extends JFrame {
JButton goButton;
JLabel label;
public Main() {
super("@As");
}
public static void main(String[] args) throws Exception {
Main instance = new Main();
// run instance's startUp() method on the EDT
EventQueue.invokeAndWait(Runnables.startUp(instance));
}
@As(Runnable.class)
void startUp() {
setLayout(new GridLayout(2,1));
goButton = new JButton("Go");
goButton.addActionListener(ActionListeners.onGo(this));
label = new JLabel("Gone");
add(label);
add(goButton);
pack();
setDefaultCloseOperation(EXIT_ON_CLOSE);
setVisible(true);
}
@As(ActionListener.class) // ActionListener for goButton
void onGo(ActionEvent e) {
goButton.setEnabled(false);
// run goBackground() in a background thread
new Thread(Runnables.goBackground(this)).start();
}
@As(Runnable.class)
void goBackground() {
for(int i = 10; i >= 0; i--) {
try {
// call showStatus(i) on EDT
EventQueue.invokeAndWait(Runnables.showStatus(this, i));
Thread.sleep(500);
} catch (InterruptedException ie) {
return;
} catch(InvocationTargetException ite) {
ite.printStackTrace();
}
}
}
@As(Runnable.class)
void showStatus(@As.Additional int value) {
if(value != 0) {
label.setText("Going " + value);
} else {
label.setText("Gone");
goButton.setEnabled(true);
}
}
}
This should compile with JDK 6. You will find the generated Runnables and ActionListeners classes whereever it is you tell javac to place generated classes (the -s option if used, otherwise in the same place as the compiled .class files).
This is designed to be work correctly even if you do incremental compiles. The processor remembers all the SAMs for the project and keeps them up to date, even if you only compile classes one by one.
Currently this doesn't work for generic SAM types. That means you can't use it to cast a method int compareStringLengths(String s1, String s2) to a Comparator<String>. I am working on a version that will infer the type parameters and the SAM type returned from the generated class will have the correct type parameters, but that isn't ready yet.
I don't think this is as good as any of the closures proposals, except in one respect, you don't have to wait for JDK 7 to use it.
]]>(The presentation video of the talk is now also available)
What seems to be happening is that much of that FUD is starting to spread.
In this post I want to expose one of these items of FUD to some light and see how it really looks. Also I am hoping that having neutralised the noise, I might more easily extract some signal from Josh's talk. I think its there but I can't hear it just yet.
At 13:06 into the sound track, Josh starts comparing interfaces to function types by first refering to these javadocs for an interface and talks about it having a name, all known implementations, and documentation including semantic constraints. He then says
"with functional types all you get is 'it takes two T's and gives you a T'. There's a lot less information there."
This presumably is in reference to where the types are used. Compare this version of a method in the fork join library with this one using closures.
An Ops.Reducer is of no value except where it is used. Now with the non closures version, all we see in the javadoc for the reduce() method is the names of the type and parameter, whereas with closures we see the essential method signature, because that is the closure type, and the parameter name. The closure version tells me more because all I get without the closure is a type name and a parameter name, and if I want to know more I have to click a link to go find it. With the closure I don't ned to first follow the link.
Recently Stephen Colbourne tried to give more impetus to this FUD when he said
"A second complaint about function types is that there is no home for documentation. One of Java's key strengths is its documentation capabilities in the form of Javadoc."
To date I haven't seen anyone describe how the javadoc tool would work for closures, so let me suggest that when a method return type is a function type, or a method parameter is a function type, then the return and parameters of that closure type will be able to have nested javadoc associated with them.
I would expect you'd find the javadoc for ParallelArray.reduce () being something like
reduce
public T reduce({T,T=>T} reducer, T base)
- Returns reduction of elements
- Parameters:
reducer- the reducer. This function must be associative.
reducer returns- The result of combining the two arguments in some way
reducer parameter 1- The first argument to be combined.
reducer parameter 2- The second argument to be combined.
base- the result for an empty array- Returns:
- reduction
You could do that now, but some new javadoc tags to do the nested documentation would make life simpler.
For sure those are pretty terrible javadocs, I just made them up, but this demonstrates that the function type's javadocs can be just as rich as the nominal type's.
Before you say it would get tedious writing out the same complicated javadoc at every place where you used a particular function type, let me say that the point at which it gets painful is probably the point at which you should consider using an interface rather than a function type, and the javadoc pain is your friend by helping you to see that.
And one last thing, Josh says that with an interface, you can find all the known implementations from the javadoc. Not so, you won't find the implementations that are anonymous inner classes. And those are exactly the sorts of places where you would use nominal types and closures. So that's not really an advantage of nominal types over function types in the places where you'd actually use them, it's just more FUD.
]]>What is interesting is the voting comments from the JCP Executive Committee. It seems that the later voters are referring to voting comments made by earlier voters. Which means that the later voters can see the voting comments (and presumably the votes) made by the earlier voters BEFORE THEY VOTE. Is that a fair way to conduct a ballot?
As usual the boring part is IBM's comment (less the first paragraph)
"IBM's vote is based on the technical merits of this JSR and is not a vote on the licensing terms. IBM supports licensing models that create an open and level playing field by allowing third parties to create independent implementations of Java Specifications and that do not allow individuals or companies to exercise unnecessary control for proprietary advantage. We support open source as a licensing model for contributions in the JCP, and would hope others will support this direction. This comment is not necessarily directed at the current business or license terms for this JSR, however, it is a statement of IBM's preferred licensing model."
They make this same comment on every ballot. Sometimes it is slightly relevant. In this case at least it is completely irrelevant. So IBM, if the intended audience of your message hasn't got it yet, I doubt they ever will, for the rest of us (and I presume the message is not targeted at me), you're starting to sound pathetic.
When I voted Hani onto the JCP I did so because I wanted someone who'd call a spade a spade. I look forward to the day when Hani's votes are postfixed with something like
This vote is based on the technical merits of the proposal and not on whether or not IBM makes statements about licensing terms in their vote comments which admit to not necessarily being directed at the particular JSR being voted on.
Maybe if a few other EC members started playing the same silly game as IBM, then the childishness of it might become apparent to them.
And one last observation, Oracle gets two votes, one as Oracle, and one as BEA, although they only exercised one of those votes this time.
]]>If you can move a thread to another JVM and have it run there, you can also presumably move it to storage, pull it back onto the original JVM some time later, and have it continue execution.
This might be worth watching. ]]>
I have invested some time getting my head around some (but not all) of the closures proposals. I don't know whether I find that easier or harder than your average practitioner, but with a little effort I can now relatively easily read and comprehend most example code.
I have also invested some time getting my head around the early draft of JSR-308 and there are parts (like method receivers) of that which I just can't get my head around. Maybe I'm thick, or maybe the spec does not do a good job of explaining what is fundamentally a good idea, or maybe the idea is fundamentally wrong. I don't yet know.
What I do know is that closures is not the only language proposal out there that can make a java program look foreign to those who can't or won't put in the effort required to internalize them. JSR-308 makes closures look simple, and its a lot closer, in terms of the JSR lifecycle, to becoming a part of the java language specification.
To all those who are voicing opinions against language changes that make java more complex, have you read the JSR-308 early draft? And have you sent your comments to the expert group?
]]>So what if instead of returning multiple values, a method returned void, but had another formal parameter which was a closure to receive the results of the method?
I've downloaded the closures prototype compiler (2007-11-20 version) and had a play with that idea. Now if it had been a complete disaster you wouldn't be reading this, because I wouldn't have blogged about it, but you are reading it so lets get on with it.
Here is a method to convert rectangular to polar coordinates and pass the results (r,theta) to a receiver closure.
static void toPolar(double x, double y, {double, double => void } rThetaReceiver) {
rThetaReceiver.invoke(Math.sqrt(x*x + y*y), Math.atan2(y, x));
}
And this is how you use it
// test toPolar
toPolar(3,4,{double r, double theta =>
System.out.format("3,4 = %f<%fRad%n",r,theta);
});
Here is the complete class with both converters, and a round trip test. Note how the round trip nests the closures.
package closures.multireturn;
/**
*
* @author bchapman
*/
public class RectangularToPolar {
static void toPolar(double x, double y, {double, double => void } rThetaReceiver) {
rThetaReceiver.invoke(Math.sqrt(x*x + y*y), Math.atan2(y, x));
}
static void toRectangular(double r, double theta, { double, double => void} xYReceiver) {
xYReceiver.invoke(r * Math.cos(theta), r * Math.sin(theta));
}
public static void main(String[] args) {
// test toPolar
toPolar(3,4,{double r, double theta =>
System.out.format("3,4 = %f<%fRad%n",r,theta);
});
// test toRectangular
toRectangular(5, Math.PI / 2, { double x, double y =>
System.out.format("5<90deg = %f,%f%n",x,y);
});
// test Round trip - toPolar and back to rectangular
toPolar(3,4,{double r, double theta =>
System.out.format("3,4 = %f<%fRad%n",r,theta);
toRectangular(r, theta, { double x, double y =>
System.out.format("%f<%fRad = %f,%f%n",r,theta,x,y);
});
});
}
}
And here's the output
C:\projects\quickhacks\src>javac closures\multireturn\RectangularToPolar.java C:\projects\quickhacks\src>java closures.multireturn.RectangularToPolar 3,4 = 5.000000<0.927295Rad 5<90deg = 0.000000,5.000000 3,4 = 5.000000<0.927295Rad 5.000000<0.927295Rad = 3.000000,4.000000
This looks promising. I'll keep exploring.
]]> One of the interesting things which I think this demonstrates is how closures are such a fundamental building block that they offer the potential of solving quite a few other problems that we've traditionally thought of as requiring specialist language changes. Maybe such solutions are not quite as nice as a specialist language change, but good enough that the advantage of not having yet another language feature outweighs the now small disadvantage of not having the perfect solution. ]]>My stack traces seem to have been getting less and less useful recently. Just to make myself perfectly clear, I am not talking about wrapping the sleigh reins around a chimney, which is what you might think of when you hear the words "stack trace".
So here are a couple of things I'd like your seven elves to work on please.
First, can the JVM elves please use the information that is available when the JVM throws an exception to create a useful message. For instance, in cases of throwing a NullPointerException, could we please be told the type of the reference that is null, and what it is that can't be done to null.
For example, say you call
Exception in thread "main" java.lang.NullPointerException: ((java.util.List)null).get()
or when accessing an element from a null array
Those are just suggestions, but having some more information in the message of JVM generated exceptions would make life a little bit more pleasant for me. I am sure I am not the only one who has spent far too long analysing a line of code that throws a NullPointerException trying to work out which reference is null, all the time overlooking the possibility that it was an Integer being used as an array index which was being autounboxed. A meaningful exception message would save an awful lot of wasted time.
Exception in thread "main" java.lang.NullPointerException: ((String[])null)[]
As best I can tell this can all be done without actually changing any specs. There are a few related bugs and RFEs in bug parade that address little parts of this, but what I'd really like is for someone to go through the whole JVM Spec, look at each exception that can be thrown by each opcode, and put all the useful information (types and names) available to the JVM into the messages in some consistent notation.
This suggestion might be a little more controversial. Often the code that is being debugged to find the cause of an Exception is not java code, but some other form that has been converted into a composite data structure and is being "executed" (in loose terms) by java code that someone else wrote for an external library or framework.
Some examples are JSP or JSF pages and scripting language code being run by an interpreter.
What would be really helpful in these cases would be for the stack trace to include a small amount of contextual information associated with key objects in the stack. Wouldn't it be nice if you could see the JSP / JSF EL expression that was being evaluated when an Exception was thrown. Wouldn't it be nice to see the name and source line number of the XML elements that enclosed the element containing that expression? Wouldn't it be nice if you could see the line numbers of the javascript code that was being executed? Wouldn't it be nice if your own classes could add the contents of a String instance field to a stack trace element for specified methods of key classes.
Here's how it might work.
Add a new property to StackTraceElement to hold the context identifier.
Define a marker annotation (say @StackContext).
Use @StackContext to annotate the methods for which you would like the context identifier shown in the stack trace.
For any class with any methods annotated with @StackContext, annotate a single String field with @StackContext to identify the context value.
When a stack trace is being filled in, the JVM would look at each method on the stack, and if it was annotated with @StackContext then the @StackContext field would be accessed, and if non null, then the value of that field would be used to set the context identifier in the corresponding stack trace element.
Printing the stack trace would print the instance identifiers where they were non null.
Other details might include taking a prefix substring if the annotated field's value was too long (say no more than 40 characters), and only filling in the context identifier once for consecutive stack trace elements with the same "this".
Imagine.
]]>