What I wanted, but what other Wicket / Javascript libraries did not do, were:

• I wanted to allow the user to type multiple values. If you compose a message in Gmail, you want to be able to enter multiple recipients, not just one.
• I wanted to have the option to either allow the user to type in options which were not presented (e.g. like when composing a message in Gmail, or typing in tags into Stack Overflow) or restrict them to the options presented (like recipients in Facebook)
• I wanted to either allow the options to be included in the HTML page (e.g. for a set of 10 options, there is no point forcing the user to wait for a server round-trip to fetch matching options), or allow the options to be fetched from the server (e.g. if there are 1M options, they can’t be included in the HTML page).
• I wanted the API to be incredibly simple. I want to include a single <input> into the Wicket HTML document, create the object in Java using a constructor, and attach the data source (client-side or server-side) in a single line.

Surprisingly all of the above are not particularly easy to achieve simultaneously. But they are now done:

• MultipleValueAutoSuggestTextField (auto-suggest = can also type in other values)
• MultipleValueAutoCompleteTextField (auto-complete = only those values allowed)

And coupled with my newly created extensive multi-lingual location hierarchy database (hierarchy in the sense of 2nd district -> Vienna -> Austria -> Europe -> World, multi-lingual in the sense I have these displayable strings in various languages), allows me to create a MultipleValueLocationTextField subclass, which can be included in a host HTML page in one line of HTML and one line of Java, and which synchronizes its data with a Location[] in the client code (e.g. straight from/to a domain object), and it looks like this:

The source for the two Wicket fields linked to above is LGPL. Download Databases & Life Util ZIP.

After hours of searching, reading Javadocs, reading source, and experimenting, I finally came up with the following lines of Java code.

Alas, this method can only convert from a SVG file to a PDF file, i.e. these have to be files existing on the disk, they cannot be URLs, in memory, cannot be streamed, and the SVG cannot be an in-memory DOM object. My SVG is dynamic: I’m altering/creating it at runtime (after all, if I wasn’t doing that, I could just save the PDF somewhere statically in the first place and wouldn’t need to do the conversion). And I want to deliver the PDF to the browser so streaming would be good for me. But no matter, I use File.createTemporaryFile together with deleteOnExit to create these files, and just ignore the fact that if the JVM exits abnormally, e.g. the computer suffers from a power failure, these files will never get deleted, and, over a long enough time-span, will fill up the disk until the computer fails.

Here are the lines:

import org.apache.batik.apps.rasterizer.DestinationType;
import org.apache.batik.apps.rasterizer.SVGConverter;
import ...

// SVG is created programatically as a DOM Document 
Document svgXmlDoc = ...

// Save this SVG into a file 
File svgFile = File.createTempFile("graphic-", ".svg");
svgFile.deleteOnExit();
TransformerFactory tFac = TransformerFactory.newInstance();
Transformer transformer = tFac.newTransformer();
DOMSource source2 = new DOMSource(svgXmlDoc);
FileOutputStream fOut = new FileOutputStream(svgFile);
try { transformer.transform(source2, new StreamResult(fOut)); }
finally { fOut.close(); }

// Convert the SVG into PDF 
File outputFile = File.createTempFile("result-", ".pdf");
outputFile.deleteOnExit();
SVGConverter converter = new SVGConverter();
converter.setDestinationType(DestinationType.PDF);
converter.setSources(new String[] { svgFile.toString() });
converter.setDst(outputFile);
converter.execute();

And I have the following JARs (search using Google to find the projects and download them):

• avalon-framework-4.2.0.jar
• batik-all-1.7.jar
• commons-io-1.3.1.jar
• commons-logging-1.0.4.jar
• fop-0.95.jar
• log4j-1.2.15.jar
• xml-apis-ext.jar
• xmlgraphics-commons-1.3.1.jar

$x = new Foo();
print $x->bar();

works fine as you’d expect. but

print new Foo()->bar();
print (new Foo())->bar();

all do not work.

I do not understand how you can build an expression parser, where the code above works, and the code below does not. It’s almost as if “$x = new XXX(xxx)” a separate case searched for by the parser?

I mean if you have an expression parser capable of handling brackets, i.e. (1+2)*4, and you have the expression (new Foo()) and you have the concept of $object->method() then how can it possibly not work?

$ cat -n x.php
     1  <?php
     2
     3  class Foo {
     4     function bar() { return 4; }
     5  }
     6
     7  $foo = new Foo();
     8  print $foo->bar();
     9
    10  print (new Foo())->bar();

$ php -e x.php
Parse error: syntax error, unexpected T_OBJECT_OPERATOR
in /home/adrian/x.php on line 10

I had a situation the other day that I wanted to break one line down into multiple lines for readability. But it wasn’t possible. If I wrote the code as one line it worked; multiple lines it didn’t. This is rather inconsistent! The following public class demonstrates the situation:

public class PublicObject {
    private class PrivateObject { }

    private PrivateObject x;
    public void setX(PrivateObject x) { this.x=x; }
    public PrivateObject getX() { return x; }
}

As you see, PublicObject instances are allowed to provide public methods which take and return PrivateObject instances, however that doesn’t make a lot of sense, as you can’t write client code which creates or manipulates PrivateObject instances.

But in fact that’s not true. Java does, in a very few places, use type inference (more info here) to guess the type of objects, to save the programmer typing. And the public/private rule enforcement seems to be:

• You get an error if you write the name of a private class anywhere in your client source
• If you just use type inference to use the object, and avoid ever explicitly writing the class name in your source code, it compiles and works fine.

So the following code works:

myPublicObject.setX(myPublicObject.getX());

but the following code doesn’t:

PrivateObject x = myPublicObject.getX();
myPublicObject.setX(x);

And the reason the first line works is that, although the code is clearly using PrivateObject instances, it doesn’t ever use the word “PrivateObject” in the source code.

Surely, whether you explicitly reference the class in your code, or implicitly using the language’s type inference, are just syntactic differences only, and you should either be allowed to do both or neither.

(In .NET, the equivalent code does indeed not compile.)

MyType *x; // Original C style
MyType* x; // The other style

I was reminded of this when attending an Objective-C training course recently. Apple’s tools create declarations of the first form, the trainer preferred the second form. I remember having an opinion on this debate back when I first came across the second form, good to see that debate is still alive and well.

The logic for the second type is that x is a “pointer to MyType” and therefore one should separate the type (MyType*) from the name of the variable. That would make sense however the syntax of C doesn’t work that way. The line

MyType* x,y;

is confusing, it appears to imply that both x and y are pointers to MyType. I have read many times that this is dangerous, and the solution is never to declare more than one variable on a line.

However in fact it’s not dangerous at all, and one needn’t remember an arbitrary rule to remove this danger. The star is in the wrong place, and that’s where the confusion comes from. If one writes the statement differently:

MyType *x, y;

Then it becomes clear that only x is the pointer and y is not a pointer.

Therefore, I must side with Apple’s tools as opposed to our trainer. One has to use the syntax as it was intended, and it was intended that the type is adopted by all variables in a declaration, the level of indirection (pointers) however is not. As that’s the case, and cannot/will not be changed, the level of indirection (the number of stars) must be next to the variable name, and not the type.

In my opinion, to write the star next to the type should be a compile error.

/**
 * This represents a user of the system as stored in Oracle.
 * @author Adrian Smith
 */
class User { ... }

But really, what’s the point, when version-control tools such as “svn log”, “svn blame” and exist? (And any project where it would be necessary to determine the author necessarily involves more than one person, any (at least) any project involving more than one person requires a version control system.)

• The information in version-control log is always accurate
• The information in the source file might originally have been accurate, but the class may have been heavily refactored by someone else
• Some people start classes by copy/pasting another file and changing it: the tag will be wrong in those cases (the people who do that aren’t going to be the people who read/write/update doc)

I suppose there could be a case for using @author in the cases that the source is distributed without any version control information. But at least on the projects I work on, that’s never the case.

The project I’m currently working on has random @author tags all over the place, due to various copy/paste action and refactoring. The @author tag bears no relation to the person who last changed the code, who knows about it, or even who’s still in the company. Wrong documentation is worse than no documentation, as you might be tempted to believe wrong documentation.

(Any exception extending “Exception”, which can to be thrown from a method, must be declared at the end of method’s signature, and any caller of the method must handle the exception or itself declare to throw that type of exception; Any exception extending “RuntimeException” need not be declared on method signatures. A programmer is free to choose which superclass to extend when designing their own exceptions.)

There are two ways of dealing with tasks which should be run in the future, both of which are very inelegant w.r.t. checked exception handling.

• Runnable – the task (method) may not throw any checked exception, as the “run” method does not declare any checked exceptions (as “Runnable” defines the method; and the interface, provided by Java, cannot know what exceptions your code may throw)
• Callable – “Solves” the problem with Runnable in that the task/method may throw a checked exception. To achieve this the interface declares “throws Exception” meaning any checked exception may be thrown. This means the caller must handle “catch Exception” i.e. handle all checked exceptions, which again gives you no safety as to which exceptions can actually be thrown (the purpose of checked exceptions in the first place)

(In addition, the difference between these two interfaces is solely the way they deal with exceptions. But you wouldn’t know that, or know which interface uses which strategy, by looking at their name!)

What one would need would be to extend the generics system to deal with exceptions. For example:

interface Callable<V,E> {
    V call() throws E;
}

class MyException extends Exception { .. }

class MyCallable implements Callable<MyObject, MyException> {
    MyObject call() throws MyException {
        throw new MyException(); // ok to throw, signature declares it
    }
}

void usingCallable(MyCallable e) {
    e.call(); // error: must catch MyException
}

The generic parameter “E” would have to be a list of exception classes as opposed to just one class.

Update: I was surprised to find out that using generic parameters for checked exceptions is basically supported! However it still isn’t very useful, as:

• There is no way for the generic parameter E to be a list of exceptions
• Callable/Runnable interfaces provided by Java do not support it
• All the useful ThreadPool code that comes with Java support only Callable/Runnable

Firstly, I love assigning a list to a list of lvalues i.e. variables; this is possible in both PHP and Perl which I use regularly; and no doubt many other languages. (But not Java: why not!?)

    ($a, $b) =      ($b, $a);  // Perl
list($a, $b) = array($b, $a);  // PHP

PHP, as always, wins in inelegance, having the left side syntactically different to the right side. While it’s obviously the case that a list of values and a list of lvalues are technically different, I don’t think this difference should be expressed in the syntax.

I mean, in most languages you write e.g. $foo=4 and $bar=$foo; in both those cases you write $foo but yet they do something different (lvalue and rvalue); given that you write them the same there i think the same should apply to lists.

But I digress – What I want to mention is using “underscore” to mean “any variable”. I first saw this in Prolog.

For example, imagine you have to implement an interface (e.g. in Java), it requires you to write a function taking two parameters, but one of the parameters you don’t care about. Wouldn’t it be nice to write

interface ExistingApi {
   public void createObject(String name, Object otherInformation);
}

class MyInstanceOfTheApi {
   public void createObject(String name, _) {
      ...
   }
}

i.e. this shows clearly you do not care about the second parameter.

In current Java (and all languages I program including Perl, PHP) you have to give all variables a name even if you don’t use them, either in function definitions or in “assign to a list” scenarios mentioned above. It is then left as an exercise to the reader to determine if these variables are used or not, and indeed an exercise to the writer to name the variable they are never going to use.

I mean yes, technically you can actually just call variables “_” (or “$_” (except in Perl where “$_” already means something)) but that would then be a coding convention as opposed to a language feature, and who knows if the coding convention is actually used correctly by a programmer. (If “_” is a variable there’s nothing stopping someone from using its value.)

And then you have the problem if you have two variables you don’t care about, you can’t call them both “_”.

By the way, Programming in Prolog is an excellent book.

In Java 1.4 the authors of Java saw it fit to introduce a method to split strings,

String csvData = "field1,field2,field3";
String[] fields = csvData.split(",");

However they did not introduce a method to “join” strings! Even in Java 7 there is no way to do this, e.g. via a static String.join method (2002-now).

OK I realize this is not “rocket science”, and I appreciate it exists in various versions in various third-party libraries, but still, it’s something every program needs to do at some point, it’s annoying to have to re-define it or think about it for each application.

For example, in one project I was working on in the last 6 months, such a function was created, and then had a bug! (OK but to be fair, that was not the only bug in the application!)

Come on, I mean this is a totally trivial function, totally necessary, available in all scripting lanuags why is it still not in Java?!

(P.S. Want to see an “enterprise java” solution to this problem? Check out the number of methods on this class)

String[] myArray = new String[] { "foo", "bar" };
List myList = Arrays.asList(myArray);

In Java 1.5 this was retrofitted for varargs; you could simply pass elements to the function

List<String> myList = Arrays.asList("foo", "bar");

I never really understood how that worked in a backwards-compatible way; I mean either the function takes an array of stuff, or it takes individual elements, surely?

It turns out, that with the varargs syntax, the caller is not forced to pass individual elements, the caller can instead pass an array of elements.

List<String> myList = Arrays.asList("foo", "bar");
List<String> myList = Arrays.asList(new String[] { "foo", "bar" });

The above two calls are identical, both return a List<String>.

But surely this is really dangerous? I mean Arrays.asList does not make any assumptions about what types of arguments it accepts; the list can be composed of any object.

How can it be certain that you want to have an List of Strings, and not a List containing a single element which is a String array? (An array is an object.)

To demonstrate this inconsistency:

String[] arr = new String[] { "foo", "bar" };
Arrays.asList(arr);            // returns List<String>
Arrays.asList(arr, arr);       // returns List<String[]>
Arrays.asList(arr, arr, arr);  // returns List<String[]>