NetKernel News Volume 6 Issue 7

May 28th 2015

• Repository Updates
• Kernel Update - Java 8 Thread Management
• Tony's Blog: Engineering the Artifact not the Process
• Resource Oriented Computing Adaptive Systems (ROCAS)

Repository Updates

We released a one-line update to the kernel so that it can continue to manage rogue threads when running on Java 8.

Java 8 removed the method Thread.stop(Error) which, much to many peoples consternation, meant it was no longer possible to kill a rogue thread in Java.

We were particularly concerned about this since NetKernel is essentially an operating system and it has to be able to take ultimate accountability for threads when they are running widely varied code; code that is not necessarily well written, or even written by anyone that can be held to account (we've kissed a lot of open source library toads in our time).

Until recently we had assumed that Java 8 had simply eliminated our ability to kill errant low-level threads. However we came across this discussion...

http://stackoverflow.com/questions/23317332/alternate-to-thread-stop-in-java-8

Where someone with similar requirements was asking for the same thing: How can you kill a rogue thread (as a last resort)?

Well it turns out that hidden away in the Java 8 API documentation there is a small but important point...

Thread.stop(Error) - is no more - it will immediately throw an unsupported method exception. This is what the kernel called and so we had assumed that NetKernel could no longer manage threads on Java 8.

However...

Thread.stop()

is still there and still enables you to kill a thread (only now you can't say why you killed it with an Error argument!!)

http://docs.oracle.com/javase/8/docs/api/java/lang/Thread.html#stop--

It can be seen in the javadoc that this method always throws a ThreadDeath exception - however it doesn't throw it until its killed the thread! We still have control in the last resort.

Today's kernel update changes that one method call. We've also changed the error logging to describe the reason (which was previously provided in the Error). So we are very pleased to say that low-level control and management of core threading is still possible on Java 8, and long may it continue - there are legitimate scenarios where killing a thread really is a necessary requirement.

Tony has been rattling the cage of Software orthodoxy. This time he's done it through Linked-In...

https://www.linkedin.com/pulse/engineering-artifact-process-antony-tony-butterfield

DARPA, you know "the guys who invented the internet", have started to ask questions about why software is so poor. Here's the opening paragraph from the announcement of their new technical program Building Resource Adaptive Software Systems (BRASS)...

In other words, DARPA has identified what we felt all those years back: there is something fundamentally not right with our current model for software that leads to the saw-tooth of build-it-throw-it-away.

Furthermore, they are calling it out, taking a stand and pointing out how unnacceptable it is that software solutions have lifespans "orders of magnitude shorter than other engineering discplines".

At last!!!!!

After all this time, someone (a significant someone at that) shares our concern!

Its fantastic to at last be in such prestigous company and to no longer be a prophet in the wilderness.

Inspired by their call to arms, I decided it was time to bring together in a new whitepaper all our perspective and experience and show how Resource Oriented Computing solves the problem.

The paper is called "Resource Oriented Computing Adaptive Systems" (ROCAS).

It begins with a formal definition of stability and evovability before introducing ROC and shows how it generalizes from REST to a full computational abstraction. Having established the ROC abstraction it then presents a series of directly relevant consequences that ROC solutions exhibit - concurrency, systemic memoization, scale invariance, dynamic adaptive architecture, transrepresentation etc. It concludes with a short and sweet description of the implementation of the NetKernel platform.

I've been told its the most tightly argued and clearest explanation of ROC and NetKernel we've yet put together. I hope so. Its now high time that the classical "on-Tape" software paradigm be expanded to recognize that we have in our hands a more powerful and elegant dimension in which adaptive software is the norm.

Please take a look, we'd very much like to hear what you think of it, you can download it here...

Resource-Oriented-Computing-Adaptive-Systems-ROCAS-1.2.pdf

We're still working on the logistics for the bootcamp and looking at late July or early August. If you would like to come along, or know someone who would like to get a fast track into ROC then please drop us a line and we'll get in touch when we've finalized the plans.

Demand will probably be high - we've already had several expressions of interest from the recent LJC meet-up.

These newsletters contain hundreds of articles with lots and lots of in-depth content on ROC and NetKernel. We've recently put quite a lot of effort into making them more search engine friendly - including ensuring that we're considered mobile friendly by Google.

One thing we need help with though is for this stuff to have good page-rank. We'd really appreciate it if you could link to articles you've found valuable etc. There's a partial list in the table of contents - even just tweeting links seems to get stuff more prominence in search results. Thanks we appreciate your help!