import static net.javacrumbs.jsonunit.JsonAssert.assertJsonEquals;

...

assertJsonEquals("{\n" +
			"   \"test\":[\n" +
			"      1,\n" +
			"      2,\n" +
			"      {\n" +
			"         \"child\":{\n" +
			"            \"value1\":1,\n" +
			"            \"value2\":true,\n" +
			"            \"value3\":\"test\",\n" +
			"            \"value4\":{\n" +
			"               \"leaf\":5\n" +
			"            }\n" +
			"         }\n" +
			"      }\n" +
			"   ],\n" +
			"   \"root2\":false,\n" +
			"   \"root3\":1\n" +
			"}",
			"{\n" +
			"   \"test\":[\n" +
			"      5,\n" +
			"      false,\n" +
			"      {\n" +
			"         \"child\":{\n" +
			"            \"value1\":5,\n" +
			"            \"value2\":\"true\",\n" +
			"            \"value3\":\"test\",\n" +
			"            \"value4\":{\n" +
			"               \"leaf2\":5\n" +
			"            }\n" +
			"         },\n" +
			"         \"child2\":{\n" +
			"\n" +
			"         }\n" +
			"      }\n" +
			"   ],\n" +
			"   \"root4\":\"bar\"\n" +
			"}");

will result in

java.lang.AssertionError: JSON documents are different:
Different keys found in node "". Expected [root2, root3, test], got [root4, test].
Different value found in node "test[0]". Expected 1, got 5.
Different types found in node "test[1]". Expected NUMBER, got BOOLEAN.
Different keys found in node "test[2]". Expected [child], got [child, child2].
Different value found in node "test[2].child.value1". Expected 1, got 5.
Different types found in node "test[2].child.value2". Expected BOOLEAN, got STRING.
Different keys found in node "test[2].child.value4". Expected [leaf], got [leaf2].

Neat, isn't it?

Let's imagine you want to test network communication in Java. It's not easy, you have to start some server on the other side, configure its responses and somehow verify that the data you send are correct.

With mock-socket it's incredibly easy.

import static net.javacrumbs.mocksocket.MockSocket.*;
...

//prepare mock
byte[] dataToWrite = new byte[]{5,4,3,2};
expectCall().andReturn(emptyResponse());

//do test
Socket socket = SocketFactory.getDefault().createSocket("example.org", 1234);
IOUtils.write(dataToWrite, socket.getOutputStream());
socket.close();

//verify data sent
assertThat(recordedConnections().get(0), data(is(dataToWrite)));
assertThat(recordedConnections().get(0), address(is("example.org:1234")));

You see, just statically import MockSocket class, prepare the mock, execute the test and verify the data. The library just removes the default Java socket implementation and place a mock implementation in its stead.

Of course, this example does not have much sense. It just tests that Java socket implementation works. But imagine that you implement some non-trivial network library. A test library can be handy.

Moreover, there is a HTTP extension which can be used if you want to test some HTTP client. Let's say a JSON REST client. In such case, you can write this.

import static net.javacrumbs.mocksocket.http.HttpMockSocket.*;

...

//prepare mock
expectCall()
  .andWhenRequest(uri(is("/test/something.do")))
     .thenReturn(response().withStatus(404))
  .andWhenRequest(uri(is("/test/other.do")))
    .thenReturn(response().withContent("Text")).thenReturn(response().withContent("Text"));

//do your test
...

//verify
assertThat(recordedConnections(), hasItem(header("Accept", is("text/plain"))));

Ain't great? You can do much more, please take a look at the project page if you are interested.

The trick is simple yet not widely known. In fact I have encountered it in a Scala related article. You just call this code from JSP or some other suitable place.

YourClass.class.getProtectionDomain().getCodeSource().getLocation()

And that's all, this command will return path to your mystery class JAR.

I took InterestingPhotos sample application from JavaFX pages and added following code to onNext function (behold, my very first JavaFX code).

try {
	var writer = new FileWriter(new File(System.getProperty("user.home"),"javafx_infection.txt"));
	writer.append("I have escaped the browser. {new Date()}");
	writer.close();
} catch (e:Exception) {
	e.printStackTrace();
}

Now every time user clicks on the “next” button, the applet attempts to write to a file in user home directory. It can be both a malicious code or a legitimate action. There is no way to tell them apart. That's the reason why we need some security mechanism.

Unsigned application
Example
You can choose not to sign the application at all. Usually it is the best choice. This way the application will run in a sandbox and will not be able to execute any potentially dangerous code. On the other hand it will be safe for user to run it and he will not be troubled by any security alert. If the application attempts to execute dangerous code, the JRE will throw a security exception. In our case it will throw

java.security.AccessControlException: access denied (java.util.PropertyPermission user.home read)
at java.security.AccessControlContext.checkPermission(Unknown Source)
at java.security.AccessController.checkPermission(Unknown Source)
at java.lang.SecurityManager.checkPermission(Unknown Source)
at java.lang.SecurityManager.checkPropertyAccess(Unknown Source)
at java.lang.System.getProperty(Unknown Source)
at interesting.Main.hackIt(Main.fx:406)
at interesting.Main.onNext(Main.fx:133)


So if you don't need to do anything dangerous and you are happy to play in the sandbox, unsigned application is the best choice.

Selfsigned application
Example
Most of the samples on JavaFX page are self-signed. It means that the JAR is signed by a certificate that is not verified by any certification authority. In my opinion, that's the worst option you can choose. You force the user to answer following security dialog.

Basically it's the same as executing EXE (or binary) file only more dangerous. Some users already know that they should not execute EXE files from unknown sources, but they don't know that they shouldn't execute Java applications from unknown sources. I am afraid that we will hear about this issue more in the future.

If the user clicks on Run, the application can do whatever it want, if the user clicks on Cancel, the application will not run at all.

Signed application
Example
We can sign the application by a certificate that is validated by a CA. I have used Thawte Freemail Certificate. Sounds trustworthy, doesn't it? If you open the example, you will see following security warning.

It looks less threatening than with the selfsigned certificate. It looks less dangerous. The “Always trust” check-box is even checked by default. But in fact, it's not much safer. It is more complicated to generate such certificate but anyone (even me) can do it. It might be even more dangerous. Everyone who is able to generate a certificate that is validated by the same CA will be allowed to execute the code (if you leave the check box checked). And again, it is all or nothing choice. User can either give the application all permissions or do not run it at all.

Unsigned application with signed JAR
Example
In case you really need to do something potentially dangerous and you do not want to scare the user at the start of the application, you can use signed JAR in an unsigned application. Basically you can put all the dangerous stuff into a jar and sign only this jar. Most of the code can live in the main application which is unsigned. This way the application will start as unsigned and when you attempt to execute the dangerous parts the signed jar will be loaded and the security warning will be shown. In our example the application will start and the security warning will be shown when user clicks on the “next” button. At least that's how it works on my machine. And I like it. This way user can use my application and is notified only when the application needs to do something insecure. And even if he decides that he doesn't trust me, he can still use the application. (This idea came from a guy from Sun, unfortunately I don't remember his name, thanks anyway)

To reiterate, the most secure choice is to write a JavaFX application that does not need any security permissions. If you do not sign it, it runs in the sandbox and everything is fine. If you need to execute some dangerous code, you have to ask user for a permission. Which is good, but users should be instructed that they shouldn't execute any Java(FX) code if they are not sure what it does. So there is a possibility that they will not execute your applications because they will be afraid to do so. I can imagine that in the next versions of JavaFX there will be a signed library provided by Sun that will contain operations that are potentially dangerous but that are in fact safe. Like opening a file using “Open File dialog” etc.

Disclaimer: I am server-side developer, I know nothing about client-side Java, so do not be surprised if something I have written here turns up being wrong. Just correct it in the comments. Thanks.